Bluesocket Access Point (BSAP) Troubleshooting Guide

[#1]

This document aims to provide general advice for installing a new Bluesocket Access Point (BSAP) as well as addressing a BSAP that is reported as “down” or does not appear in the web UI. These principles can also be applied to an AP that is rebooting unexpectedly. The vWLAN General Deployment Guide orvWLAN Quick Deployment and Configuration Guide‌ can provide guidance on setting up vWLAN to handle the new BSAP(s).

Possible solutions may included any of the following. Note: When troubleshooting an issue of this nature, it is best to avoid a factory reset (default) of the AP until the issue has been discussed with an Adtran Support Engineer.

1. The AP is not licensed
2. The AP is not in a Domain
3. Controller Discovery is not configured
4. AP Firmware is not Applied to the AP Template (vWLAN version 2.2 and above)
5. A Router or firewall is blocking traffic
6. Public IP not defined in vWLAN (vWLAN version 2.2 and above)
7. Public IP is defined in vWLAN (vWLAN version 2.2 and above), but the APs are in the same subnet as v...
8. Excessive RF interference (any version of vWLAN)
9. Factory defaulting a BSAP

The AP is not licensed

An AP that is not licensed will not appear in the Status > AP screen of vWLAN. The status light on the AP will be solid green and the network light may blink indicating activity. The AP should appear under Configuration > Wireless > AP Licenses, but there will be no domain or license information listed. Licenses should have been generated with the purchase of any new Bluesocket Access Point (BSAP). If a license file was not provided at the time of purchase, please contact the reseller or local sales representative. The Adtran ProCare team may also be able to assist with licensing issues.

If the unit is a demo, then please contact the party responsible for providing the demo equipment. Adtran Support does not generate AP licenses.

Information on installing the license can be found on our support community.

How do I apply a vWLAN license file to the vWLAN?

The AP is not in a Domain

The Status > APs list is a per domain account of APs. If an AP is in a different domain or no domain, then it will not appear under Status > APs. If the AP is in a different domain, then select that domain Domain drop-down list at the top of vWLAN. If the AP is not assigned to a domain, then browse to Configuration > Wireless > AP Licenses and select the AP(s). With the AP(s) selected, choose the appropriate AP from the Move AP(s) to Domain drop-down list located below the list of APs.

Controller Discovery is not configured

Most BSAPs are controlled exclusively through vWLAN or a BlueSecure Controller (BSC); they are not autonomous devices. The notable exception is the BSAP model 1600. If an AP does not know the address of its controller, then will be unable to communicate and therefore be reported as down. There are three controller discovery methods available.

1. Static
2. DHCP option 43
3. DNS

A static controller mode must be configured through the menu-driven command line interface (CLI) of the BSAP. The CLI can be accessed using the SSH protocol over TCP port 2335. The default username is adm1n, and the password is blue1socket. Option 1 should access the Network Configuration of the BSAP. From here options 5 and 6 can be used to set the Controller Mode and Controller Address respectively. Any BSAP that is configured with a static network assignment must also use either a static controller mode or DNS.

If the BSAP is set to obtain an IP address via DHCP, then DHCP option 43 can be used to provide the controller's address. Individual DHCP server implementations may vary, but DHCP option 43 should be set as an ASCII string containing the IP address of the controller. For example, let's say vWLAN has an IP address of 10.0.0.251, and there is an AOS device acting as a DHCP server. The AOS device could be configured as follows.

!

dhcp pool "bsap"

  network 10.0.0.0 255.255.255.0

  dns-server 10.0.0.253 10.0.0.252

  default-router 10.0.0.254

  option 43 ascii 10.0.0.251

  option 60 ascii BlueSecure.AP1500

!

If the BSAP does not have a controller assigned statically, and DHCP option 43 is not used either because the BSAP has a static network configuration or the DHCP server does not allow option 43, then the BSAP will query its DNS server to resolve the hostname apdiscovery. If this hostname resolves to the IP address of the controller, then the BSAP will attempt to establish a control channel with that IP address.  Please Note: Only the A record is required for apdiscovery in DNS.

More information on AP discovery, including converting Option 43 from ASCII to HEX can be found in our vWLAN AP Discovery guide.

AP Firmware is not Applied to the AP Template (vWLAN version 2.2 and above)

There may actually be two parts to this problem: AP firmware has not been uploaded, or the firmware has been uploaded but has not been applied to the AP template. The most common cause of this issue is a lack of AP firmware in vWLAN version 2.2. As of vWLAN version 2.2, no AP firmware is included with vWLAN meaning firmware files must be manually uploaded prior to installing APs. Also, vWLAN 2.2 backup files do not currently contain AP firmware, so AP firmware must also be uploaded after restoring vWLAN from a backup file. AP firmware is uploaded on the Configuration > Wireless > AP Firmware. It is recommended to use the root account to upload the firmware to the platform before moving the firmware to any domain. Also note that when uploading AP firmware there will be a drop-down menu allowing the administrator to apply the firmware to all templates as shown below. If no firmware is loaded, then be sure to apply the firmware to all existing templates.

If AP firmware is uploaded in vWLAN, it still must be set in the AP template. It is recommended to set firmware in all templates to help alleviate issues which may arise if an AP either does not a have template explicitly configured or the wrong template is selected during installation. If no template is defined, the AP will use the default template. This issue only occurs in vWLAN version 2.2 as previous versions and platforms (BSC) include firmware by default. This is important when creating a new template, as there is not a default AP firmware. The firmware must be explicitly set in the template.

A Router or firewall is blocking traffic

This mostly affects new installations. If the AP is in a different network than the vWLAN, verify that traffic is routed between the two networks properly. APs use specific ports to communicate with vWLAN, and it may be necessary to allow these ports through a firewall. If a firewall is between the AP and vWLAN, verify that the following ports are open.

• TCP 28000 is used by the AP to report RF data to the vWLAN.
• TCP 33333 is used for the AP control channel.
• TCP 33334 may be used by the AP to download firmware from vWLAN.
• TCP 2335 will assist in troubleshooting if the need arises.
• UDP 53 is used by the AP for DNS discovery.
• UDP 69 may be used by the AP to download firmware from vWLAN.

vWLAN will use either TFTP or SCP (over TCP 33334) to transfer firmware files to the Bluesocket AP's depending on the platform version or AP model. When configuring the firewall, it is important to consult the vWLAN configuration to determine which additional ports may need to be open. Further, as of vWLAN 2.2 it is possible to use an external server to host firmware files. This should also be taken into consideration when configuring a firewall.

Public IP not defined in vWLAN (vWLAN version 2.2 and above)

If the vWLAN is behind a firewall using NAT, additional configuration is required on the vWLAN. Under the Configuration > System > Settings > Platform options, the Public IP address for vWLAN must be defined. Please note that vWLAN behind NAT is not supported prior to version 2.2.

Public IP is defined in vWLAN (vWLAN version 2.2 and above), but the APs are in the same subnet as vWLAN

The issue here is that the vWLAN will tell the AP to communicate via the public IP address, however, LAN communication is possible at layer 2. The AP sends traffic to the public IP address, and some device will translate the destination address of the original packet to the private address of vWLAN. The traffic will hairpin back into the LAN, and special care must be taken during this hairpin to ensure return traffic is routed back through the translating device. Let us assume that a firewall will respond to the public IP address, and perform the necessary translations. Let us use some actual IP addresses for example purposes. Assume vWLAN has the IP address 192.168.0.1 and the AP has the IP address 192.168.0.2. Both devices are in the 192.168.0.0/24 network, and both use a gateway address of 192.168.0.254. This gateway address is on the firewall which also holds the public IP address configured in vWLAN; Let's say the public IP address is 74.74.75.75 for example. We will start by looking at what happens if ONLY the destination address of the original packet is translated.

The firewall has received the packet from the AP. The destination address is 74.74.75.75 and the source address is 192.168.0.2. The firewall forwards the packet to vWLAN changing the destination address to 192.168.0.1, leaving the source address as the AP's IP address. So vWLAN receives a packet with a destination address of 192.168.0.1 and a source address of 192.168.0.2. Now when vWLAN responds, it will flip the source and destination addresses. Since the destination address is 192.168.0.2, vWLAN does not have to use its gateway; the response goes straight to the AP. Because the AP did not initiate a connection to 192.168.0.1 (recall the AP initiated a connection to 74.74.75.75), the internal firewall of the AP will shutdown the communication.

Some devices will support what is called a hairpin NAT or double NAT. A hairpin NAT will change both the source and destination address of a packet such that traffic must flow back through the translating device. Let's assume now that the firewall supports hairpin NAT, and is configured to do so. Now the firewall receives the packet from the AP (source 192.168.0.2) being sent to vWLAN (74.74.75.75). The firewall will forward this packet to vWLAN, but it will change the destination to 192.168.0.1 AND the source to 192.168.0.254 (recall that is the firewall's private IP address). Now vWLAN receives a packet destined for itself sourced from 192.168.0.254, and when vWLAN responds it will send the response to 192.168.0.254. The firewall translates the source of this packet to 74.74.75.75 and the destination to 192.168.0.2 then sends the packet to the AP. The AP receives a packet from 74.74.75.75 which is what it expects.

Of course different vendors will support hairpin NAT in different ways. The above example is by no means how double NAT is actually implemented. Adtran Netvanta routers must handle hairpin traffic in a very specific way. Netvanta routers will only translate the source OR destination address, but not both. The way to support hairpin traffic in the Netvanta product line is to place the vWLAN and the APs in different networks, but have the gateway for both networks be set as the Netvanta router. The public IP address used by vWLAN is also set on the Netvanta router. This way, the AP will initiate traffic to vWLAN, which is sent to the Netvanta router. The destination address is translated to vWLAN. vWLAN's response will go back through the Netvanta router, which in turn sends traffic back to the AP. This is a very simplistic description, and may not fully describe the process. For assistance with hairpin traffic, please contact 888-4ADTRAN. You may want to specifically call out this guide.

Excessive RF interference (any version of vWLAN)

Bluesocket AP’s running firmware version 6.6.x or higher, as well as AP’s running 6.5.4 controlled by a BSC controller with BluePatch 1 installed, should not reboot due to a noisy RF environment.

The problem with excessive RF interference is all wireless stations (STAs), including APs, must contend for the wireless medium. A physical carrier sense is part of the CSMA/CA medium access method defined in the 802.11 standard. A STA will listen for other transmissions on the same channel, and cannot transmit while other devices are actively transmitting. There is also a possibly that excessive non-802.11 interference can impact a client STA's ability to hear the AP. In either case, possible problems include missed beacons, disappearing SSIDs, and decreased throughput.

Dynamic RF calibration can be used to allow the APs to scan the RF environment and choose appropriate A/B/G/N channels as well as power settings (if desired). Running dynamic RF calibration will set the AP into dual mode for a set amount of time (60 minutes by default). Dual mode causes the AP to switch to sensor mode for 3% percent of this time (about 2 minutes if the calibration time is 60 minutes) when there are no clients associated on its radios. Once the calibration has been run, the AP should automatically set itself to the least noisy channel.

Dynamic RF calibration is slightly different between vWLAN 2.2 and previous versions and hardware platforms. In vWLAN 2.2 and above, the dynamic RF calibration is configured as an Administrative Job, however the dynamic RF Mode is set under the AP template. Advanced dynamic RF settings can be configured under Configuration > Settings > Platform.

In vWLAN versions prior to 2.2 as well as other platforms, all the dynamic RF calibration settings are centralized in one location. These settings are found under Provision> Wireless> Dynamic RF (vWLAN 2.1) or Wireless> Service (BSC). It is recommended to set the dynamic RF configuration mode to “Set Once and Hold” instead of “Continuous”. A calibration of time of 60 minutes is recommended on all platforms.

If the mode is set to continuous, the AP may frequently change power and channel settings dynamically, depending on the RF environment.  When such changes are made, the AP will bring its radios down and then up. This will briefly disrupt client associations.

Factory defaulting a BSAP

It is best to consult Adtran Support prior to attempting to restore a BSAP to factory settings. The reason is two fold: we would like to gather information on any event that might trigger the need to restore default configurations, and it may be possible to recover a device without needing to factory default the unit. We would also like to limit any unexpected loss of functionality. For example, once an AP is defaulted, it will lose any static settings such as IP information or static discovery options.

The procedure for performing a factory default is similar on each BSAP. There is an option on vWLAN's Status > Access Points page or the BSAP's command line interface (CLI). Accessing the CLI for each BSAP is addressed in the individual quick start guides for the BSAPs. An example of the BSAP CLI is shown in Figure 2 above. Note that option three (3) will restore defaults.