I've started working on the device page with some information (see https://openwrt.org/toh/netgear/wax220).
@Flole did you try to build a Netgear factory image? I have a patch locally which does it but still need to test it. With that it should be possible to install OpenWrt with the OEM firmware.
Also, do you know why the order of the mtd partitions are somewhat random?
I haven't tried, I was too impatient for that 
I think they might sign their stuff now....
I am not aware of the mtd partitions beeing in random order.
Thanks for taking the time to populate some of this page. I recently purchased a WAX220 with the intent to put OpenWRT on it, but I've been running into challenges today with TFTP..
Would you mind sharing the factory image file you've got on hand? I'd like to test it out, as I'm still on OEM firmware.
I've uploaded the binaries from a build: https://github.com/agners/openwrt/releases/tag/wax-220-snapshot-20230702. Remember: They are completely untested! It might cause havoc to your firmware installation. You should be able to recover using TFTP.
Thanks for sending these. I tested the .img file from your set by uploading it through the OEM firmware upgrade page. While it did not brick the AP, I was left with OEM firmware that was downgraded from v1.0.3.0 to v1.0.1.2. I flashed a second time while on v1.0.1.2 and no change.
Either it bricked the unit and caused the secondary firmware to load, or it didn't upgrade but still caused a partition swap.
This unit is really easy to open, nothing covering the screws, no thermal paste, so that's really the best way. I have other units which are super weird to open and require like 10 minutes to disassemble, I can understand why on those you want to avoid disassembly. But on this one,.not really.
I appreciate the extra info there. I'm thankful that this device has the backup partition to ease the recovery from failed attempts.
I was able to work out the issues on my end and I've now got the 23.05.0-rc2 sysupgrade (from repo filogic folder) operational. Thanks to everyone for your insights & efforts with this device!
To me the ideal install method would be the fastest & most efficient - using the vendor-provided portal and clicking a few times to select the initial OpenWRT firmware sounds most appealing to me. I agree that opening this device is relatively easy as compared to other devices and I wonder, how would Netgear even know whether we were tinkering inside of it?
@falstaff After initial flash using the 23.05.0-rc2 init image, I tried the sysupgrade firmware from your updated set. This resulted in the portal page not loading. Both SSH and SCP were still functioning, and without changing any local settings I was able to SCP and run sysupgrade command to load the 23.05.0-rc2 version instead. The portal was immediately available after upgrade finished. I have another one of these APs stock/in-box that I don't need to deploy immediately, so I'm happy to continue testing with your firmwares.
The initial factory image really didn't work as I've expected. The WAX220 updates a bit different than the WAX206 I've used as a template. It took me a bit of tinkering, but finally I've figured it out: The WAX220 update seems much simpler: It just requires a sysupgrade tarball packed in the Netgear specific image.
However, it turns out that the resulting image doesn't create a rootfs_data UBI volume, which renders the OpenWrt pretty useless (e.g. there is no default configuration generated, so no network access at all 
One way would be to back a recovery image into the factory image. With that one would have to flash the factory image first, then flash another sysupgrade using OpenWrt. Alternatively something custom would need to be made to create a rootfs_data volume. Any thoughts?
Another thing which is bothering me right now: Restoring via nmrp seems not to work as it stands. It seems that OpenWrt uses too much space for the rootfs_data UBI volume. When the nmrp script tries to create a volume for the stock rootfs, it fails:
Image is encrypted
model: WAX220
region: US
version: V1.0.2.8
dateTime: Wed Mar 22 04:19:35 2023
size: 0x16f0b3f
block size: 0x80
checksum: 0x36b0643c
Decrypt image...
Decrypt finish
ubi0: attaching mtd6
ubi0: scanning is finished
ubi0: attached mtd6 (name "ubi", size 81 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi0: good PEBs: 650, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 6, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 3/1, WL threshold: 4096, image sequence number: 0
ubi0: available PEBs: 2, total reserved PEBs: 648, PEBs reserved for bad PEB handling: 19
Updating volume 'kernel' from 0x46000800, size 0x34e9b4 ... OK
Updating volume 'rootfs' from 0x4634f400, size 0x13a0400 ... ubi0 error: ubi_create_volume: not enough PEBs, only 40 available
ubi0 error: ubi_create_volume: cannot create volume 1, error -28
*** Failed to create volume 'rootfs', err = -28 ***
ubi0: detaching mtd6
ubi0: mtd6 is detached
*** Image not supported! ***
write flash fail.
When the serial console is attached, fixing this is relatively easy: Simply removing the volume using ubi part ubi then ubi remove rootfs_data. But without access to U-Boot, I am not sure if we can do much about it.
I've added code to automatically setup a rootfs_data partition which improves the flow from the OEM firmware to OpenWrt. Also reverting back to the original firmware should now generally work, but note that some special steps are required to get rid of OpenWrt traces entirely.
The process to flash the firmware as well as revert back to the OEM firmware is documented as well now, see: https://openwrt.org/toh/netgear/wax220#oem_easy_installation.
I've uploaded snapshot builds here:
@eth0up note that snapshow builds generally come without luci, so that is expected. Feel free to test the factory.bin files to upgrade via OEM web interface. This time the images are tested and work fine here, so I expect them to work just fine on your end as well.
just came here to say that I got a new WAX220 recently and just tried out your snapshot build @falstaff. Install via OEM GUI with the 10MB factory bin went very well. 
I am having a problem in converting my wax220 to openwrt. These are the steps I followed:
ubi0: attaching mtd6
ubi0: scanning is finished
ubi0: attached mtd6 (name "ubi", size 81 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi0: good PEBs: 650, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 4, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 5/3, WL threshold: 4096, image sequence number: 1664355062
ubi0: available PEBs: 2, total reserved PEBs: 648, PEBs reserved for bad PEB handling: 19
Reading from volume 'kernel' to 0x46000000, size 0x0 ... OK
*** Start update image to backup ***
Reading from volume 'rootfs' to 0x463c1000, size 0x0 ... OK
Updating volume 'kernel_backup' from 0x46000000, size 0x3c1000 ... ubi0 error: ubi_create_volume: not enough PEBs, only 2 available
ubi0 error: ubi_create_volume: cannot create volume 3, error -28
*** Failed to create volume 'kernel_backup', err = -28 ***
ubi0: detaching mtd6
ubi0: mtd6 is detached
Hit any key to stop autoboot: 0
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
This looks similar with the post above.
Any advice on what I am maybe doing wrong? Or where the issue might be coming from?
The bootloader tries to create a backup of your main kernel, which fails due to insufficient space (error -28 translates to ENOSPC).
The script run at first boot after the upgrade creates a data partition which takes 90% of the space (see target/linux/mediatek/filogic/base-files/lib/preinit/75_rootfs_prepare). This should leave enough space for the backup partition, at least per my testing. Also the original firmware is typically larger, so there should really be enough space. I am not sure why on your system this seems not to be the case.
Which stock firmware did you start off with? Did you do a single reboot after the installation of OpenWrt? this makes sure that the "current" firmware is copied to the backup partition (the one you did just the upgrade with).
To recover from the current situation you can erase the whole UBI partition using mtd erase part 6 in the U-Boot command line (enter using Ctrl+C at startup). Then use the nmrpflash flashing method to flash either my OpenWrt factory image or the Netgear image.
Here was the problem, I only installed the factory image and booted it once, I didn't reboot it to give it the chance to create the *_backup partitions as well. Because those partitions were missing, the sysupgrades were ending up with a strange partition layout which caused the failures.
Thank you for your support! Now the device runs 23.05.0-rc2.
There are now official snapshot images of the factory image, so converting a Netgear WAX220 to OpenWrt is a breeze with that image.
The changes have also been backported to 23.05 branch. 23.05-rc3 does not include it yet though. So next rc or release will have have factory images as well 
Hi @falstaff. I’ve got a wax620 and do you think the factory image logic/code, can be ported to the wax620? I did try the factory image for wax218 but it said wrong type in the web ui from stock. If I remember correctly the stock firmware contains a nand image and a md5 file.
We got the wax620 up and running but we’re only missing the factory image solution.
I believe they share a lot, but wax220 is local management and the wax620 is insight/cloud with local too.
We have a pr ready if you want to have a look at the code. https://github.com/openwrt/openwrt/pull/13325/files
Great work by the way 
very helpful!
Hi @Spacebar. I've gained most of the information about the factory image encryption by studying WAX202, specifically what is mentioned in this commit.
Having a quick glance at the WAX620 firmware, it seems that the image has a different header. E.g. this is the header of the WAX220 firmware and WAX202 firmware:
00000000 57 41 58 32 32 30 00 00 00 00 00 00 00 00 00 00 |WAX220..........|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 55 53 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |US..............|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 56 31 2e 30 2e 33 2e 30 00 00 00 00 00 00 00 00 |V1.0.3.0........|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000000 57 41 58 32 30 32 00 00 00 00 00 00 00 00 00 00 |WAX202..........|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 55 53 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |US..............|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 56 31 2e 30 2e 35 2e 31 00 00 00 00 00 00 00 00 |V1.0.5.1........|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
However, unzipping the WAX620 firmware and looking at the image header looks significantly different:
$ hexdump -C nand-ipq807x-apps.img | head
00000000 d0 0d fe ed 02 ba 25 00 00 00 00 38 02 ba 1d 74 |......%....8...t|
00000010 00 00 00 28 00 00 00 11 00 00 00 10 00 00 00 00 |...(............|
00000020 00 00 00 3c 02 ba 1d 3c 00 00 00 00 00 00 00 00 |...<...<........|
00000030 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 |................|
00000040 00 00 00 03 00 00 00 04 00 00 00 2c 64 c3 7f 64 |...........,d..d|
00000050 00 00 00 03 00 00 00 18 00 00 00 00 46 6c 61 73 |............Flas|
00000060 68 69 6e 67 20 6e 61 6e 64 20 38 30 30 20 32 30 |hing nand 800 20|
00000070 30 30 30 00 00 00 00 01 69 6d 61 67 65 73 00 00 |000.....images..|
00000080 00 00 00 01 73 63 72 69 70 74 00 00 00 00 00 03 |....script......|
00000090 00 00 00 0a 00 00 00 00 66 6c 61 73 68 2e 73 63 |........flash.sc|
Maybe it is not even encrypted? I also quickly glanced at GPL source code release of the WAX620, and it seems that only source of the individual packages have been uploaded. In WAX220, the whole OpenWrt build directory was part of the source release.
So, from my quick analysis it doesn't seem similar to the WAX220.
Maybe your right about not encrypted. Binwalk gave no issues. What I get when I extract the .img file.
# binwalk nand-ipq807x-apps.img
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 device tree image (dtb)
6492 0x195C UBI erase count header, version: 1, EC: 0x0, VID header offset: 0x800, data offset: 0x1000
Then if I extract the file I get:
195C.ubi --> ubifs-root/
inside the ubifs-root/ folder
6094848 Jul 13 19:11 img-1480376004_vol-kernel.ubifs
0 Jul 13 19:11 img-1480376004_vol-rootfs_data.ubifs
26030080 Jul 13 19:11 img-1480376004_vol-ubi_rootfs.ubifs
And by looking at the nand.sh script inside squashfs-root/ in ubi_rootfs
# Check if passed file is a valid one for NAND sysupgrade. Currently it accepts
# 3 types of files:
# 1) UBI - should contain an ubinized image, header is checked for the proper
# MAGIC
# 2) UBIFS - should contain UBIFS partition that will replace "rootfs" volume,
# header is checked for the proper MAGIC
# 3) TAR - archive has to include "sysupgrade-BOARD" directory with a non-empty
# "CONTROL" file (at this point its content isn't verified)
#
# You usually want to call this function in platform_check_image.
#
# $(1): board name, used in case of passing TAR file
# $(2): file to be checked
nand_do_platform_check() {
local board_name="$1"
local tar_file="$2"
local control_length=`(tar xf $tar_file sysupgrade-$board_name/CONTROL -O | wc -c) 2> /dev/null`
local file_type="$(identify $2)"
[ "$control_length" = 0 -a "$file_type" != "ubi" -a "$file_type" != "ubifs" ] && {
echo "Invalid sysupgrade file."
return 1
}
echo -n $2 > /tmp/sysupgrade-nand-path
cp /sbin/upgraded /tmp/
return 0
}
Inside the tar file from Netgear, it contains 4 files:
# cat metadata.txt
WAX620 WAX630
# cat nand-ipq807x-apps.md5sum
cc8a9d0e88e8bed3fef7673e64fbbc60 nand-ipq807x-apps.img
# cat version
WAX620-630_V9.5.0.21
nand-ipq807x-apps.img
So maybe we need to create a similar file, to do an upgrade. This is out of my knowledge, so maybe all of this information is useless anyway 
And I don't mean to talk about wax620 in a wax220 thread, so I'll continue in the wax620 thread I was just curious, and thanks for your input on this.
@falstaff I think I have a slightly different issue with *** Failed to create volume 'kernel_backup', err = -28
I have used OEM flash page for 3 WAX220s without issue but this 4th one isn't working quite right. After flashing the 10MB .img the AP came up with OpenWRT, and then after doing sysupgrade the AP went in to a bootloop. Hooked up to the serial port and see the kernel_backup issue. There are some differences from bitweaver's kernel_backup error.
Some include:
ubi0 user volume is only 3 instead of 4
rootfs is different location, 'rootfs' to 0x463e0000 instead of 0x463c1000
kernel backup size, 'kernel_backup' from 0x46000000, size 0x3e0000 instead of 'kernel_backup' from 0x46000000, size 0x3c1000
Not sure if it matters since still only 2 PEB available.
I am unable to use nmrpflash. The ethernet broadcasts fine and the WAX hears it and sends the download but the WAX errors with configuring error timeout. With both openwrt and OEM image.
I am able to TFTPBOOT an initramfs binary and bootm. OpenWRT comes up, and I can sysupgrade -n the recovery itb. Actually I have to use -F to force it for a metadata error. OpenWRT comes up again and when I try to do a sysupgrade after the reboot the bootloop starts. I did try mtd erase part 6 but that command doesn't errors. New to the forum so not sure if I paste full logs here or external site. Hopefully I have just overlooked something easy, but without nmrpflash as an option I'm curious as where to go next.
tftpboot the initramfs with bootm
sysupgrade -n -F openwrt-mediatek-filogic-netgear_wax220-init
ubi0: attaching mtd6
ubi0: scanning is finished
ubi0: attached mtd6 (name "ubi", size 81 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi0: good PEBs: 650, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 2, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 0
ubi0: available PEBs: 3, total reserved PEBs: 647, PEBs reserved for bad PEB handling: 19
Reading from volume 'kernel' to 0x46000000, size 0x0 ... OK
*** Start recover image from backup ***
ubi0: detaching mtd6
ubi0: mtd6 is detached
sysupgrade openwrt-mediatek-filogic-netgear_wax220-squashfs-s
ysupgrade.bin
ubi0: attaching mtd6
ubi0: scanning is finished
ubi0: attached mtd6 (name "ubi", size 81 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi0: good PEBs: 650, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 0
ubi0: available PEBs: 2, total reserved PEBs: 648, PEBs reserved for bad PEB handling: 19
Reading from volume 'kernel' to 0x46000000, size 0x0 ... OK
*** Start update image to backup ***
Reading from volume 'rootfs' to 0x463e0000, size 0x0 ... OK
Updating volume 'kernel_backup' from 0x46000000, size 0x3e0000 ... ubi0 error: ubi_create_volume: not enough PEBs, only 2 available
ubi0 error: ubi_create_volume: cannot create volume 3, error -28
*** Failed to create volume 'kernel_backup', err = -28 ***
ubi0: detaching mtd6
ubi0: mtd6 is detached
MTD ERASE
MT7986> mtd erase part 6
MTD device part not found, ret -19
MT7986>
EDIT: Nevermind about the nmrpflash. I was able to erase ubi part with
mtd erase ubi
then nmrpflash worked. Back in business.
Bytes transferred = 10486296 (a00218 hex)
nmrp tftp upload complete.
write firmware...*** Upgrading Firmware ***
*** Loaded 10486296 (0xa00218) bytes at 0x46000000 ***
Image is encrypted
model: WAX220
region: US
version: V1.0.0.0..r23486+1
dateTime: Thu Jan 1 00:00:00 1970
size: 0xa00000
block size: 0x20000
checksum: 0xb2d171fa
Decrypt image...
Decrypt finish
ubi0: attaching mtd6
ubi0: scanning is finished
ubi0: empty MTD device detected
ubi0: attached mtd6 (name "ubi", size 81 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi0: good PEBs: 650, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 0, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 0/0, WL threshold: 4096, image sequence number: 0
ubi0: available PEBs: 627, total reserved PEBs: 23, PEBs reserved for bad PEB handling: 19
Updating volume 'kernel' from 0x46000800, size 0x3b35a8 ... OK
Updating volume 'rootfs' from 0x463b4000, size 0x43c400 ... OK
ubi0: detaching mtd6
ubi0: mtd6 is detached*** Firmware upgrade completed! ***
upgrade firmeare success.
Saving Environment to MTD... Erasing on MTD device 'nmbm0'... OK
Writing to MTD device 'nmbm0'... OK
OK
reset config default succes.
nmrp closing...
I am not sure if this is the right thread for asking this, but did anybody manage to revert from Openwrt to OEM Firmware with nmrpflash?
When i try it uploads the firmware to the wax220 but then asks for another upload in an endless cycle, which looks like it doesn't like the OEM image (i tried different versions).
When i interrupt that cycle nothing was flashed.
I did manage to flash the openwrt-factory image with nmrpflash.
I tried the current version of nmrpflash and the ubuntu version.