You mentioned that in an earlier post that after a reset you got reset to a previous version.
I did do a reset a few hours ago to see if that would happen too. But although my WAX206 did come with an earlier firmware out of the box it got reset to 1.0.4.0.
I don't think that happens at a normal reset. I soldered up the ttl header on my wax206 today and played a bit with luci interface on the original firmware. When tried to flash the 1.0.4.0 Firmware from luci, the bootloader said, that the image was corupt and reflashed to the previous firmware.
Has anybody been succesfull in booting the box via tftp? I wasn't succesfull.
To @frollic@sumo I would be very happy to put a bounty on a flashable image for the WAX206 if there is a posibility. Obviously keeping it open source all the way and available through the OpenWrt project pages.
I have a WAX206 together with an EX6120 and I would like to flash both and start using them with the wifi mesh functionality OpenWrt offers. Extenders suck and most mesh solutions for home application are way too over priced... so I am very prepared to pay a bounty to the one who manages to succesfully port it. In the end I'll likely be cheaper off that way compared to buying the mesh routers by Netgear themselves as example...
I tagged people in here, but honestly, I would like to extend my offer to whoever manages to get the latest OpenWrt version to correctly work on the WAX206.
My bounty offer: 100 USD - payable by wise or paypal, to a person or to the OpenWrt project itself.
I got around to solder and get serial access to the WAX206. After using @sumo git branch to build an initramfs and playing around with the device tree I'm as wise (or dump) as before.
Preface: Unfortunately I don't have much (if any) embedded dev knowledge, I'm more of a (un)trained monkey with some programming and debugging skills.
I was setting the phy-mode and speed keys to the same value as in the Netgear provided device tree. OpenWrt is happy and reports all successs in the logs but no traffic over either lan or wan (`tcpdump -i eth0 -vvv) except DHCP client broadcast for wan (from WAX206 itself). The lan1-4 port do register if the network cable is disconnected or connected (ethtool). ethtool reports the wan port always got a link not matter what.
Looking into the source provided by Netgear for v1.0.4.0 there's a patch that adds handling of the RTL8221B IRQ in the mt753x (file target/linux/mediatek/patches-4.4/1007-822x-irq.patch in WAX_V1.0.40_SOURCE) as an external phy. I assume that's the reason why in their DTS there's ext-phy and ext-phy-reset-gpio in the mac@0 node.
cat /proc/interrupts on Netgears firmware lists the interrupts for RTL8221B:
In the current OpenWrt initramfs there's no IRQ 77.
A few questions:
Does anyone know if something similar is needed to make it work on OpenWrt?
The phy-mode is set to sgmii, is that the right mode even for 2.5GbE (since I read that SGMII only supports speed up to 1+a-bit Gbit)?
*Are there ways to confirm how the RTL8221B is connected without an oscilloscope. It is to assume it's via port 5 of mk7531 but is that for sure?
Is there a way to get the phy ID of the RTL8221B chip used?
Is there a way to see if the RTL8221B chips is recognised and a driver loaded?
And to finish it off: I found a partly similar setup in MTK830 + RTL8221B-VB-CG 2.5G question .The 2.5G port connected mk7531 seems not to work either.
The reset-gpios of course already exist but GPIO_ACTIVE_LOW seems to be correct, not GPIO_ACTIVE_HIGH.
The limitation is that it's either working up to 1GBit speeds (including 10MBit and 100MBit) or 2.5GBit only. Depending of how you set the phy-mode for port 5 of the switch.
The difference between the two branches is just the lines 200 / 201 in target/linux/mediatek/dts/mt7622-netgear-wax206.dts
ethtool does correctly indicate the speed for the wan interface for all possible speeds. But tcpdump -ni wan shows only traffic in the above mentioned configurations.
For the 2.5GBit tests the WAX206 was connected to a QNAP QSW-M1204-4C and for the up-to-1GBit testing a MikroTik CSS610-8G-2S+ was used.
I think it maybe is a bit early to come to that conclusion; assuming that phy-mode = "2500base-x" working at 2.5G only is a software limitation. I don't know if 2500base-x is supposed to do auto-negotiation or not.
But if it can't be solved in time that may be an option.
Did you try autonegotiation with the original firmware? I'm not familar with programming kernel modules, but it looks like the patches, netgear uses in their sources, have some features, the drivers in openwrt 22.03 don't. I can't find any references to "hnat" in the openwrt implemantation of drivers/net/ethernet/mediatek. Maybe a closer look to those drivers would help?
Btw. I succesfully booted the recovery initramfs build from your tree. Please tell me, if there's anything to do to assist you.
Hi @Sailor, speed auto-negotiation does work with Netgears firmware, yes.
Unfortunately I'm not much of a programmer either. But the differences will be huge anyway since Netgears firmware uses swconfig for handling of the switch and now dsa is used. I'm sure there are developers here who know enough about it.
Looking for 2500base-x and sgmii in the 22.03 code it seems to confirm that 2500base-x doesn't do speed auto-negotiation and sgmii does do it but handles only speeds up to 1G. I haven't found too much information which is not behind a paywall (ieee.org). phy-mode = hsgmii would see the obvious choice for port@5 since the RTL8221B can handle that and it's designed for speeds up to 2.5G. But then I'm not sure if the MediaTek MT7531 can handle it, after all that's the port we're configuration phy-mode for.
But with phy-mode = hsgmii there's no network traffic in any mode.
dmesg the second line below should indicate which PHY mode is set and here it is set to phy/ instead of `phy/hsgmii'
[ 3.716915] mt7530 mdio-bus:00 wan (uninitialized): PHY [mdio-bus:07] driver [RTL8221B-VB-CG 2.5Gbps PHY] (irq=POLL)
[ 12.702102] mt7530 mdio-bus:00 wan: configuring for phy/ link mode
I'm not sure which developer to ask, maybe @daniel or @sumo ?
Definitely not an expert on this, but my impression is that the phy and mac can auto-negotiate the interface. So if the phy supports 10,100,1000,2500 and the mac supports sgmii and 2500base-x, then the phy selects 2500base-x if the peer wants 2.5G and sgmii otherwise.
I spent some time learning how the partition stuff works. I am sure this can be improved because I am a noob at openwrt. but I got a flashable .img with this
just trying to hit the 10 character minimum for a post lol
I'm sure I broke conventions I just wanted to get it going
I flashed it both with the stock firmware web ui "firmware update" function and with nmrpflash
fwiw, nmrpflash lets you flash an unencrypted image which is nice for debugging
Am I right in assuming that the image gets flashed to the partition with the label 'firmware' ('Kernel' in the stock device tree)? Have you tried to flash stock back?
After verifying my flash backups I'll give it a got tomorrow or maybe Friday.
yeah firmware partition gets flashed. flashing back to stock with nmrpflash works but I don't think flashing it via the luci webui will work because the fw files are encrypted. I think you would have to decrypt them and flash that.
also I didn't pull in any of the 1gb/2.5gb changes yet. I may screw around with that next since it looks like the interfaces arent being detected right in my image. I need to get VLAN working