Any random reboot or crash on your devices?
Drowning... flooded... i will get there... i havent given up hope of finding a few hours to finish this...
none to speak of so far
ok, so I spoke too soon. the version I had, had DAWN on it, it worked partially, and I updated it. I managed to trash the config, reloaded a sysupgrade squashfs file, and now DAWN is gone. what would be the best working sysupgrade right now to test on? EDIT: something about UmDNS it doesn't like
Just a follow-up, it looks like the issue with the 2.5Gbps interface when connected to a Ubiquity (Realtek-based) UACC-Adapter-RJ45-USBC-5GE interface is auto-negotiation between that and the Aquantia PHY in the MR-53 -- maybe related to the fact that the MR53 seems to advertise 5000baseT/Full as a supported capability?
I (finally) moved the MR-53 and connected it to a free 2.5Gbps port on my router, and lo-and-behold, it establishes link at 2.5Gbps and passes traffic. D'oh!
iPerf3 results with MR53 as server and my Intel N5100 with a an I225-V 4-port card as a client:
[ 5] 0.00-10.00 sec 1.01 GBytes 867 Mbits/sec 689 sender
[ 5] 0.00-10.00 sec 1.01 GBytes 865 Mbits/sec receiver
and vice-versa:
[ 5] 0.00-10.00 sec 698 MBytes 586 Mbits/sec 0 sender
[ 5] 0.00-10.01 sec 699 MBytes 586 Mbits/sec receiver
So the results are not any better than over the 1Gbps link. But at least I can stop beating my head about the 2.5G port supposedly not working -- it probably just needs to not advertise 5Gbps support and things might work fine even with the Ubiquity 5GE USB-C dongle.
Note that there still seems something not-quite-right with the Aquantia PHY:
[ 14.300177] qca_85xx_sw_get_eth_dev: Found netdev lan1 for SGMII+ PHY
[ 678.114296] qca_85xx_sw: sgmii_plus_if_change_speed: curr_speed 9c4 curr_duplex 1, curr_version ffff, chip_id ffff
[ 678.141990] AQR chip ID = 0x0000ffff, firmware version 0x0000ffff, speed = 2500
[ 678.146604] qca_85xx_sw: sgmii_plus_if_change_speed: enabling force mode on port 27
Maybe the AQR isn't being reset properly, or is being reset and therefore is missing the firmware? Just seems odd that it can't read out the Chip ID / firmware version registers.
Having abandoned my search for what was "wrong" with the 2.5G interface (TL;DR being maybe nothing, or maybe the fact that it adverises 5Gbps as a capability and so negotiates the higher speed with far ends capable of that), I decided it was about time to see if I can rebase Chris' work onto latest master.
You can find the result here: https://github.com/rkboni/openwrt/releases/tag/meraki-54bba75 (and a draft PR with the updated code here: https://github.com/rkboni/openwrt/pull/10). No promises it will butter your toast (or even not burn it), but it's working for me, so I figured I'd share.
EDIT: Limiting the Aquantia PHY to 2.5Gbps via the max-speed DTS attribute fixed the advertised rates and now allows my 5Gbps interface to successfully connect and pass traffic, so the only thing wrong was the fact that higher speeds were being advertised.
Hi @rkboni,
Since IPQ806x will be moving to kernel 6.18 in the next few weeks, could you please take a look at updating the MR53 patches to work with 6.18?
Thanks!
This probably first requires cleaning up Chris' patches to isolate the MR-53 code from his other additions (Deco M5 support, additional packages, etc.), to make the attempt to stack that on top of the 6.18 diff easier.
I'll take a look at that first and then we can talk about 6.18. But I am definitely not committing to having either done in the next few weeks -- my OpenWRT hacking time has had to be quite opportunistic recently.
Ok, @slow-boat's MR53 support code has been extracted to https://github.com/rkboni/openwrt/pull/11 and a build of the branch is available in https://github.com/rkboni/openwrt/releases/tag/meraki-a095953.
I've also got the ipq806x 6.18 branch at least building w/out any of the above changes: https://github.com/rkboni/openwrt/tree/openwrt-ipq806x-v6.18-master (the code in the PR was missing 1 line in the config-6.18 which caused the builds to fail), but haven't run-tested any of that since I don't have access to my test MR42/52 hardware atm.
I'll see if I can find some time to merge those two work streams and get a MR53-on-6.18 branch going.
@vochong have you tested any of the other Meraki hardware with 6.18?
For what it's worth, I built that branch and installed it on a MR52, and the MR52 comes up without any working network interfaces after reboot. Will need to take it apart and attach serial to debug, but it's not looking good at first blush.
UPDATE: Turns out that issue was specific to the MR52... the 6.18 build installed and ran fine on the MR42, but on the MR52 crashed out due to some (new in 6.18) strict behavior in the pinctrldriver re: sharing pins. I've now got both an MR42 and an MR52 running the 6.18 kernel happily, though definitely not highly tested. Latest build with the fix for the MR52 is available here: https://github.com/rkboni/openwrt/releases/tag/meraki-3a7ae83
Next, I'll have a look at getting the MR53 code rebased on top of that.