OpenWrt support for Linksys MX8500

I'll confirm shortly, but it is my belief that I will see:

And here are my findings, @OpenWRT-fanboy .

tl;dr, I conclude that the board file that made it into the repo is either ID 164, or some other ID that acts exactly LIKE ID 164, and it is not stable with my MX8500s. A board file built against ID 162 IS stable.

• board-2.bin-162 (sha256sum c5e455338d114393c31693c2659d5173b0a5ff9aa2127bc6bed040550d624545): no channels disabled in iw phy phy2 channels. No apparent panics.
• board-2.bin that comes with the package (sha256sum 2d526a85435531fb9025da2dfd14a7bfc58c09d5db8c2ccac06472c699da4db1): crashy behavior/traces/100% CPU upon bootup. Channels 1-31 are all disabled in iw phy phy2 channels. Disabling all three radios with option disabled '1', then JUST enabling radio2 and issuing wifi reload sends the router into interrupt and CPU hell.
• board-2.bin-164 (sha256sum eb26d508258bccbed62f42535ce5579f1ab851871a904b3292b34a5e4a3cb85c): crashy behavior/traces/100% CPU upon bootup. Channels 1-31 are all disabled in iw phy phy2 channels. Disabling all three radios with option disabled '1', then JUST enabling radio2 and issuing wifi reload sends the router into interrupt and CPU hell.

I cycled through all the standard country codes to see which ones allowed 5 GHz at all (some allow part of it, some allow all), but as far as I can tell, all of this is set in MX8500 firmware and not through wireless-regdb. In any event, I documented what I found in https://openwrt.org/toh/linksys/mx8500#country_setting .

I think you're not getting the same checksum because you need to edit the json to "bus=pci,qmi-chip-id=0,qmi-board-id=255,variant=Linksys-MX8500"

Also, have you tested dd-wrt? I think Brainslayer has been working on MR7500/MX8500 recently and it should have newer firmware. I can't test mesh as I only have one.

Okay, there we go. You're right, if I do board ID 162 with ,variant=Linksys=MX8500 on the end, I get the matching sha256sum beginning with 3d. And that one is stable for me on 6GHz.

What I still can't figure out is how to reproduce the board file checksum that actually made it into the repo, "that acts like board ID 164", and is NOT stable for me, then.

EDIT: I'm not a board expert, but I did hexdump the 162 and 164 variants that produced the board files including the one beginning in 3d, and also the board file in the repo which I re-extracted. I think the definition of the board ID shows up at 0x0000030.

162: 00000030 34 5b 00 00 00 00 00 00 00 00 a2 3b 00 00 00 00
164: 00000030 34 5b 00 00 00 00 00 00 00 00 a4 38 00 00 00 00
repo: 00000030 34 5b 00 00 00 00 00 00 00 00 a4 29 00 00 01 00

The thing I've been trying to say all along is that I think a mistake was made: whatever the origin board-2.bin file is for the MX8500 board file that appears in the ath11k-firmware-qcn9074 package, whose shasum is 2d526a85435531fb9025da, I believe was encoded against board ID 164 (a4) then pinned to 255 (ff), and my experience is that that's not stable on the MX8500.

https://github.com/openwrt/openwrt/issues/17071 seems to want another board file for the QCN9074 for Wallystech, where 162 is properly pinned to 162/a2 (because Wallystech, when they ship their SoC, does this "properly". But in our case, the MX8500 I think does use 162/a2, but its ID was fused to ff, so we have to do this workaround -- and I believe when this got merged a few months back, the wrong board ID was put in, 164/a4.

Sounds like you should make a PR to replace the board-2.bin file.

I don't have a lot of experience with pulls in OpenWrt, but at the very least I've made a comment against the PR that introduced this, asking for another look. https://github.com/openwrt/firmware_qca-wireless/pull/37#issuecomment-2781400238

Hello,

The relevant comment related to board2.bin is here: OpenWrt support for Linksys MX8500 - #211 by hot21shot
You have the explanation for 255 vs 162 and others from a linked reddit post

After this, testuser7 added a comment stated that the board2.bin I provided was not completely correct and then provided a fixed one.
I am not sure of the difference between what I did and what testuser7 did. The board2.bin he provided work well for me in STA mode (no mesh).

Ah, this is interesting, yeah. I wonder if that's where this got changed (or if testuser7 can say what was changed, that'd be the key, but I think it's 'it was done against 164 instead')?

One of the things I consistently found with the board file in the repo is...IF the router successfully completely boots up, it's fine until a next bootup. The problems are always at QCN9024 initialization time., starting just after the 'flashing blue light' phase of bootup.

That said, if you look at 'dmesg', you may see kernel traces, or if you look at 'logread', you may see other issues, possibly with the filesystem. In general, the router can take longer to boot up. Though as you said, AP/STA mode may be okay with this board file. I've always been using this in 802.11s mode, with or without batman-adv.

Doesn't seem like dd-wrt is any better with mesh on the 6G band: DD-WRT :: View topic - MX8500 6GHz Backhaul "LEGACY" linking at 54Mbs

If you just want a functional 6G backhaul, WDS and relayd implementations should work. @Lexridge, any thoughts?

For what it's worth, if I use a board_id extracted against ID 162 and use 802.11s, I can get 1200mbps between two mesh nodes on 6GHz, no problem. I can STILL get almost that even with the one with the repo, (putting aside the initialization issues discussed earlier). See below with the 162 currently running, speed is mbps:

[B.A.T.M.A.N. adv 2024.3-openwrt-3, MainIF/MAC: phy2-mesh0/xx (bat0/xx BATMAN_V)]
         Neighbor   last-seen      speed           IF
   satellite-5.6g    0.410s (     1006.3) [phy2-mesh0]
   satellite-3.6g    0.440s (      962.9) [phy2-mesh0]
   satellite-1.6g    0.450s (      288.1) [phy2-mesh0]
   satellite-4.6g    0.090s (      633.7) [phy2-mesh0]
   satellite-2.6g    0.390s (     1161.2) [phy2-mesh0]

(Satellite-1 is going through an intermediate AP to get to the router, so its end to end performance would be expected.)

WDS worked great with limited testing and I was getting 1200Mbps with iperf3 tests between the mx8500 and a mr7500 but without relayd as I was using DD-WRT for the test. It was only 802.11s that was limited to 54Mbps with slow rates. I have no experience with relayd. I read the link for it you provided and it doesn't appear to support vlans so it would be of no use to me.

Something fascinating I discovered doing some speed testing...what channel I use in an 802.11s mesh can influence speeds I get, because the configuration combination of 'channel' and 'htmode' with the firmware can do odd things. Example:

channel 33, htmode HE160: mesh isn't visible in a scan (maybe because 33 isn't a PSC channel), but iwinfo shows a mode of "VHT160". Speeds of mesh points near each other approach 1200mbps.

channel 37, htmode HE160: mesh IS visible in a scan, but iwinfo shows a mode of "VHT80". Speeds of mesh points near each other are much slower.

I'm sure iwinfo just isn't 802.11ax/HE mode aware, but at least seems to understand the width of the SSID in play.

There's probably a cocktail of ideal channels to use with the typical HE160 htmode, but I definitely wouldn't have guessed that JUST broadcasting with a different 20MHz channel inside the same 160 MHz range would force different htmodes, or otherwise heavily influence speeds.

That is an interesting discovery. I'll test this myself later this week and post my results. Ofc this will be between mx8500 to mr7500 as I am down to one mx8500.

@OpenWRT-fanboy @skylerbunny @lytr Has there been any recent update regarding the 6 Ghz channels? I am currently on 24.10.2 and cannot get the 6ghz channel to work. I have set for WPA3 and tried channel 161/149 and sometimes channel 149 work. When channel 149 works then I can connect to my s24 with the 6e connection but then I cannot get my surface laptop7 to connect to 6e but instead it connect to the 5ghz channel. My country code is set to CA (Canada).

I went straight to the 24.10.2 version from the stock firmware. I looked over this thread but I am not sure what the board-2.bin discussion means? Is that necessary if I went straight to the 24.10.2 version?

Currently, I cannot get any of my radios to work unless I reset my router. However, I have working internent via a ethernent cable.

Just got 3x MX8500 bundle from ebay.

Something is really interesting with this device:

1. Although the 5GHz radio is advertised 4x4 80MHz (2402 mbps), from iw list it seems to support 4x4 160MHz too (4804mbps). ( -- This is unlike E8450, where you choose between 80MHz 4x4 or 160MHz 2x2). I briefly tested it. It seems working in AP/Station mode but not in 802.11s.
2. The regdb shipped by the firmware seems to be different (you may say superior) than what a standard openwrt/linux offers (US regdom):

root@MX8501:~# iw reg get
global
country US: DFS-FCC
        (902 - 904 @ 2), (N/A, 30), (N/A)
        (904 - 920 @ 16), (N/A, 30), (N/A)
        (920 - 928 @ 8), (N/A, 30), (N/A)
        (2400 - 2472 @ 40), (N/A, 30), (N/A)
        (5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
        (5250 - 5350 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
        (5470 - 5730 @ 160), (N/A, 24), (0 ms), DFS
        (5730 - 5850 @ 80), (N/A, 30), (N/A), AUTO-BW
        (5850 - 5895 @ 40), (N/A, 27), (N/A), NO-OUTDOOR, AUTO-BW, PASSIVE-SCAN
        (5925 - 7125 @ 320), (N/A, 12), (N/A), NO-OUTDOOR, PASSIVE-SCAN
......

phy#2 (self-managed)
country US: DFS-FCC
        (2402 - 2472 @ 40), (6, 30), (N/A)
        (5170 - 5250 @ 80), (N/A, 30), (N/A), AUTO-BW
        (5250 - 5330 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
        (5490 - 5730 @ 160), (N/A, 24), (0 ms), DFS, AUTO-BW
        (5735 - 5895 @ 160), (N/A, 30), (N/A), AUTO-BW
        (5925 - 7125 @ 160), (N/A, 30), (N/A), NO-OUTDOOR, AUTO-BW

...... (similar for other phy's)...

It can do 30 dbm on low 5GHz band (36-48) (v.s. 23 dbm on a standard openwrt). It can also use UNII-4 band (169 173 177), which allows me to have 3 non-overlapping 160mhz channels in 5GHz band. -- Theses are legal in US. Just for some complicated reasons the upstream wireless-regdb is more restricted.

That's very cool!