Yes every iPhone since the 11 supports 802.11ax.
So:
11 and derivatives
SE 2020
12 and derivatives
13 and derivatives
SE 2022
Yes every iPhone since the 11 supports 802.11ax.
So:
11 and derivatives
SE 2020
12 and derivatives
13 and derivatives
SE 2022
I tried this by system upgrading from RC6 and was hit with nothing but issues on wifi so I downgraded back to RC6...not sure what the issue was maybe some of my installed packages not sure...
how do you get up to 28 dBm? max I see is 20
All I needed to do was to set the country code for the Wi-Fi to Bolivia
awesome ty!
Do you live in Bolivia?
Don't set codes for anything else than the country your device is located in.
@giuliomagnifico i guess you have sent the wax202 back already, right? if you still have it, have you tried using ax on the 2.4GHz band? 2.4GHz is supposed to reach higher distances than 5GHz. So you could compare 802.11n (2.4GHz) vs 802.11ax (2.4GHz).
By the way found this website quite helpful:
Estimated Attenuation at 900MHz:
The website has a factual error: > -30 dBm = Overloaded, not Excellent.
I still have it here, but on 2.4ghz I have many other (slower) iot devices, I can’t use it.
Another important parameters is the SNR.
Does adjusting Tx power values for the WAX202 actually have a real effect on the Tx power ?
I've had some devices running OpenWrt where changing Tx value doesn't actually change Tx power
The reason is I have my router in my office and I generally like to have it on lowest power - only enough for iPhone/iPad/music streamer to have WiFi.
For other rooms I have another AP at other end of the house.
WAX202 looks like a future proof device, especially as I get AX devices in future.
Apart from range, AX works fine with WAX202? I read that AX with Belkin RT3200 is having issues
As far as I can tell, yes support is there. The Wi-Fi 6 is real and also the speed, I’m getting 720 Mbps staying right in front of the router.
I’m running the latest 22.03 rc.
If you can find some WAX202 cheap enough I would buy two of them and try to cover my house. But once the signal goes through a wall you’re probably getting worse speeds than Wi-Fi 5.
Fantastic. This must be one of the best 2022 WiFi 6 routers with OpenWrt
Great price too
Yes the power works (indeed I have better speed with 18/20db), all my clients are ax so it could have been useful but it has a limitate signal coverage, you have to stay in the same room of the device or use lots of them.
I prefer to use only one device, so I keep the R7800 and I’ll buy a better ax device when it will be supported by OpenWrt.
Once I come back from vacation I’ll test the wireless signal a bit more.
We’ll surely have very similar results, but who knows, maybe we have different walls or something.
Does this help WAX202 ax performance?
There seems like an issue with custom images that are greater than 32MB in size. While the image itself will flash, the overlay partition will fail to mount, causing the device to stuck without network and other configuration. In the serial console in dmesg, this message shows up in the logs:
[ 10.888198] UBIFS error (ubi0:1 pid 639): ubifs_mount: too few LEBs (12), min. is 17
[ 10.897479] mount_root: failed to mount -t ubifs /dev/ubi0_1 /tmp/overlay: Invalid argument
Also, OpenSSL performance on this device seems to be very poor:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 8933.82k 11133.41k 11888.10k 12047.48k 12146.48k 12105.65k
aes-256-cbc 7255.65k 8643.72k 9081.03k 9202.39k 9237.09k 9237.09k
aes-128-gcm 5340.70k 5958.08k 6134.47k 6180.06k 6191.63k 6188.91k
aes-256-gcm 4687.56k 5160.02k 5292.06k 5326.16k 5334.33k 5334.33k
chacha20-poly1305 10426.08k 17191.17k 19827.50k 20617.78k 20861.02k 20722.22k
With 4 threads:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 18897.57k 22915.64k 24208.50k 24558.99k 24644.04k 24619.55k
aes-256-cbc 15064.52k 17677.18k 18446.37k 18632.38k 18694.63k 18659.25k
aes-128-gcm 11115.05k 12148.18k 12442.37k 12508.45k 12519.34k 12524.78k
aes-256-gcm 9726.41k 10498.28k 10719.34k 10779.56k 10793.84k 10782.96k
chacha20-poly1305 22287.54k 36070.36k 41072.10k 42526.96k 42949.49k 42832.46k
The poor crypto performance probably means you will get very bad speeds if you try to run a VPN server on it. You will probably get less than 40Mbps when running AES and 150Mbps when running ChaPoly. Merging https://github.com/openwrt/openwrt/pull/10238 had no discernable difference on software crypto.
Here are some comparisons - with a MobiPromo CM520-79F being powered over 5v USB (Qualcomm IPQ4019):
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 13523.11k 16830.59k 18100.82k 18476.37k 18587.65k 18606.76k
aes-256-cbc 10715.88k 12802.03k 13612.63k 13802.50k 13899.09k 13904.55k
aes-128-gcm 9546.79k 11806.51k 12463.36k 13248.51k 13459.46k 13467.65k
aes-256-gcm 8124.64k 9681.92k 10009.51k 10660.18k 10827.09k 10807.98k
chacha20-poly1305 14596.79k 24982.31k 37955.84k 41054.21k 42218.84k 42330.79k
With 4 threads:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 54092.12k 67181.38k 72410.71k 73789.10k 74189.48k 74072.06k
aes-256-cbc 43079.24k 51249.75k 54357.59k 55232.51k 55492.61k 55503.53k
aes-128-gcm 38163.24k 47167.91k 49743.45k 52922.71k 53641.22k 53690.37k
aes-256-gcm 32396.84k 38619.46k 39817.64k 42515.11k 43119.52k 43032.19k
chacha20-poly1305 57820.09k 99661.76k 151623.68k 163834.88k 168296.45k 168465.75k
The USB-powered router consistently performs better in crypto operations than the WAX202.
And on the R7800:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 54848.84k 75935.47k 86117.29k 83540.99k 88880.47k 87444.84k
aes-256-cbc 43984.02k 56890.33k 62755.75k 61962.92k 63834.79k 63543.79k
aes-128-gcm 41883.99k 53554.67k 58530.99k 62744.23k 63400.62k 61909.67k
aes-256-gcm 35236.44k 43642.69k 46324.05k 49721.34k 50686.63k 50113.19k
chacha20-poly1305 43963.53k 101907.78k 235945.90k 267032.23k 276720.30k 266807.98k
With 2 threads (R7800 only has 2 cores):
aes-128-cbc 105247.46k 146135.42k 163082.33k 162201.26k 169446.06k 166057.30k
aes-256-cbc 83660.43k 110448.17k 121007.19k 119213.64k 122874.54k 117009.07k
aes-128-gcm 78463.50k 102965.59k 113500.59k 119983.10k 118311.59k 116976.30k
aes-256-gcm 68600.32k 84870.91k 89156.35k 95366.49k 98342.23k 97053.35k
chacha20-poly1305 89263.51k 193036.31k 436408.06k 515102.04k 520421.38k 525505.88k
As you can see, the R7800 has a much more powerful processor than the WAX202. The WAX202 does have a pretty decent radio performance when broadcasting at 28dBm, with throughput very similar to the R7800 at a distance. If you are contemplating an upgrade, I would probably stick with the R7800 for now.
If you haven't already you could try and see if this commit improves your results:
The WAX202 SoC (MT7621) supports four 4 threads, but it still only has two 880 MHz MIPS cores. It's not too surprising that it's encryption performance only doubles with four threads versus one, or that its quite low overall compared to ipq4019 (four true ARM cores) or ipq8065 (two fast ARM cores).
The endearing qualities of the MT7621 are its low cost and OpenWrt supported hardware offload capability. I'd still consider a MT7621 device if my ISP service were slow (~100 Mbps or less); or no features I wanted interfered with hardware offload (e.g., SQM), CPU cycles needed for WiFi, or required a strong CPU (e.g., VPN). It's not a bad dumb AP option.
However, the MT7621 is not particularly well suited to high VPN or SQM throughput. For VPN performance see: OpenVPN Performance and Wireguard Peformance. When I used a MT7621 ER-X as my gateway, it struggled to shape ~200 Mbps with fq_codel/simple or ~100 Mbps with CAKE. I've since replaced the ER-X with a NanoPi R4S paired with a Netgear GS308T switch - both running OpenWrt.
wireguard shouldn't be performing that well on mt7621. I guess the team optimized the hell out of it.
yeah looking at the numbers again they seem nonsensical.
I think the ethernet driver is contributing to the speed.
qca9563 for example, has a faster CPU but worse ethernet driver.