Wired connectivity issues, or lack of config?

Installing and Using OpenWrt Network and Wireless Configuration
1

I've been successful at installing the snapshot for MX5500 on a couple of nodes, but I've noticed something extremely odd.

AT&T RG uses 192.168.1.254 as RG IP for DHCP, so default OpenWRT install uses 192.168.1.1 and correctly (and seamlessly) gets connectivity through the RG without issue. However, if I connect my PC (regardless of which NIC) without the MX5500 in the line, so, 'virtually' direct to the RG, I get full gigabit duplex connectivity (minus standard overhead).

Having flashed 2 MX550 boxes now, if I put either one of them in front of my RG, my speeds drop staggeringly - about 25% down and 30% up. I tested this with all three NICs as well as with 2 Win11 Enterprise VMs in Hyper-V with virtual switches attached to the 2 onboard NICs.

My first thought is that, being a basic install, I have a lot of configuration (and possibly some additional package installation) before I get it working correctly. However, I want confirmation either that that is true, or else that I might be pushing past the limits of my run. So, here is what it looks like:

RG in basement -->
Cat 6A run to NetGear 8 port Gb switch -->
Cat 6A run to patch panel -->
Cat 5e run from patch panel to 'office' 2 stories up -->
replaced termination jack -->
Cat 6A run to Tp-Link SG116 16-pot switch -->
Cat 6A run from 3x switch ports to my PC NICs
(2x on board, Gb and 1.5 Gb, and 10.0 Gb PCIe addon)

When setting up and trying to configure the MX5500s, I've taken 2 of the runs from the switch to my onboard NICs and used them as WAN connection for the MX5500s, and then connected my NICs using additional Cat 6A cables to the LAN ports, one NIC per MX5500.

Notes:

  1. Cat 5e in the walls was installed by builder, and not much I can do about it, but I did use a Southwire tester and all 4 pair tested fine one both ends.

  2. All Cat 6A I built myself, so many are 2 m lengths, but one is at least a 5 m length (termination jack to switch). All were also tested with same Southwire cabler tester.

  3. Just to be sure that my testing was not goofed, or reliant on a specific NIC, I swapped in every combination I could think of, and tested from PC using Speedtest.net, after disabling all NICs except the one being explicitly tested.

  4. Even with some basic setup, like assigning my own subnet to the LAN on one of hte MX5500, nothing changes.

So, I want to know - is it possible that I'm simply adding the nodes into a chain that is exceeding some theoretical limit of devices in a chain (I seriously, seriously doubt that, but stranger and stupider things have happened), or does the basic install require a lot of configuration post installation before I can even begin setup to achieve relatively decent throughput (I'd be happy with 80%, but would obviously prefer as close to native as possible).

Example results:

hamstringed

'direct'

2

Long story short you are basically testing the LAN<>WAN throughput of your MX5500?

If so this is a dual core 1 GHZ A53 CPU which is probably not capable of 1 Gbit throughput in default configuration due to slow CPU.

There are things to mitigate this, enable Packet steering, enable irqbalance and enable offload but even with all these workarounds I am not sure you will get 1 Gb/s

1 Like
3

Yeah, I am. I don't know what tricks the stock LinkSys firmware used, but it did achieve it mostly well enough, and if it is wasn't for the 2123 error that it encounters because of the device connectivity list, I would not be exploring alternate firmware.

Thanks for the heads up. I hope someone else who uses these can help guide me with what I need to get it working.

4

Stock uses the NSS cores (networking sub system, dedicated asic) not available with Openwrt.
You can enable packet steering and offload at the firewall.
Irqbalance is an installable package: https://openwrt.org/docs/guide-user/services/irqbalance

1 Like
5

Thanks for the heads up.

1 Like
6

I'm thinking of switch to MX5300,
it has NSS support in Openwrt but the performance is not solid and buggy,
and it is a bit expensive in 200euro.

7

I think you answered it your self :wink:
I just ordered a Flint 2 GLi net MT-6000

8

I'm also thinking of Gl-inet too, the price is attractive,
MT-6000 running MTK chip that easy to support in Openwrt.

1 Like
9

Question: Is there a breakdown of things like this that an average user would not necessarily know, and to look out for?

For example, I'm looking into Cudy devices, and while they have several (seemingly newer) WiFi 7 routers, I don't see that they have provided any sort of OpenWRT files for those (yet?). I already have at least 3 devices that are Wifi-7 ready (2 phones and a brand new laptop) but if those newer devices are gonna cause problems, or take a while to be OpenWRT ready, I might as well shop other devices that are already ready.

10

For example, it seems Cudy advertises the WiFi 7 ready dual band devices as having ARM A7 CPUs in them, but the one device they have that is tri-band advertises an ARM A53 - which puts me right back where I am right now with these LinkSys boxes, right?

11

I see my mistake now. The Cudy 7 boxes use Broadcom chips, and the 6 use either Qualcomm A53s or MediaTek Cortex-A53s, which is not the same as the Qualcomm. Took me a while to figure out the difference.

Looks like Cudy WR3000S/H is in my future, as trying to get full WiFi 7 throughout my home is going to be both expensive and painful.

12

Would this be of use to me then?

I'm searching through the thread, and found this post in particular intriguing:

Because of its mention of the IPQ5018, which is basically what is in my MX5500:

And later on, this one from Brainslayer:

In fact, moving through that thread, I see direct mention of the IPQ5018, and even posts by George, who got hte MX5500 code working, so ... this might be the way to go.

Just a lot of research I gotta do lol.

13

Welp. That was a lot of reading for a big, fat no.

Bummer.

14

yes but unlike the most ipq5018 devices which come with a secondary 6102, the mx5500 has a qcn90xx pcie chipset. you need a entire different ipq5018 main wifi firmware for it and also the kernel code used for this configuration is different. i havent tested the latest openwrt upstream patches yet on mx5500. maybe need todo next to check if this is all working correct. i just remember that i had alot of troubles with it in the past depending on the device

1 Like
15

Yeah, I read through that entire thread, saw where that one set, the MR/ MX 5500 by Linksys, used a much older NSS ...driver, firmware, whichever, that was not compatible with the latest QSDK, and breaks every time anyone tries to force it.

If it helps, I have 2x of them that I need to somehow (probably disassemble and serial flash) recover from DD-WRT builds hosed somehow, and 4 that are on the latest stock Linksys firmware from June 2025.

I've just bought a triplet of Cudy WR3000Hs (bundled with a triplet of free Cudy TR3000s) so, in effect, I have 6 MX55000, 4 of which are active on Linksys firmware and working, that I'm more than willing to use as guinea pigs to get this settled if there is any new progress to be made on them, @BrainSlayer @georgem83

16

i have a mx5500 and a mr5500 and thats the only ipq5018 devices i have and these where the base for the development i made for dd-wrt and flashing back from dd-wrt isnt a problem. you can use the factory image and use the mtd -e -f command to flash it to the linux2 and linux partition. just make sure that the entire partition must be erased before writing (which is handled by -e.
so i dont need them, you have havent noticed it but i'm the maintainer of dd-wrt

1 Like
17

Yeah, I Know you're the maintainer - it was DD-WRT I went to first for these boxes. I had forgotten you actually had them in hand though.

I'll go to their forums for more help with the failed flashbacks. Was just hoping ( long shot, I know) that the newest stock Linksys firmware for this MR/MX set might have changed something - one of the things I saw that I had not seen before was the ability to set up one MX5500, then in CA settings, enable a setting whereby it would 'automagically' set up new devices that you add for either wired AP or wireless AP use without having to go through the entire set up yourself for each device you add. This might have been there before, but it's been well over a year since I last set the MXs up on Linksys firmware, so I had not noticed it before.

As it is, though, they are gonna be glorified paperweights, unless I repurpose one or two of them for use as IoT VLAN providing APs, which, after their sub-par performance because of the NSS inanities, is about the only thing I'd consider them useful for now.