mherger wrote: > ...Their latest dev firmware would break compatibility with the Radio. > They have been able to identify one cause for the failure ... > They believe that the problem is related to 11ax (wifi6?) and WLAN > beacon size. Now they're asking whether the beacon size was limited in > firmware or similar. ...
This sounds like progress: the AVM/Fritz!Box vendor identifying one cause for failure as related to 11ax WLAN beacon size. Two questions: 1) how did they come to believe this, and 2) could the 11ax beacon size, if too large, be reduced in their software as a compatibility option? This "toxic beacon" theory fits with my experiences investigating the radio's failure. It explains how the radio, even when solidly connected to a compatible access point, fails occasionally when exposed to much weaker signals from neighbor's newer 2019-2020+ systems. I suspect that the very frequent scanning performed by the radio is picking up these signals, and, once in a while, crashing something. The effect is that the radio loses receive sensitivity, misses packets from the access point, and eventually disconnects. I do not understand how a too large beacon would affect receiver sensitivity, other than overwriting an AGC parameter in the chip's WLAN radio receiver. And it happens "rarely" considering the radio is so frequently scanning, which was evidently increased in a patch to the driver source code, perhaps to improve performance when moving the radio between rooms or access points. Wouldn't it be great if all the other vendors were similarly engaged in this issue? I suppose a first step would be to identify and list the "offending" access points (e.g., wireless routers) make, model (and ideally firmware version). These could be researched for configuration options that might eliminate the interference, and the device owners perhaps be enticed to make these changes. The vendors could be contacted and they might investigate or provide support. Posting these user and vendor contact notes and results could be helpful. Regarding the radio's firmware, I have been involved in investigating the "wireless connectivity loss" issue implementing a troubleshooting logging (and mitigation) script wlanpoke, then 'instrumented my most often failing radio' (https://forums.slimdevices.com/showthread.php?111663-Community-Build-Radio-Firmware&p=990627&viewfull=1#post990627). An early wifi-6 router was obtained and 'wifi-6 implicated' (https://forums.slimdevices.com/showthread.php?111663-Community-Build-Radio-Firmware&p=1018853&viewfull=1#post1018853). Of note is the finding that "... it seems that the wifi-6 is the culprit, and [heavy] wifi-6 traffic makes it much, much worse." Might this imply that not just the beacon is involved? It should be noted that wifi-6 (or something) also disrupts other cheap IOT devices (e.g., cameras), making them unreliable for continuous monitoring. However, these devices reset themselves without intervention. On the other hand, very cheap devices like the ESP32 modules are not affected. Regarding the software, the host (radio) software runs the wlan script, which calls the /lib/atheros/loadAR6000l.sh script. The script loads the kernel driver ar6000.ko, uses bmiloader to set some values, then calls the eeprom.AR6002 app to load calData_ar6102_15dBm.bin. Next, bmiloader loads athwlan.bin and then data.patch.hw2_0.bin, and loadAR6000l.sh returns to the wlan script to configure the system using wmiconfig, then launches the wpa_supplicant and wpa_cli processes. The linux host software is marked open source, but that source has not been made available. Another version of the Atheros chip OS driver was modified to 'partially run' (https://forums.slimdevices.com/showthread.php?111663-Community-Build-Radio-Firmware&p=1020189&viewfull=1#post1020189), not crash, on the radio. After realizing the driver's role in simply passing packets up and down, attention turned to the chip firmware as a means of preventing a failure, rather than more quickly recovering from one. The AR6002 hardware seems quite capable. Its firmware is a combination of the chip's Tensilica Xtensa core software athwlan.bin plus the patch and configuration files. Updating this firmware is likely to completely fix the current issue. Regrettably, both the chip documentation and firmware source are proprietary. The effort to reverse engineer the binary firmware files without chip documentation seemed to be quite daunting. Using another version of firmware might work, but has not been tried. ------------------------------------------------------------------------ POMdev's Profile: http://forums.slimdevices.com/member.php?userid=70558 View this thread: http://forums.slimdevices.com/showthread.php?t=111663 _______________________________________________ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
