Disassociated, could not associate

Today we have replaced 4 x netbox 5 with the new version netbox 5 ax.

Before, we used 10 MHz bandwidth, which the ax type unfortunately does not support, so we changed the settings of netbox 5 to 20 MHz and reconfigured the clients. These are LHG XL 5 and Ubiquiti Airgrid. All was working again.

So today I have swapped the APs and looked, and none of the clients was connected again. From there on, some very strange things happen: the Airgrid auto re-connected after about half an hour. A LHG did not reconnect, but when I did a scan it did see the other side OK. I started fiddling a bit with the parameters (changed 802.11 to any, for example) and suddenly it was re-connected. But in the end nothing has been changed (I compared the /export before and after the fiddling). And now it re-connects reliably.

There is another client that I cannot access at the moment, and it is not connected. When I enable “debug” logging on Wireless, I get quickly repeating sequences of:

associated, signal strength -80

disassociated, could not associate, signal strength -79

etc. There is no reason given for the failure. While -79 is not that good of a signal strength, with the netbox 5 we had situations where the signal was like -83 and still a usable connection.

The authentication is WPA2-EAP and it works (same config) on the other clients, but for this quickly reconnecting client there is no attempt to authenticate at EAP level (no RADIUS requests).

What can be going on here? Could it be distance related? I have set the distance to different values, the client is 53km away and this worked on the netbox 5 but now it completely fails. Is there a max distance for the ax type?

Ok found that the Airgrid did not auto-reconnect but it had “lock to AP MAC address” configured and the user unlocked it, then it reconnected.

So it really is only an LHG thing for now. Why “could not associate” until you fiddle with the config?

I disabled the AP for like half an hour to see if that would change things, but it doesn’t.

Now I know a little more. The client repeatedly logs:

established connection on (frequency) (SSID)

lost connection, received deauth: authentication not valid (2)

What could that be? The same client connected to the old netbox with the same authentication.

The only thing peculiar is that the client runs RouterOS 6.49.10 so not really uptodate, I have a working connection with the same type of device running RouterOS 7.19.6

Could it be that wpa2-eap on an AX device triggers a bug in 6.49.10 that makes it fail this way?

Some devices tend to associate PSK with SSID and some other details (e.g. combination of security algorithms offered by AP). And if any of those changes, station fails to connect because it thinks it doesn't know correct PSK. In such case it's necessary to set up station connection anew.

I don't think this behaviour has anything at all to do with AP though.

And I've no idea how ROS fares in this aspect. But I guess it should be pretty easy to check (remove station setup - security part in particular - and redo the configuration).

Yeah I have seen that with some other AP, however as was written the authentication is WPA2-EAP and I would expect that it at least goes through the EAP protocol (TLS connection, challenge-response) and then maybe gets a failure. However there is no attempt at all to authenticate. I can compare it with another link which I got working, and there I can see the RADIUS debug but on this connection there is nothing more than those 2 wireless debug messages, both on the AP and the client.

I have now asked the maintainer of the client device to upgrade RouterOS, to see if that improves it.

It should, because the only difference between the working and notworking link is the software on the client. I can connect the same AP from my own dish without problem.

Also the admin is trying to setup a backdoor (over another link) so I can experiment myself and try to remove-add the config.

I am completely baffled… I tried everything that I could think of, including resetting the interface and reconfiguring it, disabling security, using WPA2-PSK instead of EAP, the result is always the same.

And it worked before (with the older AP) and it continues to work on another LHG device, on the same AP.

Could it be that the new wifi-qcom driver does not support a link with a distance of 53km even when the distance is set to a larger value? What is the maximal supported value for distance?

Well, the answer from support says that in the product description it says:

That means you can add a HGO-antenna-OUT and you’ve got yourself an excellent omnidirectional AP… or try the mANT30 PA antenna to create a powerful long-range point-to-point link for distances up to 30 kilometers.

Apparently I should read that as “the max distance is 30 kilometers” even when I use another antenna than the mANT30 PA. Or when I accept the use of N mode only.

As the Netbox 5 operated this link OK, we can only conclude that there is a hard limit of 30km in the driver, not mentioned on the help page.

The product page of the LHG XL 5 ax has a highlighted “up to 30 km” in the product description, but of course I did not read that before buying a Netbox 5 ax.