1 of 1 people found this helpful
The 1800 can talk to a vWLAN server (not to an AOS controller),
the NV160 can talk to a AOS based Controller typically in one of our routers or switches. (not to vWLAN),
The hardware is similar on the APs, but not identical. The firmware is different.
There are two options to allow the 1800 AP to discover the vWLAN server. (other than hard coding the AP to point to the vWLAN server, via a default gateway)…
1) Use DHCP option 60 from the AP to the DHCP server to identify the Vendor class so that the server will respond with the appropriate DHCP option 43. (if nothing else is using option 43, you could just set it in your generic DHCP scope and not look at option 60)
2) Program the AP's DNS server with the hostname of apdiscovery for the vWLANs IP address.
In some cases when your customer site router/gateway is the DNS source (proxying the corp
DNS) for the LAN, you can add a DNS entry on the router for apdsicovery. (not all Routers may support this)
DHCP Server Option 43 details
You can manually configure the DHCP server on your network to send BSC/vWLAN IP addresses to BSAPs using DHCP vendor-specific option 43.
In DHCP requests sent from the BSAP Access Point, the BSAP uses/sends option 60 Vendor class
identifier with a value of BlueSecure.AP1500 to identify itself to the DHCP server
(Note that all BSAPs —1500,1540, 1800, and 1800 —identify as BlueSecure.AP1500 for option 60).
Option 43 (if entered as a text string) is configured as a comma-separated list of IP addresses, for example
Here the “F”
denotes failover BSC/vWLAN.
If the primary BSC/vWLAN fails (the one without F in front of their IP), the AP associates to the failover BSC.
Downloading the new firmware can be slow (I have seen over 45min, depending on where the server and AP are in the network, and there is no progress bar. (Even on the same LAN it can take 5-10min I believe, other comment on that please)).
I've watched the traffic rate on the switches Ethernet port to the AP in order to gauge when it's finished (or on my lab, a Wireshark capture on the vWLAN server).
Support will have to comment if the AP will upgrade from the default template if there is not license on vWLAN. I don't know off hand.
If there is a firewall between the AP and the vWLAN, there are some firewall tweaks as well. There is a forum topic on this if you search for it.
and a side note, some DHCP servers use Hex entries by default, you need to make sure you know which format you need to enter on your server, or if you can pick ASCII text format for the IP address (assuming that's what you want).
The problem is it never communicated to the vWLAN server at all (with full license keys installed on it, and i static ip'ed the server address) Now that it is reset to factory defaults I still can't seem to connect (after setting the static, and the option 43 in DHCP) I know the regular AOS access points enter recovery mode if reset to factory default and I think that is what happened here, yet i don't know how to get it out (the topics I have seen all involve a normal AC)
Once you set a static route to the BSC, the mac address should list itself in the list of access points in the controller correct? This is what I am judging "connection" by. I would resolve all of this with adtran tech support, but the boss bought this a while back as a "demo" unit and never installed it. Now the AP license is 4 months out of date for support.
As a note, the 1800 does seem to be able to communicate to and normal AOS controller, seeing as if you console to the system, the controller options are either BSC or AC (in later firmwares) Infact, for an unrelated issue with a different AP environment support had us load the 1800 firmware to a 160 AP (since it was a later firmware that resolved some specific issues.) This 160 is what i set a static for and saw on the BSC.
Your post mentions AOS controllers, vWLAN, and the BSC platform. It would be beneficial to the discussion if you could explicitly provide the following information so we can all be sure to provide accurate assistance.
- Controller type (AOS, vWLAN, or BSC) that you trying to have the AP associate with.
- Controller software level - ie. AOS R10.9.3, vWLAN 2.3.0.09, etc.
- AP firmware level - ie. BSAP version 6.7.0-23.
I might also suggest you look at our Bluesocket Access Point (BSAP) Troubleshooting Guide.
There is not a recovery feature in the Bluesocket AP like you would see in a NV160. A factory default should simply revert the AP back to using DHCP (among other things as you obviously noticed), but the AP must still get it's firmware from vWLAN. You do not need to concern yourself with copying firmware to the AP. Or you shouldn't at least. Can you still SSH to the AP over TCP port 2335?
You may also want to contact the individual who provided the demo to assist you with setup. The demo provider may also be able to involve Adtran Support on your behalf.
Thanks, I will clarify the best I can.
Original AOS controlled wifi system: (i guess irrelevant but rather put the info out anyway.)
- Controller = Adtran 1534p firmware - nv1534v2a-r10-6-0.biz
- AP = NV 160 firmware - NV160:1840-44-1:126.96.36.199
- Controller = BSC appliance (couldnt find model number) software -
You are in Partition B.
Partition A runtime: version => V2_1_0_14
Partition B runtime: version => V2_3_0_09
- AP = BSAP 1800c firmware - as far as I can tell rev1, since its at factory defaults
I looked through the troubleshooting guide before. The problem is most of it is to do with "what if your AP is down or not licensed etc" I ran through the static, and DHCP setup process line by line twice and the BSAP never even sent a mac to the BSC. The Mac address for the NV160 is showing up in the list however, and its not even pointed to the BSC.
I wasn't able to telnet to it on trying (have a wireless management vlan on that port set to 192.168.1.2) not sure why. All setting so far I have been configuring in the console.
Okay. Just for clarification purposes, you are using vWLAN not a BSC. These are completely different platforms, and I want to eliminate any confusion. There are various ways to determine, but based on the software versions we can be certain you are using vWLAN.
You must use SSH on TCP port 2335. You cannot telnet to a Bluesocket AP like you would the NV160, but it sounds like you have a console cable connected so we can avoid this for now.
What AP firmware have you defined in vWLAN (Configuration > Wireless > AP Templates > edit whatever template is assigned to the AP > check the firmware)?
Is there any firewall/router between the AP?
Does the AP have an IP address that is not the self-assigned default address?
Can the AP ping its gateway?
Can the AP ping vWLAN?
Sorry, tried both SSH and telnet, neither works.
Firmware listed on vWLAN is bsap1840_1800v2-6.5.5-1017.bidp
There is no router or firewall between computer and AP
The AP does not seem to be pulling a DHCP at all so I just set it all to static.
AP can ping the gateway
AP can ping the vWLAN
I seem to have made some small measure of progress. I reverted the vWLAN back to v2_1_0_14 and for some reason now the mac address of the AP is coming into the system. While I can detect it, I am going to push the new firmware to it, and the re-upgrade the platform software... hopefully that will solve all of my problems.
1 of 1 people found this helpful
You should note that bsap1840_1800v2-6.5.5-1017.bidp is not compatible with vWLAN. It is NV160 firmware.
Make sure you are using BSAP software version 6.7.0-23. You can follow the AP Firmware is not Applied to the AP Template (vWLAN version 2.2 and above) section of the Bluesocket Access Point (BSAP) Troubleshooting Guide if you need assistance installing the firmware.
Did moving the AP back to vWLAN 188.8.131.52 help?
It did, for some reason or another. The older version recognized the AP. Once I pushed the latest firmware to it, it worked with the 2.3 version just fine. Not sure why but if it works it works right?
Good deal. I'm going to mark your response as the correct answer in order to make it more visible to other users. My apologies for the round about way you had to solve this, but I'm glad it's working.