Bolt - WiFi Locks Up

Anybus Support Anybus Wireless
#1

We are testing the Bolt in our office as a potential wireless option for our customers (using MAC cloning to get our devices on a WiFi network). We are very happy with the roaming in general, however we have run into an issue where, seemingly during a roam attempt, the wireless communications lock up. The bolt drops completely off the APs and will not rejoin. If the power is cycled to the unit it will then work again and function normally until it locks up again. The AP’s are not posting any syslog messages that would indicate an issue with them (Using two Netgear Nighthawks AC1900 with dd-wrt firmware that we roam between). Originally we were using version 2.02.01, and noticed there was new firmware since then so we upgraded to 2.03.02 and the same issue occurred. When the issue occurs, we are able to gain access to the bolt through it’s ethernet still as it has a static address. The main page states that the Status is “On”, and that the Connection is “Connecting”. When going to the WLAN page, and clicking the “Scan for Networks” button an error pops up stating “Communication error, press OK to retry”.

The settings we are using are as follows:

Easy Config: None

Network Settings:
IP Assignment = Static
IP Address = 192.168.0.99
Subnet Mask = 255.255.255.0
Default Gateway = 192.168.0.99
Internal DHCP Server = Disabled

WLAN Settings:
Enabled
Operating Mode = Client
Channel Bands = 2.4GHz
Connect to SSID = LPCARTS24
Authentication Mode = WPA/WPA2-PSK
Bridge Mode = Layer 2 cloned MAC only
Cloned MAC Address = 00-20-4A-D6-96-99
Cloned IP Address = 0.0.0.0

Bluetooth Settings: Disabled

#2

It might be that there’s an issue with the roaming conditions of the AT commands

image
image839×220 20.8 KB

But before changing these could you try the connection with 5GHz and see if that makes a difference?

#4

Before switching to 5 GHz the registers are as follows:
4003 = -70
4004 = 1

We cannot use 5GHz for this specific deployment. However, we enabled 5GHz in the APs, adjusted the Bolt accordingly, and in a short test it seemed to work better (we can usually have the lock up occur in less than an hour of roam testing with the 2.4 GHz network).

Then we switched off the Fast Roaming (ATS4004=0), and set it back to the 2.4 GHz network. Now it seems the bolt does not wish to roam at all. We saw it get to under 20% signal strength on the AP and never roaming. It’s been attached to the same access point for over an hour. Before turning fast roaming off, it was roaming between APs with no issues until the lock up.

#5

It might be worth trying to leave the fast roaming enabled and then try changing the RSSI trigger value for when it starts looking for a new connection. It might be that the connection isn’t getting bad enough for it to disconnect from the current network so it keeps trying to reconnect to the current one

#6

That wouldn’t help me with the lock up issue of the radio that I originally brought up though, and that’s what my issue is here. Regardless, I was able to force it to roam on 2.4 GHz with Fast Roaming disabled by adjusting the power of our APs. It just seems odd that roaming behaved differently when all that was changed was the Fast Roaming setting. In this case I watched the RSSI value of the WLAN connection hit -89 on the radio before it roamed. It roamed at a much different RSSI value prior to disabling the Fast Roaming, I believe it was in the -60s.

On a side note, how do I get the logs from the device? I tried using cURL on Windows but it seems to just output a webpage with no information, just some markup. I changed the Log Level to Verbose (3), and then used "curl http://192.168.0.99/cgi-bin/log.cgi -o “C:\BoltLog.tar.gz”

#7

I escalated this with one of my colleagues to try and get some syslogs and here’s what he told me you can do on the newest firmware

To activate the watchdogs you need to enter values for 2 S registers and then reboot:

ATS3016=5

ATS3017=60

AT*AMREBOOT

First one is if there is a known driver problem, then after 5 seconds we will reboot.

Second is if we are disconnected and don’t see any new AP, after 60 seconds we will reboot.

In the firmware we have also added more events that could be sent to a syslog server for further debugging, if you have the possibility to set up that at the customer we will get more information.

If possible then use these additional AT commands, replace xx.xx.xx.xx with the IP address of the syslog server.

AT*AMESS=,xx.xx.xx.xx,514,4,1

ATS1013=27

ATS1018=30

#8

Hi @ckracht,

were you able to connect to the device and make grab the logs using the method described above?

-Tim

#9

We did not get the logs setup. We found an issue with some settings in our AP that was causing roaming to be improperly handled. Once this was resolved it was found to be roaming properly.

The lockup of the radio when roaming on 2.4Ghz seemed to be a product of that fast roam setting.

#10

Oh ok, glad to hear that it’s working now!