AP's unexpectedly going "down".

[Anonymous]

I've been experiencing AP's showing up as "down" in vWLAN.  If I go to the location, all lights are green and appear to be flashing in a normal manner, however I can not connect through the particular AP.  All are AP's are POE.  If I physically unplug for about a minute and let the AP reboot back up it will connect to vWLAN and begin working properly.  I can also turn off the POE in the switch with the same results.

We have 1920's, 1925's, and 1940's.
vWLAN version 3.1.0 build 647193.

This is happening in what appears to be a random fashion both time-wise and device.  I see nothing in the logs that indicated an issue (or at least nothing's jumping out at me.)

My first question is:  if I lower the number in Configurations-Settings-AP Control Channel Timeout to something like 3600 seconds, does this mean the AP will automatically reboot itself after 10 minutes of being "down"?

Seondly, is this a possible but in v3.1.0, or is there some setting I may be missing?

Thanks in advance,

-Luke

[Anonymous]

Occasionally ill see the same happen running 3.0.1 Build 641375, we have a mix of 1925, 2030 and 3040 and it only appears to happen on the 1925's, i think sometime they run out of resources, or something about the RF environment causes them to go brain dead.

As far as the channel time out yes, it should in theory cause the AP to reboot if it can not contact vWLAN in the specified amount of time.

[Anonymous]

Thanks for the confirmation (at least I know I'm not alone and going

crazy.)

On Thu, Mar 29, 2018 at 10:11 AM, briangonyer <

[Anonymous]

I'm also having issues with connectivity on our AP's.  I have 6 1920's running 3.0.1-641375.  This has been an ongoing battle for over a year.  I've tried just about everything in order to better the wireless service to no avail.  The biggest issues I have are with Apple devices not letting go of an AP and connecting to a closer AP with better signal.  This also happens with Androids but not as frequent.  Our sister company switched out their AP's and we reconfigured AP placement but we are still having issues and they haven't had a single issue since the change.

[Anonymous]

I've heard through other avenues that Apple devices are having a difficult time releasing an AP.

I'm also writing to share that i have lowered the channel time out and it does not seem to make a difference.  I still have to take power away from the AP's in order for them to begin working normally again.  This is getting very very frustrating.

[Anonymous]

I forgot to mention that we are running the latest 3.1.0 build 647193.  This appears to be an issue since leaving 2.9.(?)

[Anonymous]

Luke,

I would suggest opening a ticket with ADTRAN product support. They should be able to help you troubleshoot this issue and determine what is going on.

You can open a ticket with an active service contract by going to www.adtran.com/openacase .

Thanks,

Evan Hudson

ADTRAN Product Support Manager

[Anonymous]

Douglas,

Client's actually make the decision on which AP to associate to and when to roam. Specifically in Apple's case, the decision is generally made when the signal it has seen becomes lower than -70. My guess based on your situation is either that your power settings are too high, or your APs mounting is causing an RF issue. In general, the AP can only be configured to persuade a client to move - they have no control over whether a client actually does it or not. So a good wireless design is a catalyst behind this.

If other APs don't seem to have the issues, you may consider they are using settings you aren't employing such as DynamicRF (Configuring DynamicRF in vWLAN​), our best practice settings (vWLAN Best Practice Recommended Settings​), band steering (DynamicSteering in vWLAN​). I would also highly suggest you read through RF fundamentals to be familiar with them as you make changes. (Avoiding RF Interference with a Successful BlueSocket Wireless Deployment​).

Thanks,

Evan Hudson

ADTRAN Product Support Manager

[Anonymous]

I know I need to open a ticket, but in case anyone is listening that has

similar experinces:

1. I have followed the instructions under the 'best practices' white paper.

2. When the AP goes down, all led's appear to normal.

3. The only way to reset is to fully remove power.

4. An AP does NOT reboot after X seconds of a control channel being down.

4. Finally got a log entry at the moment an AP went "Down"

2018-04-03 21:17:09 ap connection deleted AP 19252813050127 MAC

00:19:92:37:46:60 Name AP-Vickers1North disconnected INFORMATION

On Mon, Apr 2, 2018 at 2:58 PM, evanh <adtran@adtran.hosted.jivesoftware.com

[Anonymous]

I too have had frustrating connectivity problems with one customer, especially since going to 3.1.  AP lights appear normal, but Down in the GUI, cannot connect of course, and only a reboot fixes, for awhile. Another symptom is the PSK gets rejected, so the client keeps re-entering it, but no luck.  Other APs within the same building, same template and everything will be servicing clients just fine.  The AP timeout is 5 minutes, but they do not reboot on their own.  This is a mix of 1802, 1920, 2020, and 2030s.  Unfortunately support's only help so far is to do a packet capture, but if the AP is not reachable on the network that doesn't help, plus with random APs doing this I can't expect to capture an AP and get the event unless I get lucky.  Support doesn't acknowledge there's a problem in code.  I saw some problems with my in-office test bed, though on the other hand I've got a 300+ AP installation that seems to be okay on 3.1, AFAIK.  I'm two hours from the client site so camping out there is not really an option.  I just downgraded them to 3.01 and so far, less than two days back on it, things seem to be better. The jury is still out. 

[randytata]

We have seen this behavior also - and I opened a ticket on it.

We are on 3.1 with a mix of 1920's, 2020's, and 2030's

[Anonymous]

Excellent! Thanks for the update. I'm swamped with all kinds of problems

and haven't had a chance to open a ticket. If you do get an

answer/solution/resolution, PLEASE share!

On Thu, May 3, 2018 at 10:51 AM, randytata <

[Anonymous]

As a follow-up to myself, a month later the customer has been rock solid on 3.01.  Hmmm. 

[Anonymous]

Interesting.  We are running Version 3.1.0 and having the problems.

I tried going back to 3.0.1 but discovered that not only when you go backwards in versions, you also go backwards in all your settings.

[sergey_batakov]

Any solution?

[Anonymous]

Give 3.2HA a shot, seems to have fixed this and more.

[Anonymous · Accepted solution]

Brian,

You are correct. We believe that we have resolved this issue in 3.2.0-HA as several test sites have been successful with an upgrade. 3.0.2-HA also includes a host of other fixes as well.

Note: 3.2.0-HA contains no support for BSAP 1800s. They will not boot up correctly on that code. You will have to stay on 3.1.0 if you still have BSAP 1800s (they are EOL) connected.

Thanks,

Evan Hudson

ADTRAN Product Support Manager

PS: I am marking this question answered with my comment so that others will see this.

[Anonymous]

I need to add that there are also settings for the SSID's regarding converting multicast to unicast.  Once I disabled those settings our wifi network stablized even further.