Resolve unresponsive node problems with Mikrotik AC devices. 04/01/2023 #776
Conversation
Mikrotik AC devices get into a state where they wont communicate with non-AC devices .. sometimes. Leaving and rejoinging the network resets everything. We monitor for this situation and rejoin the network when detected to resolve the issue.
|
in ath9k, only clock changes were made to do 5 and 10 MHz channels. Everything else always reported and still thought only a 20MHz bandwidth was occurring. Upstream changes were never made in iw, wifi, and more to account for channel widths beyond the 802.11 specification. ath10k should be the same in this regard. I'm not 100%, but I think the spec and the beacons are always in a 20MHz channel, with the 40, 80, ... being multiple blocks of the 20MHz channel. Although, the beacon should only report these blocks, even in 5 and 10MHz channel widths; HT20, HT40- (block below), HT40+(block above), ... All this to the question... What is found other than "STA channel width: 20 MHz" in beacons? For sure, let's commit this PR to gain more insight. |
|
It's more about what the beacon payloads say about how to use the channel. On the receiver end the beacon information sometimes doesnt match what is expected when sent from a Mikrotik AC device. You'll see failed kernel assertions at times about this. It would be good to understand more about what's actually happening because - well - Ubiquiti doesnt do it. |
|
It does solve the problem in the couple of places I can test it (one my test bench, the other up on a hill near Livermore). Would be good to get some more testing in and I have another couple of people available to try it. |
ae6xe
changed the title
|
Reports from various testers say this fixed the problems. |
Mikrotik AC devices get into a state where they wont communicate with non-AC devices .. sometimes. Leaving and rejoining the network resets everything. We monitor for this situation and rejoin the network when detected to resolve the issue.
Diagnosis:
It looks like somewhere in the Mikrotik AC firmware, devices broadcast their beacons with an incorrect channel width. This will then confuse devices connecting to them resulting in failed communications. The situation is very intermittent and not all devices seem to be effected, and not every time even if they are.
I'm trying to detect the issue using the arping process as before. This is imperfect as devices sometimes dont answer (wifi broadcasts are unreliable) so I'm looking for failures over time before leaving and rejoining the IBSS network. This means detection and correct can take a few minutes. I'm trying to head the problem off for Mikrotk AC devices by doing a rejoin early on regardless.