Wireless Network Troubleshooting

July 14, 2007 [<<][>>] [back to archive index] [no comments]

When you encounter trouble connecting a wireless host (desktop, laptop, PDA) to an office network, these debugging steps can be helpful. Start by rechecking physical connections -- so often the culprit, but frequently overlooked. Is the wireless router's WAN port connected to a cable modem, DSL modem, or another router? Are Ethernet hosts cabled to the wireless router's LAN ports? Make sure all Ethernet cables are fully inserted, and that port activity status indicators (if any) are lit. Possible problems include a bad Ethernet cable, using a cross-over cable when you need a straight-thru cable or vice versa, and failure to auto-negotiate line speed (10 Mbps vs. 100 Mbps, full vs. half duplex).

Next, verify that your wireless adapter is connected properly. Make sure the adapter is recognized by your PC (i.e., visible from Windows Network Connections). View the adapter's Properties panel, click on Configure, and verify that device status is Enabled. Possible problems include using a 32-bit PC card in a 16-bit slot, connecting a USB adapter with a loose cable, installing the wrong card driver, and resource (IRQ, I/O range) conflicts.

Using the wireless router's admin interface, verify that the router's LAN port is active, noting its IP address and subnet. Make sure that DHCP is enabled and check that the DHCP address range is in the same subnet as (but does not overlap) the router's LAN port address. If your router's DHCP server filters on MAC address, add your wireless adapter to that "permitted device" list. Check your router's log or DHCP status page to see verify that an IP address is indeed assigned to your wireless adapter whenever you connect.

Check the wireless adapter's IP address using the Network Connection's Status/Support panel, or by entering "ipconfig" from a Windows Command window. If the adapter's address is either 0.0.0.0 or 169.254.x.x, retry DHCP by entering "ipconfig /renew" from a Command window, or clicking "Repair" on the Status/Support panel. If you can't get DHCP to work, try configuring your adapter with an unused IP address in the same subnet as your router's LAN port, with your router's LAN IP as default gateway. For example, if your router is 192.168.1.1/255.255.255.0, set your host's IP address to 192.168.1.2/255.255.255.0 with gateway 192.168.1.1. You may have to disable and re-enable your adapter for these IP settings to take effect.

Once you know you have a valid IP address, use the "ping" command to verify reachability. From a Command Window on your wireless host, ping your router's LAN IP address (e.g., type in "ping 192.168.1.1"). Ping replies mean success; timeouts mean failure. If pinging your router is successful, then ping another host on your LAN. If you can ping the router but not the host, go to step 6. If both pings fail, skip to step 7.

If you cannot ping another LAN host, then the sender or receiver or both may be blocking ICMP pings. If using Windows XP SP1 or earlier, open the adapter's Properties panel, choose the Advanced tab, and make sure that the Internet Connection Firewall box is unchecked. If using Windows XP SP2, verify that the Windows Firewall is disabled. If using a personal firewall like ZoneAlarm, temporarily disable that firewall program. Now retry ping. If successful, then your firewall(s) were blocking ICMP ping and may also be blocking other protocols like Windows Network sharing. Re-enable firewalls on both hosts, configuring each firewall to permit only the traffic you really want to exchange between LAN hosts. For example, to share folders and printers on your LAN, permit incoming NetBIOS connections from the same local subnet.

If your wireless adapter is enabled but cannot get a DHCP address or ping your router, then the adapter probably is not associating with your wireless router. Check that the router and adapter use the same SSID, channel, wireless mode, and security settings. Examine the router's log or Wireless status page for hints about what may be wrong. Use the XP Available Wireless Networks panel or your wireless card's client software to watch for progress and error messages. Potential problems include the following:
The adapter and router must use exactly the same SSID, including capitalization.
If Available Wireless Networks does not include your SSID, enable SSID broadcasts on your router.
If using an 802.11b adapter, make sure your wireless router is set to "mixed" 802.11b+g mode.
If using an 802.11a adapter, make sure that your wireless router is also using 802.11a.
If using a MIMO adapter, use a router from the same product line, or configure both to use standard 802.11g.
If signal appears weak, debug your wireless host right next to your wireless router, then see step 11.
If using wireless security, you may have a parameter mismatch; go to step 8.

To find and fix a wireless security parameter mismatch, temporarily disable security on both the adapter and router. Important: This may impact other users and should be done only briefly for debugging! If the problem disappears, then re-enter matching security parameters on both ends:
If using WEP, choose the same authentication mode (open system or shared key).
If using WEP, enter the same keys, translating from ASCII to hex where necessary.
If using WEP, choose the same key index number for authentication.
If using WPA, choose the same data encryption type (TKIP or AES).
If using WPA-PSK, enter the same passphrase (network key), including capitalization.
If using WPA2-PSK, enter same passphrase, making sure both ends are set to WPA2-PSK.
If using WPA or WPA2 (aka WPA/WPA2 RADIUS or 802.1X), go to step 9.

802.1X depends on communication between your wireless router and a RADIUS authentication server. Whether you're using WPA2, WPA, or WEP with dynamic keys, the following 802.1X debugging hints can be helpful:
Re-enter the same RADIUS secret into your wireless router and RADIUS server.
Configure your RADIUS server to accept RADIUS request from your router's IP address.
Use ping to verify router-to-server reachability.
Watch LAN packet counts to verify that RADIUS requests and responses are flowing.
Use an Ethernet analyzer like Ethereal to watch RADIUS success/failure messages.
For XP SP2, turn on Wzctrace.log by entering "netsh ras set tracing * enabled"

If RADIUS is flowing but access requests are being rejected, you may have an 802.1X Extensible Authentication Protocol (EAP) mismatch or credential problem. Fixing this depends on EAP Type. For example, if your RADIUS server requires EAP-TLS, then select "Smart Card or other Certificate" on your wireless adapter's Network Properties / Authentication panel. If your RADIUS server requires PEAP, then select "Protected EAP" for the adapter. If your RADIUS server requires EAP-TTLS, then you'll need a third-party wireless client like AEGIS or Odyssey. Make sure that EAP-specific properties match for your adapter and server, including server certificate Trusted Root Authority, server domain name (optional but must match when specified), and client authentication method (e.g., EAP-MSCHAPv2, EAP-GTC). When using PEAP, use the CHAP "Configure" panel to prevent Windows from automatically re-using your logon. If you still haven't spotted the problem, consult your RADIUS server's 802.1X documentation for EAP-specific configuration details.

Finally, if your wireless client associates and pings, but encounters intermittent connectivity problems (e.g., some pings work, some fail), you may be experiencing RF interference or disconnection due to roaming

Submit a new comment