OpenWrt support for WAX206

I have the capacity here, just looking for a quick way to get testing.

@dhewg I have to read up on what the rules are for having a new device in, not sure we got enough feedback of people running it.

Is everybody happy with the partition layout? Right now the free space on the writable partition is only about 15Mb, even less if you compile some kernel modules into the kernel. It is fine for me since it's going to work as an AP only. But what do others think about it?

And I set the max kernel size to 4096k like in WAX202 (for more writeable space), @sumo set it to 6144k initially. I don't know if that poses a potential problem.

@nigelterry I can provide the image(s) I use for you BUT no kernel modules will be installable from SNAPSHOT and every package which depends on a kernel module - VPN, Wireguard, ... - will fail.
The image I use got luci-ssl installed plus a few command line tools like mdio-tools and nand-utils. Would that work for you?

2 Likes

Fine by me, but I'm also setting it up as an AP..

Working 2.5gbe port is kind of a deal breaker for me though.

It's more than good enough for a PR!
All open questions are better handled there during review.

And the partition layout looks good I think, this should allow to recover and reflash the vendor firmware.

The bigger related question is if the OpenWrt nand driver is compatible to whatever is being used in the vendor fw, but that too can be discussed in a PR.

From https://openwrt.org/toh/linksys/e8450:
Since 2021-08-27, it is no longer possible to keep the default vendor flash layout (a.k.a. “non-UBI”), as it contains ECC errors out of the factory, and these errors are not compatible with the new SPI-NAND driver, that means you cannot install the non-UBI firmware (*.bin).

Which then changed with https://github.com/openwrt/openwrt/commit/02351861824a13ed158db1ef59aede2db6ba7568
So there're two different firmware variants for the same device. This could be done for wax206 too, if required due to the nand driver, or wanted to get more space for OpenWrt.

4 Likes

I have just moved and I am still getting all my local machines set back up. Once I get some time later this week I will try run a build based off of your branches and give it a test drive.

I do still need to obtain a 2.5GB ethernet sfp+ to test out the wan port. However, I do plan to use this as just an AP with Vlans tied to specific SSIDs.

This is also a good time to get a device page together for the wax206 in the wiki. I can take this on once I get my editor account created if no one else gets to it first.

4 MB may pose a problem after some time.

Years ago 1 MB was too little for kernel, then 1.5 MB, then 2 MB and now 3 MB is too little..
(see https://github.com/openwrt/openwrt/commit/15309f5133d55e92bec3ed91dfb3ac9d124f6a96 )

4 MB will come next...

When introducing a new device, take 6 MB if possible. Changing it later leads into uncomfortable factory image flashes.

Ps. see this for background evidence about kernel & firmware size growth.
https://openwrt.org/supported_devices/432_warning#analysis_of_firmware_size_growth

3 Likes

Ok, I see. The WAN port does work in 2.5G mode if set phy-mode of port 5 to 2500base-x in the device tree, but then it won't work with any other speed, like 1G.

I don't mind, but others might. :slight_smile:

Alt create two images.

As @lynxis managed to get automatic switching depending on the link speed of similar RealTek 2500Base-T phy working when connected directly to the SoC's GMAC, I'm sure we can get the same thing working also with such a phy being connected to port 5 of the MT7531 switch -- lynxis has pointed out to me a while ago that the SGMII units of MT7622, MT7986 and MT7531 seem to be identical, which for now turned out to be true. While the code cannot (yet) be directly shared for structural reasons, it is quite easy to implement what ever works for the GMAC also for MT7531 and vice-versa.

7 Likes

That does sound promising @daniel. l'll prepare a PR at the weekend if nobody does it before.

1 Like

This device sounds promising; is there ac or ax support on 2.4GHz and no 160 MHz support on 5 GHz like on the WAX202? On the specsheet was somewhere mentioned ac on the ~2400 frequencies but I've also head otherwise. I'm especially asking because of some walls it would have to go through in my case.
Has also someone by occasion measured the power draw on normal usage?
And a last thing I was wondering for the people that teared it down: Can the bottom stand be removed and the router being placed horizontally without issue?

There is no real way to remove the base, it afaik and can see isn't intended to be put on it's side.

Wifi: For 2.4GHz the mt7622 is used and it shows up as "MediaTek MT7622 802.11bgn", I'm afraid no ac or ax support there.

The 5GHz shows up as "MediaTek MT7915E 802.11acaxn". According to iw phy1 info it does support 160 MHz but I was not able to get it to work. And according to shoutwiki WAX206 there are 2 chips for the 2nd radio MT7915AN and MT7975AN. The second one should support it. Long stories short: I'm no help here.

Power draw: Not in daily use but while testing, two devices - an iPhone 11 Pro and an OnePlus 9 - connected on Wifi both on 5GHz it draws around 5.8 to 6.8W while idle or light web browsing.
Running iPerf3 client (Upload, 5 streams, ~650Mbits/s) from the iPhone to a PC behind the WAN of the WAX206 it draws around 8.2W. Measured with a Voltcraft SEM6000

Bottom Stand: I do have to disagree with @xNUTx on that. At least with the EU model the bottom stand is secured with two screws. I have removed the screws and could removed the stand. The underside basically looks like the top short side. The WAX206 is laying on the side on the table connected via TTL USB adapter to my computer. The internal antennas are places at the top short side of the WAX206. Reception may be better if you place it standing up.

Same experience here, but it's also the EU model.

Hi all,

While preparing for the pull request I checked a few things to make sure it works as it should and a question came up about the flash layout (which is very similar to WAX202 with 128MB flash):

The current layout ends at 0x7000000 which is at 112MB. According to the documents around the web the WAX206 got a 256MB flash chip (Toshiba TC58CVG1S3HRAIJ). What happened to the missing 128MB+?

1 Like

Mine's packed down, but aren't there two kernel and root FS partitions?

There are two firmwares, yes but that is all included, see the stock layout:

stock nand layout
[    1.374329] Recognize NAND: ID [
[    1.377391] 98 eb
[    1.379402] ], [TC58CVG1S3HRAIJ], Page[2048]B, Spare [128]B Total [256]MB
[    1.386547] nand: device found, Manufacturer ID: 0x98, Chip ID: 0xeb
[    1.392903] nand: Toshiba SNAND 256MiB 3,3V 8-bit
[    1.397608] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 128
[    1.405264] [NAND]select ecc bit:12, sparesize :112
[    1.410963] [BBT] BMT.v2 is found at 0x7ff
[    1.415097] 18 ofpart partitions found on MTD device MTK-SNAND
[    1.420928] Creating 18 MTD partitions on "MTK-SNAND":
[    1.426066] 0x000000000000-0x000000080000 : "Preloader"
[    1.432563] 0x000000080000-0x0000000c0000 : "ATF"
[    1.438102] 0x0000000c0000-0x000000140000 : "Bootloader"
[    1.444585] 0x000000140000-0x0000001c0000 : "Config"
[    1.450724] 0x0000001c0000-0x0000002c0000 : "Factory"
[    1.457649] 0x0000002c0000-0x0000028c0000 : "ImageA"
[    1.515958] 0x0000002e0000-0x0000028c0000 : "Kernel"
[    1.578449] 2 fit-fw partitions found on MTD device Kernel
[    1.583937] 0x0000002e0000-0x000000580000 : "kernel"
[    1.593026] 0x000000580000-0x0000028c0000 : "rootfs"
[    1.647508] mtd: device 8 (rootfs) set to be root filesystem
[    1.686080] 1 squashfs-split partitions found on MTD device rootfs
[    1.692261] 0x000001d20000-0x0000028c0000 : "rootfs_var"
[    1.714221] 0x0000028c0000-0x000004ec0000 : "Kernel_backup"
[    1.775087] 0x000004ec0000-0x0000056c0000 : "CFG"
[    1.791387] 0x0000056c0000-0x000005ac0000 : "RAE"
[    1.802130] 0x000005ac0000-0x000005bc0000 : "POT"
[    1.808707] 0x000005bc0000-0x000005fc0000 : "Language"
[    1.820002] 0x000005fc0000-0x0000061c0000 : "Traffic"
[    1.832321] 0x0000061c0000-0x0000062c0000 : "Cert"
[    1.838990] 0x0000062c0000-0x0000063c0000 : "NTGRcryptK"
[    1.846161] 0x0000063c0000-0x0000068c0000 : "NTGRcryptD"
[    1.858911] 0x0000068c0000-0x0000069c0000 : "LOG"
[    1.887554] mtdoops: ready 0, 1 (no erase)
[    1.891648] mtdoops: Attached to MTD device 19

Maybe the flash size is not right and it's only 128MB; or only 128MB usable.

Could try to read from the 128mb+ space, see if it'll let you...

I moved the kernel and ubi to 0x7000000 in the devicetree, booted into initramfs and wrote the sysupgrade image. It did let me write it and if I enter u-boot console it let me nand read from 0x7000000 with the usual size to the standard address. But check_image is not successful. I assume not successfully written.

Maybe I give it another go tomorrow.

Thank you for all these details, already helped much.

Would just need one more opinion before deciding for one: Since I'd need to pass through 2-3 walls/2 floors, would it rather make sense setting up a WAX202 with AX (or N) support on 2.4GHz (but probably only 1.5db power) or the WAX206 on 5GHz AC/AX (or if it's too far away 2.4GHz N)?
Has maybe someone tested (or could test) the working range on 2.4GHz and 5GHz behind some walls? There was also a discussion for that on the WAX202

(Or am I completely wrong and should consider something else as a semi-dumb ap)