Diagnosing LANforge WiFi Problems

It can be difficult to debug wireless problems. Here are some hints. Contact support if you need more details. You may also find the Improving WiFi Performance page useful.

• Check LANforge Alerts.
  Go to the Alerts tab in the LANforge-GUI and make sure there are no DHCP alerts. This can indicate mis-configured DHCP servers on the APs, or that the DHCP server is just out of leases. The LANforge management IP should be on a different subnet from that used by the DHCP servers to ensure there are no conflicts. Link-Down alerts are probably more of a symptom than a cause.
• Check the LANforge Wireless Events window. This window prints out various WiFi events. If you see events similar to:
  

  2012-05-25 09:50:47.445  1.1:  sta224 (phy #1): auth 20:cf:30:b7:42:30 -> ee:aa:bb:cc:dd:17 status: 1: Unspecified failure
  2012-05-25 09:50:47.445  1.1:  sta222 (phy #1): auth 20:cf:30:b7:42:30 -> ee:aa:bb:cc:dd:15 status: 1: Unspecified failure
      ...

  
  then the AP is denying authentication. This is probably because there are already too many stations connected to the AP. Most APs support no more than 128 stations, and many support only 32 or 64.
• Debug External WiFi bridging mode.
  LANforge WiFi station interfaces can be configured to bridge traffic generated by external machines (usually third-party traffic generators). See the GUI Users Guide for details on how to configure it.

  When debugging WiFi bridge problems, you should start with figuring out if your system-under-test (SUT) is configured as a bridge or a routed network. In bridge mode, your traffic generator will talk through LANforge and the SUT to the target traffic generator without using a router or gateway. In routed mode, the traffic generators will talk through LANforge to a router, which will forward the traffic to the other endpoint.

  First, there is a bug in LANforge 5.2.6 and earlier where LANforge does not disable the TCP Offload for the wired Ethernet NIC. This can cause extremely slow TCP throughput in some cases. To work around this, please go to the Port-Mgr tab in the LANforge-GUI. Modify the wired port (eth1 in many cases), select 'Set Offload' on the left-hand-side, and then disable all of the offload features on the bottom-right side of the GUI. Click 'Ok'. This should fix the problem, and the offload features should stay disabled unless users explicitly re-enable them. Release 5.2.7 will automatically disable the offload features when a port is used in a wifi bridge.

  Debug Bridge Mode
  In bridge mode, the originating system (endpoint A) will make a connection to the target system (endpoint B). A and B must be on the same subnet.

  Scenario 1: A connects to B
  A will send ARP (WHO HAS) request for the MAC address of B's IP address. The packet will arrive on the Ethernet port of the LANforge, and should leave on the Station interface that matches the MAC or IP of A (depending on whether LANforge is bridging by MAC or IP). The packet then flows through the SUT and arrives at endpoint B. B should answer the ARP (IS AT) with it's MAC address. The packet should arrive on the LANforge station interface after traversing the SUT, and then be transmitted out of the Ethernet port configured for the wifi bridge. A should receive this packet, update it's ARP table, and then start the TCP (or UDP) connection.

  Scenario 2: B connects to A
  B will send ARP (WHO HAS) request for the MAC address of A's IP address. The packet go through the SUT and arrive on the Station interface in LANforge. It will be transmitted out the Ethernet interface towards system A. A should answer the ARP (IS AT) with it's MAC address. The ARP reply packet should arrive on the LANforge Ethernet interface and be transmitted out the station interface, and should arrive at system A after traversing the SUT. B should receive this packet, update it's ARP table, and then start the TCP (or UDP) connection to A.

  Debug Routed Mode
  In routed mode, the originating system (endpoint A) will make a connection to the target system (endpoint B) through a router. A and B should NOT be on the same subnet, and must have a default gateway or other route properly configured on each endpoint.

  Scenario 1: A connects to B
  A will send ARP (WHO HAS) request for the MAC address of A's gateway. The packet will arrive on the Ethernet port of the LANforge, and should leave on the Station interface that matches the MAC or IP of A (depending on whether LANforge is bridging by MAC or IP). The packet then flows to/through the SUT and arrives at the gateway. The gateway will route, and eventually B's gateway will ARP to find the MAC of endpoint B. B should answer the ARP (IS AT) with it's MAC address. The packet should arrive on B's gateway. A's router may also arp for the MAC of A. That packet should arrive on the LANforge station interface and be transmitted out the Ethernet port in the wifi bridge towards A. A should answer the ARP, and the answering packet will come in the LANforge Ethernet port and be transmitted out the station interface towards A's gateway. A will then start the TCP or UDP traffic. Packets arrive on the LANforge Ethernet port and are sent out the Station interface with destination IP of B and destination MAC of A's gateway.

  Scenario 2: B connects to A
  B will send ARP (WHO HAS) request for the MAC address of B's gateway. The packet will be answered by the SUT. B then starts the TCP or UDP connection. A's gateway will ARP for A's MAC address. The ARP request comes in the LANforge Station interface and leaves on the Ethernet port towards A. A answers the ARP. The response comes in the LANforge Ethernet interface and is transmitted out the Station interface. The destination MAC is that of A's gateway. When ARP is completed, A's gateway will start sending TCP or UDP packets to A. The packets arrive on the LANforge Station interface and leave on the Ethernet port destined for A. The destination MAC and IP should be that of A. A's response packets arrive on the LANforge Ethernet port with destination IP of B and destination MAC of A's gateway.

  To debug issues, sniff each LANforge interface and the traffic generators to figure out where the packets are lost. When bridging by IP, LANforge must re-write packets slightly, and it only works for TCP/IP, UDP/IP and ARP protocols. Candela suggests that the user use MAC bridging when possible, and to definately try MAC bridging if IP bridging fails for some reason.

  If the problem cannot be resolved, contact Candela support (perhaps through your reseller as appropriate). Please send detailed network configuration information, and packet traces or detailed description of results of packet sniffing.

• Check Supplicant Logs when debugging stations.
  The logs are found at: /home/lanforge/wifi/wpa_supplicant_log_wiphy0.txt and /home/lanforge/wifi/wpa_supplicant_log_wiphy1.txt by default. If you have only a single radio, then you will have only a single wiphy0 log file.

  By default, the wpa_supplicant logs are not very verbose. You may wish to increase the logging messages by creating a file called wpa_supplicant_args.txt and adding the content "-ddd". You can use this command: echo \\-ddd > /home/lanforge/wpa_supplicant_args.txt or create the file with your favorite text editor. After creating this file, click 'Reset' on the wiphy device or just restart the LANforge-Manager process to have the new settings take affect.

• Create monitor interface for sniffing.
  Run this command or similar on the Linux command line:
  iw phy wiphy0 interface add moni0 type monitor
  Sniff the interface using wireshark, tshark or tcpdump.