Chapter 4: WLAN Performance and MaintenanceTroubleshooting WLANs <<previous|next>> :Wireless network troubleshooting
Wireless network troubleshooting: Connectivity problems
15 Sep 2010 | SearchNetworking.com
When you have trouble connecting a wireless client (a desktop, laptop, PDA, or phone) to an office network, these step-by-step debugging tips can help with your wireless network connectivity problems.
1. Start by rechecking your physical connections -- a common culprit that is often overlooked. Check your wireless router's WAN port link to your cable/DSL modem and LAN port links to Ethernet clients. Make sure that WAN and LAN cables are inserted tightly and the status lights are on at both ends. If not:
- Try swapping Ethernet cables to isolate a damaged cable.
- Check your router's manual to make sure that you're using the right type of cable -- some WAN uplinks require cross-over cables.
- If status lights are still off, connect another device like a laptop to the affected WAN or LAN port. If status changes, to device you just replaced may be failing link auto-negotiation. Check port configurations at both ends and reconfigure as needed to match speed and duplex mode.
2. Next, verify that your client's wireless adapter is installed and working properly On a Windows client, select your wireless connection from the Network Connections panel and verify that its status is "Enabled."
- If the adapter is not listed, there may be a problem with the associated PC Card slot or USB adapter cable. If removing and reconnecting the adapter does not help, use Device Manager to uninstall / reinstall that adapter.
- If the adapter is listed but the connection cannot be enabled, use the Properties panel to spot resource conflicts or update the driver.
3. Next, verify that your wireless router's LAN settings are correct. Use your router's admin utility to determine its LAN port IP address and subnet.
- Make sure the router's DHCP server is set to assign IPs using a non-overlapping range in the same subnet as the LAN port address.
- If your router's DHCP Server is set to filter access by MAC address, add your client's MAC address to that "allowed device" list.
- Check your router's Log or Status page to verify that an IP address is indeed assigned to your wireless client whenever it connects.
4. Next, verify your client's TCP/IP settings. Although we describe using Windows to manage wireless connections here, troubleshooting wireless problems is conceptually similar when using any other connection manager (e.g., Intel, Linksys).
- Open the Network Connections panel and select your wireless connection. If the status is still "Disabled," return to step 2.
- If status is "Not Connected," use View Available Networks to select your wireless network and click Connect. If your network's name does not appear in Available Networks or you cannot connect to your network, go to step 8 to debug wireless settings.
- While attempting to connect, status may change briefly to "Acquiring Network Address," then "Connected." At that point, use Status/Support to determine the client's assigned IP address. If the client's IP is 0.0.0.0 or 169.254.x.x, click Repair. If that problem persists, go to step 8.
- Otherwise, if the connected client's IP address is not in your router's LAN subnet, use the Properties / Internet (TCP/IP) panel to reconfigure the connection to get an address automatically and repeat step 4.
5. Once your client has a valid IP address, use "ping" to verify network connectivity. Run a command window from the client's start menu and use it to ping your router's LAN IP address as shown in Figure 5.
- If pinging your router repeatedly fails, skip to step 6.
- If pinging your router is successful, then ping any other wired or wireless LAN client that you
wish to share files or printers with. If that ping fails, then the destination may be using a
firewall to block incoming messages.
- On Windows XP SP1 or earlier, use the connection's Properties panel to temporarily disable the Internet Connection Firewall.
- On Windows XP SP2 or later, use the client PC's control panel to temporarily disable the Windows Firewall.
- If no Microsoft firewall was running, check for a third-party personal firewall like ZoneAlarm and temporarily disable it.
- After disabling the destination's personal firewall, ping that client again. If ping is now successful, then the firewall you disabled may also be blocking Windows Network protocols. Reconfigure the firewall to permit the traffic you want to exchange between LAN clients. For example, to share files and printers, permit incoming NetBIOS connections from your LAN subnet. Don't forget to re-enable the firewall when finished!
6. If your wireless client still cannot connect, get a valid IP address, or ping your router, it's time to consider wireless-specific problems. The router and client must use compatible 802.11 standards and the same network name (SSID). Use your router's admin utility to view WLAN settings and compare them to your client's wireless connection parameters.
- If your router's network name does not appear in the client's Available Networks list, enable "SSID broadcasts" on your router. Alternatively, add the network name to your client's Preferred Connections manually. Be sure to match the router's SSID exactly, including capitalization.
- With an 802.11b client, you must use an 11b, g, or n router. If any 11b clients are present, enable b+g protection on your 11g router.
- With an 802.11a client, you must use an 11a router. For dual-band products, you may configure both ends to use 11b/g, a, or both.
- 802.11g or 11n clients can generally use 11g or n routers. However, in mixed 11g/n WLANs, disable any vendor extensions (e.g., turbo mode).
7. If a matched wireless client and router can "hear" each other but still cannot connect or exchange traffic, look for a security mismatch. The client must support the security mode required by the router: Open, WEP, WPA, or WPA2. Unless the WLAN is open (unsecured), the router and client must also have (or dynamically receive) the same keys used to encrypt traffic between them. Compare your router's WLAN security settings to your client connection's preferred network properties and attempt to match them.
- If your router uses WEP, set the client's encryption to WEP and match the router's authentication type (open or shared). Copy the router's first WEP key to the client, translating from ASCII to hex if needed.
- If your router uses WPA-Personal, set the client's authentication to WPA-PSK and match the router's encryption type (TKIP or AES). Use the router's passphrase as the client's network key; capitalization counts!
- If your router uses WPA2-Personal, set the client's authentication to WPA2-PSK and use the router's passphrase as the client's network key.
- If your router uses WPA or WPA2-Enterprise, set the client's authentication to WPA or WPA2 respectively, match the router's encryption type, and continue 802.1X set-up in step 8.
8. Ensure RADIUS is working. WPA and WPA2-Enterprise log the client into the network and deliver encryption keys using an 802.1X-capable RADIUS server. If you do not already have a RADIUS server, consult this tip. Otherwise, try the following:
- Re-configure your router and server with a matching RADIUS secret.
- Re-configure your RADIUS server to accept requests from your router.
- Use ping to verify router-to-RADIUS server network reachability.
- Watch router LAN packet counters to verify that RADIUS is being sent.
- Use a LAN analyzer (such as Wireshark) between the router and server to decode RADIUS.
- On XP SP2 clients, entering "netsh ras set tracing * enabled" to write 802.1X debug messages to the Wzctrace.log file.
9. If RADIUS is working but the client's access requests are rejected, look for an 802.1X Extensible Authentication Protocol (EAP) or user login problem. Your client must support one of the EAP types required by your server and must supply a valid login and password / token / certificate or other kind of credential.
- If your server requires EAP-TLS, select "Smart Card or other Certificate" on the client's Network Properties / Authentication panel.
- If your server requires PEAP, select "Protected EAP" on that panel.
- If your server requires EAP-TTLS, install a third-party 802.1X Supplicant program like Juniper OAC or Cisco SSC on the client.
- Make sure that client and server EAP-specific properties match, including server certificate Trusted Root Authority, server domain name (optional), and tunneled authentication method (e.g., EAP-MSCHAPv2, EAP-GTC).
- If you are prompted to accept the server's certificate at connect time, examine the certificate carefully, verifying issuer and identity. Never add an unrecognized or suspicious certificate to your trusted list.
- If EAP-TLS problems persist, use Internet Explorer to inspect the client's certificate and make sure the certificate is valid (e.g., not expired).
- If PEAP problems persist, use CHAP Configure to prevent Windows auto-logon and enter a valid username and password when prompted.
- If you still haven't spotted the problem, consult your RADIUS server's 802.1X documentation for EAP configuration and debugging hints.
10. Finally, if your wireless client connects and pings successfully, but encounters intermittent network connectivity problems (e.g., some pings work, some fail), you may be experiencing poor signal strength, RF interference, or disconnection caused by AP roaming. To troubleshoot these low-level problems, see:
- Troubleshooting wireless networks: A systematic approach
- Understanding WLAN signal strength
- Moving freely between WLAN access points
- Eliminating interference thru Wi-Fi spectrum analysis
- B vs. G: Understanding mixed WLAN performance
This tip was originally published in January, 2004, and was updated by Lisa Phifer in September, 2007.
About the author:
Lisa Phifer is vice president of Core Competence Inc., a consulting firm specializing in network security and management technology. Phifer has been involved in the design, implementation, and evaluation of data communications, internetworking, security, and network management products for nearly 20 years. She teaches about wireless LANs and virtual private networking at industry conferences and has written extensively about network infrastructure and security technologies for numerous publications. She is also a site expert to SearchMobileComputing.com and SearchNetworking.com.