I upgraded a Rocket M2 from 3.23.12.0 to the new 3.24.4.0, and it is not working right. The neighbors show up mostly as IP numbers, LQs are low and NLQs very low. RF operation is useless. I have LQM turned off.
Going back to 3.23.12.0 brings the node back to be fully usable.
The two files tried are:
- aredn-3.23.12.0-ath79-generic-ubnt_rocket-m-squashfs-sysupgrade.bin
- aredn-3.24.4.0-ath79-generic-ubnt_rocket-m-squashfs-sysupgrade.bin
The admin page shows: Hardware Type: (ath79/generic) ubnt (rocket-m)
Attached is the support data file (renamed to supportdata-K4QJZ-Rocket-202404280847.tar.gz.doc).
Any suggestions?
Thanks, Mike AB4YY
File Attachment:
connecting with a node 26 miles away.. The remote node is a Rocket M5 using 3.23.12.0
Using 3.23.4.0 LQ and NLQ are consistently 90% to 100% no issues
Using 3.24.4.0 LQ is consistently 90% or better.. NLQ ranges from 100% to 10% over a 3 minute period. DNS name will periodically drop and replaced by the IP
here are the two versions I've tried... LQM doesn't seem to make a difference with either firmware.
aredn-3.23.4.0-ath79-generic-ubnt_powerbeam-m5-xw-squashfs-sysupgrade.bin works
aredn-3.24.4.0-ath79-generic-ubnt_powerbeam-m5-xw-squashfs-sysupgrade.bin don't work
Richard ko0ooo
Orv W6BI
Before reading Mike's post, I believed my old PowerBeam was dying and replaced it with a Rocket 5AC Lite with a high gain dish (which I'm really impressed with by the way)
github issue #1055 doesn't mention the Rocket 5AC Lite as having the issue. I haven't tried version 3.24.4.0 thou, currently using 3.23.12.0
Has anyone tested the 5AC with 3.24.4.0?
Richard ko0ooo
Richard ko0ooo
Power level for both radios 10dBm
Radios approximately 100' apart and mounted 4' above ground. The PB was pointed SW toward the remote mountain node, the NS pointed at the side of the PB. (Even at waist level the PB could hear the remote mountain node on channel 172 at 90%.)
LQ and NLQ between the NS and PB remained steady at 100% for all tests.
1. The PB exhibited the stability problems. Ping times vary considerably. Ping test is JPEG 1
NS - 3.23.12.0
PB - 3.24.3.0
Channel - 172
2. The PB also exhibited the same stability problems using this nightly build. Ping times also vary considerably. Notice the new station that now appears. Ping test is JPEG 2
NS - 3.23.12.0
PB - 20240513-7c4892d
Channel - 172
3. Reinstalled 3.24.3.0 on the PB and moved to a quiet channel (183) Ran test for about 30 minutes with no problems. Ping tests consistently low. Ping test is JPEG 3
NS - 3.23.12.0
PB - 3.24.3.0
Channel - 183
It appears the addition of another station messes things up for both 3.24.3.0 and nightly 20240513-7c4892d.
Richard ko0ooo
#1
Adding a 3rd localized node to a link does bring up the possibility of it being a 'hidden' node as far as the hilltop node is concerned. Can you get the nano somewhere 'above the fence' where it might be heard by the hilltop, even if not fully connected? I had this situation here and letting all 3 somewhat hear each other improved things greatly.
The node with IP 10.102.188.55 belongs to Red Mountain in the SE part of the valley. One of its antennas is a 90 degree sector pointing NW into the Vegas valley, on channel 172
The mountain node my PB points to is High Potosi, in the SW part of the valley. It also uses a 90 degree sector pointing NE into the Vegas valley, also on channel 172
Each system doesn't appear on their respective neighbors list. So I assume they don't hear each other, at least not enough to show up on the table.
Most likely I'm hearing Red Mountain due to a reflection off the mountains.
I'll try moving the NS around my backyard, with luck I'll find a place where it hears Potosi.
Richard ko0ooo
This was reported a few cycles into the nightlies after 3.23.12, likely when OpenWRT 23.05 was introduced. Spent a lot of time testing this and we closed it thinking it was OK, but probably prematurely in hindsight. I still see the same issues on a PowerBeam M5 400 and several SXTsq Lite2's. I can reliably introduce continuous high latency and even dropped packets by switching between versions as you've noticed. Don't believe it's an external itinerant RF issue as I can make it happen or go away as fast as new firmware will load.
My two test links are:
PowerBeam M5 400 (variable fw) against a Rocket M5 XW (not my node) running 3.23.12.0. About 5 mi. -65RSSI, 100%LQ/NLQ normally.
SXTsq Lite2 against a Nanostation M2 XW. Nanostation version doesn't seem to matter. SXTs only work well with 3.23.12. This is a short on-site link between buildings with one extra node down the street. Introducing a 2nd lab SXT makes it worse but could be because it's a hidden node as far as the one down the street is concerned. Still, it's a 2nd data point which behaves the same as the first SXT--3.23.12 always makes the whole segment happy.
Also saw this in town on a Rocket M5 sector to half dozen clients of various hw types, possibly a RocketM3 trio, and another pair of PB 400's as well. Those too were rolled back successfully.
If you all have more long-term test data please post it. A simple dirty ping and 'it works!" moments after upgrading won't cut it. It may take a while for the problem to manifest. I have run ping stats overnight and 3.23.12 is perfectly stable, while 3.24 is all over the place. Try also extended iperf's and observe the retries and data size not just overall speed. Take before and after readings as you upgrade any nodes. It's not certain if this affects only the hardware types above or what. RF-less hAP and x86 images seem to be unaffected.
Ian AJ6GZ
I also saw this warning several times while running version 3.24.4.0
blocked - retries: the retransmission rate is too high to reliably pass data
I'm limited with equipment, and the remote node 26 miles distant is the only station I can reliably link with. The owners, and other Vegas valley users, probably won't appreciate my tests.
Richard ko0ooo
Thanks
Ian
- Mike