Netgear WAX220 support (almost complete)

Alright I've done some more testing and I'm quite sure the Duplex detection is the problem. What I've tested is, I've connected the Access point (WAX220) to a switch with 2.5Gbps port ran an iperf test. The results were as expected +900Mbit TX and RX. On the same switch I've connected the Access point to a 1Gbps port ran the same test and you see a massive difference in transmit and receive +900Mbits/s TX and 370Mbits/s RX The results are show below, also you can see the output of ethtool eth0 which shows the difference between the duplex detection, from full with the 2.5Gbps port to unknown when connected to the 1Gbps port. It's worth to mention all the cables and other hardware are the same during this test but also all settings are identical, only the port on the switch changed.

Created a github issue for this: https://github.com/openwrt/openwrt/issues/14504

## Connected to 2.5Gbps port
root@eva:~# ethtool eth0
Settings for eth0:
	Supported ports: [ TP MII ]
	Supported link modes:   2500baseT/Full
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  2500baseT/Full
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  100baseT/Half 100baseT/Full
	                                     1000baseT/Half 1000baseT/Full
	                                     2500baseT/Full
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 2500Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 6
	Transceiver: external
	Auto-negotiation: on
	MDI-X: Unknown
	Current message level: 0x000000ff (255)
			       drv probe link timer ifdown ifup rx_err tx_err
	Link detected: yes

Connecting to host 192.168.10.66, port 5201
[  5] local 192.168.10.9 port 36150 connected to 192.168.10.66 port 5201
[  7] local 192.168.10.9 port 36158 connected to 192.168.10.66 port 5201
[ ID][Role] Interval           Transfer     Bitrate         Retr  Cwnd
[  5][TX-C]   0.00-1.00   sec   114 MBytes   960 Mbits/sec    0    539 KBytes
[  7][RX-C]   0.00-1.00   sec   111 MBytes   933 Mbits/sec
[  5][TX-C]   1.00-2.00   sec   112 MBytes   936 Mbits/sec    0    539 KBytes
[  7][RX-C]   1.00-2.00   sec   112 MBytes   935 Mbits/sec
[  5][TX-C]   2.00-3.00   sec   112 MBytes   944 Mbits/sec    0    609 KBytes
[  7][RX-C]   2.00-3.00   sec   110 MBytes   926 Mbits/sec
[  5][TX-C]   3.00-4.00   sec   111 MBytes   934 Mbits/sec    0    609 KBytes
[  7][RX-C]   3.00-4.00   sec   112 MBytes   935 Mbits/sec
[  5][TX-C]   4.00-5.00   sec   112 MBytes   944 Mbits/sec    0    609 KBytes
[  7][RX-C]   4.00-5.00   sec   112 MBytes   936 Mbits/sec
[  5][TX-C]   5.00-6.00   sec   111 MBytes   934 Mbits/sec    0    609 KBytes
[  7][RX-C]   5.00-6.00   sec   112 MBytes   935 Mbits/sec
[  5][TX-C]   6.00-7.00   sec   112 MBytes   943 Mbits/sec    0    609 KBytes
[  7][RX-C]   6.00-7.00   sec   112 MBytes   935 Mbits/sec
[  5][TX-C]   7.00-8.00   sec   111 MBytes   933 Mbits/sec    0    609 KBytes
[  7][RX-C]   7.00-8.00   sec   112 MBytes   935 Mbits/sec
[  5][TX-C]   8.00-9.00   sec   112 MBytes   943 Mbits/sec    0    609 KBytes
[  7][RX-C]   8.00-9.00   sec   112 MBytes   935 Mbits/sec
[  5][TX-C]   9.00-10.00  sec   112 MBytes   944 Mbits/sec    0    609 KBytes
[  7][RX-C]   9.00-10.00  sec   112 MBytes   936 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID][Role] Interval           Transfer     Bitrate         Retr
[  5][TX-C]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec    0             sender
[  5][TX-C]   0.00-10.02  sec  1.09 GBytes   938 Mbits/sec                  receiver
[  7][RX-C]   0.00-10.00  sec  1.09 GBytes   936 Mbits/sec                  sender
[  7][RX-C]   0.00-10.02  sec  1.09 GBytes   933 Mbits/sec                  receiver



### Connected to 1Gbps port
Settings for eth0:
	Supported ports: [ TP MII ]
	Supported link modes:   2500baseT/Full
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  2500baseT/Full
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full
	                                     100baseT/Half 100baseT/Full
	                                     1000baseT/Half 1000baseT/Full
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Unknown! (255)
	Port: Twisted Pair
	PHYAD: 6
	Transceiver: external
	Auto-negotiation: on
	MDI-X: Unknown
	Current message level: 0x000000ff (255)
			       drv probe link timer ifdown ifup rx_err tx_err
	Link detected: yes


root@eva:~# iperf3 -c 192.168.10.66 --bidir
Connecting to host 192.168.10.66, port 5201
[  5] local 192.168.10.9 port 36152 connected to 192.168.10.66 port 5201
[  7] local 192.168.10.9 port 36162 connected to 192.168.10.66 port 5201
[ ID][Role] Interval           Transfer     Bitrate         Retr  Cwnd
[  5][TX-C]   0.00-1.00   sec  45.4 MBytes   380 Mbits/sec  209   82.0 KBytes
[  7][RX-C]   0.00-1.00   sec   110 MBytes   926 Mbits/sec
[  5][TX-C]   1.00-2.00   sec  44.0 MBytes   369 Mbits/sec  267   70.7 KBytes
[  7][RX-C]   1.00-2.00   sec   112 MBytes   937 Mbits/sec
[  5][TX-C]   2.00-3.00   sec  43.8 MBytes   367 Mbits/sec  249   55.1 KBytes
[  7][RX-C]   2.00-3.00   sec   112 MBytes   937 Mbits/sec
[  5][TX-C]   3.00-4.00   sec  44.6 MBytes   374 Mbits/sec  170    109 KBytes
[  7][RX-C]   3.00-4.00   sec   112 MBytes   937 Mbits/sec
[  5][TX-C]   4.00-5.00   sec  44.2 MBytes   371 Mbits/sec  219   77.8 KBytes
[  7][RX-C]   4.00-5.00   sec   112 MBytes   938 Mbits/sec
[  5][TX-C]   5.00-6.00   sec  45.1 MBytes   379 Mbits/sec  137   66.5 KBytes
[  7][RX-C]   5.00-6.00   sec   112 MBytes   937 Mbits/sec
[  5][TX-C]   6.00-7.00   sec  42.9 MBytes   360 Mbits/sec  147    139 KBytes
[  7][RX-C]   6.00-7.00   sec   112 MBytes   937 Mbits/sec
[  5][TX-C]   7.00-8.00   sec  45.6 MBytes   383 Mbits/sec  230   65.0 KBytes
[  7][RX-C]   7.00-8.00   sec   112 MBytes   937 Mbits/sec
[  5][TX-C]   8.00-9.00   sec  43.4 MBytes   364 Mbits/sec  223   63.6 KBytes
[  7][RX-C]   8.00-9.00   sec   112 MBytes   938 Mbits/sec
[  5][TX-C]   9.00-10.00  sec  42.0 MBytes   352 Mbits/sec  214   62.2 KBytes
[  7][RX-C]   9.00-10.00  sec   112 MBytes   937 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID][Role] Interval           Transfer     Bitrate         Retr
[  5][TX-C]   0.00-10.00  sec   441 MBytes   370 Mbits/sec  2065             sender
[  5][TX-C]   0.00-10.01  sec   440 MBytes   369 Mbits/sec                  receiver
[  7][RX-C]   0.00-10.00  sec  1.09 GBytes   940 Mbits/sec                  sender
[  7][RX-C]   0.00-10.01  sec  1.09 GBytes   935 Mbits/sec                  receiver

iperf Done.

are you 100% sure of your switch? settings or so?
does your switch show 2.5Gbps when WAX is connected to it?
my WAX is connected to port 5 below:

The switch I'm using is not a manged one so i cannot see the settings on that side, however the output from ethtool on the WAP seems quite clear, as it detects and syncs on Speed: 2500Mb/s Duplex: Full as to the 1Gbit port where it syncs on: Speed: 1000Mb/s Duplex: Unknown! (255)

What are you thinking / missing?

I am not an expert ;-(
don't you have any comp at home with 2.5Gbps NIC?
To connect directly its NIC to WAX and then test iperf3 between them, bypassing the switch.

Unfortunately no I don't but to be fair I don't think that is the problem. line speed, at least the duplex is not detected correctly I've tried different switches (1Gbps) and cables all with the same result Duplex unknown. When connected to a 2.5Gbps port it detects the Duplex full as it should. This also explains the difference in TX and RX.

hello!

Is the recommended build still 23.05.0 (and not 23.05.2)?

new user to this AP and have run into a weird issue where all devices will disassociate and unable to reconnect unless I reboot the AP, which typically happens at least once a day.. I have been on latest stable but just downgraded per the wiki entry (unless it has not been updated yet) to see if that fixes anything

anyone running into something similar?

note: I disabled disassociate on low ack to see if that fixes it, but based on an above comment, this may not remedy this? As mentioned, it fails to reconnect to any devices once they are disconnected. I'll try this with 23.05.0 for now, but will upgrade to the latest point release if this doesn't work.

Howdy! Did you ever find a solution for this? I don't have another AP to roam to, but clients disassociate and fail to reconnect unless I reboot the AP. Honestly have no idea what the root cause is. Tried wpad-openssl for the full suite, but no dice and am not sure that's what is failing. Possibly kernel 5.15 as I have tried stable and snapshots? I would build from source with 6.1 but don't have a means to recover via serial if things go sideways at the moment and am hoping that it's just a config/package issue (if there is a solution).

1 Like

I have a WAX220 on order. What kind of issues should I expect to run into?

Bringing it down to 80Mhz bandwidth solved these issues funny enough.

But that may also be because in NL there is overlap with a radar installation in the country on all bands that support 160Mhz. It was the autodetect of these signals that was likely booting off everyone so the radio could be silent.

1 Like

Ahh.. that might be the ticket! Didn't realize that all 160hz channels overlap with DFS and that's honestly what's probably booting my clients. I am somewhat near an airport so maybe that's why? Still a bit odd that the clients aren't able to associate after the fact, but who knows. Regardless, I'm trying 80hz out at channel 157+ (as the lower range is typically congested) to get out of DFS and hopefully that is the fix.

Separate note, but I also ordered some CAT6 cabling (realized I was still using 5e) to take advantage of the 2.5G switch on my x86 box, in which my understanding is needed for full WAX220 functionality.. comes in tonight so hopefully solving that bottleneck makes my LAN that much quicker (my service is 300down/10up so not lighting fast on that front)! I'm also probably not losing much with not using 160hz channels since I live in a semi-crowded area.

Thanks for the input!

1 Like

@xNUTx 160hz channels were the problem, thanks again. Kind of odd that 80hz channels within DFS do not have the same issue though.

1 Like

You are more then welcome. Just happy to have been of help :blush:

Look at this channel allocation graph.
Stepping one channel into DFS range requires the router to do a channel availability check, before it will even broadcast. 1 channel in may take 30 seconds. 8 channels could take 10 minutes. That down time may look like 'its not working', because, well, it is not.
160MHz width requires DFS no matter what channel you use and it reaches deep into DFS channels.

80MHz, on the other hand, may only step one or two channels into DFS range but it is still likely to need a clear channel check.

For all we know, you were not waiting long enough for the check to complete.

But seriously: 160MHz width is just a punk move/finger in the eye of your neighbor unless you are out in the boondocks.

Most OEM firmware actually turns off DFS, which is why you see so much congestion at the front and end.