WiFi issues on new laptop

Question

I have a new ProBook 4420s that I can't use the wifi at my office (It's my access point that I control). Other devices can use wifi here just fine, and I can use the laptop on my home wifi or other nearby access points.

I am able to connect to the access point and get an IP address, but once I have one I can't send any traffic over the connection; no pings or dns requests even, and it doesn't matter whether I try to connect to internet or internal hosts.

I'm running Win7 Pro x64, and it worked okay on Friday. I feel like I'm missing something obvious. Any ideas?

Update:
When I first connect to the wifi if I look at the "Currently connected to:" list by clicking on the network item in the system tray it says: Identifying...(MySSID) No network access. This is after it already lists the network as "Connected" and I already have an IP address.

Also, sometimes it will instead connect and the "Currently connected to:" list will show it as Connection Name (Unauthenticated) No internet access.

If I set the AP to b/g mode only it doesn't even show up as an available network, which is odd because my home router does not support n at all - it's b/g only and I connect to it just fine.

Another thing: my "office" router is of the same type and configuration of several that are in student dorms on the campus where I work. I need to be sure that this will work for our students as well without requiring them to do complicated configuration steps.

Update 2:
I visited another building and was able to use the wifi access point in that building just fine. Same SSID, same dhcp server and IP address handed to me. Different model access point this time, though, that only supports b/g. My next step is to try in another place on the same network that supports n.

Update 3:
I was unable to use a similar access point in another building on campus, and replacing the access point in this building with a different model did not help. So far the only usable access points have been b/g-only. Any access point that supports n has failed. These are draft-2.0 n access points and the laptop has the final spec, so that might be part of it. But I still have trouble using those access points when configured for b/g only.

Also, I set up a static arp entry to the default gateway and it did not help. I should also mention that the main culprit here is a TrendNet TEW-639GR, but I've also had trouble talking to a Belkin F6D-4230-4 N150 and a more expensive 3Com b/g only now.

Update 4:
I updated the firmware one the router to the latest version, and it seemed to work briefly. However, it was only for one or two page requests before it stopped again, so I think the page might have been cached or pre-loaded by my browser. Anyway, I really think the problem is in this laptop, as this laptop had problems with a multiple routers that all work fine with other devices.

Answer 1

802.11 partial-connectivity problems almost always come down to multicast problems.

In 802.11, broadcasts are a subset of multicasts, so this breaks not only multicast protocols such as most service discovery / service browsing protocols, but also fundamental broadcast-based things like ARP.

802.11 multicasts are only tricky when they're being sent to a wireless client. That's why DHCP tends to work even when multicast is broken; the DHCP messages that are usually broadcast are the ones from the client (Discover, Request); the messages to the client (Offer, Ack) are usually unicast.

When you suspect an 802.11 multicast problem, the standard troubleshooting steps are:

1. Temporarily turn off wireless security on your AP and see if the problem goes away. Some security methods, such as WPA and WPA2, require multicasts to be sent with a different key than unicasts, and require the multicast (group) key to be periodically changed automatically, which some buggy APs and clients get wrong. Some security methods, such as WPA2 mixed-mode (AES and TKIP enabled simultaneously) and 802.11i TSN (AES, TKIP, and WEP enabled simultaneously) require multicasts to be sent with an entirely different cipher than unicasts, which again, many poor implementations get wrong.

2. Make sure the multicast rate [update: just your multicast rate, not your whole rate set] of your AP is not set too high. In 802.11, multicasts must be sent at a low enough data rate that all clients can receive them reliably. Try lowering it to 2 or 1 mbps and see if the problem goes away.

3. Enter static ARP mappings between your affected devices. In your case, that would be your new laptop and whatever box serves as the default gateway for the IPv4 subnet that your wireless clients are on. [*IEdit**: Just to be clear, entering a static ARP mapping on the router, that tells it the MAC address of the client, is the most important direction.] Then trying pinging your default gateway, or connecting to external sites/services. If it works now, this confirms that it's a multicast problem.

Here's an example of what I think is happening. Take the case of pinging your router:

1. Client sends ARP request (broadcast) to find MAC address for router's IP address. In this direction, it works.

2. Router sends ARP response (unicast).

3. Client sends ICMP Echo request (ping request) to IP (L3) and MAC (L2) addresses of router.

4. Router doesn't have an ARP mapping yet for the client, and it can't just trust the MAC address on the ping request it received because that could lead to ARP cache poisoning, so it sends its own ARP request (broadcast) to find the MAC address for the client's IP address. But this is the direction in which multicasts can break in 802.11.

5. Because client never receives the ARP request broadcasts from router, it never knows to reply, so the router never knows how to address the L2 headers of the ping reply frames it wants to send, so it has to drop them.

Some may ask, "But wouldn't the DHCP transaction have caused an ARP mapping to have been created on the router?", but I've seen DHCP servers that inject packets at a low level, bypassing the usual IP stack, thus bypassing the ARP code.

If it does turn out to be a multicast problem, if it's caused by your security settings and you can't find a setting that meets your security needs without hitting the bug, the solution is to either get updated firmware for your AP or drivers for your cards that have the bug fixes you need, or to replace your buggy equipment with less-buggy equipment. I suppose there's also a chance that if the problem is on the AP, that maybe third-party firmware for that AP, such as DD-WRT, OpenWRT, or Tomato, might not have the bug that the original vendor firmware had.

If it's a multicast problem caused by using a multicast rate that's too high, consider sticking to a lower multicast rate.

Answer 2

Check to make sure the router is not in B or G only mode. If it is running exclusively on an older protocol, a brand new laptop may have issues if it's not set to be backwards compatible.

Answer 3

This doesn't really fit with any other answers here or I'd just leave a comment, but in general when I hear 'new laptop' and 'can't connect to specific routers' my first thought is 'flash the firmware on the router'. I have had many cases where brand new wireless cards would send packets that confused routers with 2-3 year old firmware but the flash fixed it. Now, this probably ISN'T your issue, but it may help somebody who reads this at some point...