Dear maintainers.
First of all, very good work you're doing with the project and the forum. Lots of information and good advice in here, and very good reading material as well. Especially for me as a newbie to AREDN, there is a lot to learn and study.
I got myself three used Ubiquiti Nanostations M5 with hardware revision XW. They all work quite nicely with good throughput and stability with AirOS6 and also with a genuine openWRT installation With my local WLAN hotspot at home I'm getting max. throughput, modulation scheme MCS15 nearly constantly, FTP throughput around 6 MByte/s. Very decent.
Installing the latest 3.22.12.0 works like a charm, however, the mesh building and once its established, its stability is very poor. First I thought I bough faulty hardware, but the hardware performs fine. Also, after a few Gigabytes of data, the mesh dies, the stations every now and then come to re-establish briefly, but no luck again. After power-cycling all stations, same game from the start.
I downgraded to use 3.16.2.0 which installs ok but fails to save the first password change and never lets me go any further than that. Is this a known issue? Couldn't find any notice about that.
Next stop was release 3.18.9.0 and I'm lucky the first time with AREDN software. Throughput in a peer-to-peer mesh is nearly as good as with AirOS and openWRT, mesh build-up is quick, stability and re-establishment are wonderful. More recent releases I haven't tried out yet.
Is 3.22.12.0 already known to have issues at least with Nanostations XW, or am I the first to report, or may there be something I missed in setting them up? (Just doing it the normal way with tftp...). How can I support further investigation?
Cheers and 73, Andreas.
You are here
Trouble with Nanostation M5-XW and SW 3.22.12.0
Fri, 03/10/2023 - 18:04
#1
dm4ab
Trouble with Nanostation M5-XW and SW 3.22.12.0
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
Hi, Andreas:
Please further explain 'mesh building'.
Please further define 'stability'.
LQ/NLQ values would be a measure of quality.
TxMbps and SNR would be a measure of signal strength.
If all the AREDN devices are in/at the same location,
I recommend setting Distance to farthest node to 1 km. i.e. Not automatic (0 km).
73, Chuck
Hi Chuck.
Thanks a lot for your reply. I'm new to AREDN which I could have mentioned, and I've had a learning curve after posting my original report. I can work with wireshark now, I somewhat learned the protocol, the differently tagged logical channels and handshake traffic, and I can create a better report now :-) And from understanding that I was facing a DNS resolution issue and a DtD loss of link, both seem already to be reported here: https://www.arednmesh.org/content/dns-issue.
When using SW release 3.22.12.0 the issue surfaces, with the latest nightly build (2496-211006b) functions are fine, also with older release version 3.22.8.0.
For some time (maybe 20 minutes) LQ and NLQ are 100%, then one red LED disarms, then the second one, and while this happens the NLQ and LQ ratings gradually drop to zero.
Both stations sit on my desk, after disappointment testing outside. SNR is excellent, distance is set to minimum, TXpwr down to minimum to avoid jamming each other, frequency is outside other WLAN station traffic (in unused ham frequency range).
I believe this report can be closed in favour of the linked report https://www.arednmesh.org/content/dns-issue. Not sure though how other hardwares behave - my Ubiquitis don't like the 3.22.12.0
73! Andreas.