I am using the latest stable release on two RT3200s. Both are dumb wifi APs, with a 802.11s mesh between them to provide wifi upstairs. Is there any advantage/improved performance to using snapshots instead? Thanks for the help!
The only advantage that I can think of in your scenario is when you want to enable WED (hardware offloading) on your DUMB AP. This requires the 'bridger' package. I can't find the bridger package on the stable release version repository, but it is available on the snapshot repository.
The stable branch has issues with 802.11ax being slower than 802.11ac, especially on upload and especially as distance and barriers from client to AP increase. Snapshot has a newer mt76 driver that helps with this.
1 Like
Hey Daniel,
Still having the same issues months later, haven't been able to use the router and am considering just tossing it and saving up for a new one, but decided to take one more crack at it before doing that.
Any chance I could grab those ready-made binaries with the kernel debug symbols if you have the time at some point? Not sure what else I can do to chase this issue down, but if you, or anyone else has ideas I'd love to hear them. Sadly my IT background just isn't in this arena and I feel clueless.
Thank you for all the help, either way!
The release may be tagged but it’s not a good idea to install until the official release announcement
See:
6 Likes
Any exciting changes for the RT3200 crew?
1 Like
Aren't you on the master tree?
The 22.03 tree has been split from master more than a year ago.
Don't know why, but changes on 22.03 branch of mt76 were not merged to 22.03 branch of openwrt.
1 Like
Good advice there Tim. Not having gone through the process too often, maybe you could help. It doesn't seem as if much has been added to any of the 22.03.4 release directories since 10th April for the device. From experience, should we expect more changes before the official announcement?
The only reason for changes to 22.03.4 would be if the build turned out to be unstable or to have a sufficiently serious vulnerability that it got pulled.
The main issue now is that not all of the packages have been built so if you try to install things or to build a custom image it will probably fail. Once everything is built the announcement will go out.
2 Likes
If permitted by the regulatory requirements, and thinking only in terms of the hardware, what are the maximum safe to set transmit powers across the various channels on this device? I'm thinking in terms of hardware limitations. Is it possible to set a power that will damage the device (e.g. for those who live in Panama) or is the maximum power that can be set always a power that is safe to set?
1 Like
As it is, OpenWrt restricts RT3200 txpower in the U.S. to 28 dBm on 2.4 GHz (versus 30 dBm allowed), to 23 dBm on U-NII-1 (versus 30 dBm allowed) and 27 dBm on U-NII-3 (versus 30 dBm allowed). Only on U-NII-2 is the full 24 dBm allowed.
The 23 dBm restriction on U-NII-1 is the most annoying, as it restricts the RT3200 to only one decently powered 5 GHz channel of 80 MHz width.
I am confident RT3200 OpenWrt firmware that permits transmitting at the power levels allowed in the U.S. will not "break" my RT3200 and am more than willing to try. I don't think that Belkin would have designed the RT3200/EA8450 to use less than full power.
Using full power may have required placing external RF amplifiers, which means additional cost. Appart from that note that restrictions can also be related to RF noise emitted on neighboring or harmonic bands which would be too high otherwise. Hence we'd have to proof that the stock firmware really behaves differently and permits higher TX power levels despite calibration data stating otherwise (it's not that we would have never seen vendors patching the driver instead of just writing correct calibration data to EEPROM...)
1 Like
Interesting. I went down the rabbit hole a little to understand how the antenna amplification affects your maximum transmission power. Sorry, it's a bit of a random ramble, but I thought I'd share my finding. Apparently the FCC has this to say:
Point-to-multipoint (omni, sector): 1 watt (30 dBm) minus 1 dB for each dB of antenna gain > 6 dBi
I'm going to assume that the antennas inside the RT3200 have a gain of no more than 7dBi? Meaning you would indeed be permitted to ramp it up to 29dBm in the US.
Edit: Actually! There's a Linksys document that states the antenna gain is below 6dBi.
I remember back in the old old days that it was hard to find a NIC that would transmit at more than 100mW, the exception at the time being some InterSil cards that would go up to 200mW. I take it a lot of lower-end wifi hardware is still spec'd to such limits for cost reasons and because it's more than adequate for many home set-ups. Not to mention limiting the interference in densely populated areas where more isn't always better.
2 Likes
My situation would still benefit from having two 80 MHz channels (one for each of two AP's) of at least at 27 dBm. I don't see much loss in 5 GHz throughput dropping from 30 to 27 dBm, but I do see a substantial reduction in download throughput below 27 dBm at intermediate to longer distances. This even though my clients are only transmitting at ~22-23 dBm. Perhaps the control transmissions from client to AP are less demanding than the higher throughput download traffic from AP to client.
Fortunately, I don't have to contend with significant interference on 5 GHz due to its lower range (than 2.4 GHz). There is no competition within 20+ dBm of our AP's on any 5 GHz channels, despite our home being in a Wi-Fi dense environment. I could see that being a problem in an apartment complex though. Everyone seems to scatter mesh routers about these days, even though our neighborhood builder thoughtfully left wired Ethernet back haul behind that needs only termination on a patch panel in the telecom cabinet-a bridge too far for most. 2.4 GHz is another matter. Mesh and ISP provided hardware throughout our neighborhood completely ignores not using 40 MHz wide channels on occupied 2.4 GHz space, and it's all turned up loud.
1 Like
I'm not sure if I'm the only one running into this, but after upgrading to OpenWrt 22.03.4 I'm getting a kernel panic every couple minutes/hours (maybe 4 or 5 times in the last half a day), but the stack trace doesn't make any sense:
<1>[ 2177.211289] Unable to handle kernel NULL pointer dereference at virtual address 000000000000001c
<1>[ 2177.220112] Mem abort info:
<1>[ 2177.222898] ESR = 0x96000006
<1>[ 2177.225943] EC = 0x25: DABT (current EL), IL = 32 bits
<1>[ 2177.231261] SET = 0, FnV = 0
<1>[ 2177.234305] EA = 0, S1PTW = 0
<1>[ 2177.237435] Data abort info:
<1>[ 2177.240315] ISV = 0, ISS = 0x00000006
<1>[ 2177.244141] CM = 0, WnR = 0
<1>[ 2177.247101] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000041721000
<1>[ 2177.253538] [000000000000001c] pgd=00000000401b2003, p4d=00000000401b2003, pud=00000000401b2003, pmd=0000000000000000
<0>[ 2177.264222] Internal error: Oops: 96000006 [#1] SMP
<7>[ 2177.269090] Modules linked in: xt_connlimit pppoe ppp_async nf_conncount xt_state xt_helper xt_conntrack xt_connmark xt_connbytes xt_CT pppox ppp_generic nft_redir nft_nat nft_masq nft_flow_offload nft_fib_inet nft_ct nft_chain_nat nf_nat nf_flow_table_ipv6 nf_flow_table_ipv4 nf_flow_table_inet nf_flow_table nf_conntrack_netlink nf_conntrack mt7915e mt7615e mt7615_common mt76_connac_lib mt76 mac80211 ipt_REJECT cfg80211 xt_time xt_tcpudp xt_tcpmss xt_statistic xt_recent xt_policy xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_esp xt_ecn xt_dscp xt_comment xt_TCPMSS xt_LOG xt_HL xt_DSCP xt_CLASSIFY xfrm_interface slhc sch_cake nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_quota nft_objref nft_numgen nft_log nft_limit nft_hash nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_counter nf_tables nf_reject_ipv4 nf_log_ipv6 nf_log_ipv4 nf_log_common nf_defrag_ipv6 nf_defrag_ipv4 macvlan libcrc32c iptable_raw iptable_mangle iptable_filter ipt_ah ipt_ECN ip_tables hwmon crc_ccitt
<7>[ 2177.269257] compat sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred act_gact xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ipmac ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 ifb sit ipcomp6 xfrm6_tunnel esp6 ah6 xfrm4_tunnel ipcomp esp4 ah4 tunnel6 tunnel4 ip_tunnel xfrm_user xfrm_ipcomp af_key xfrm_algo sha1_generic seqiv md5 echainiv des_generic libdes cbc authenc leds_gpio xhci_plat_hcd gpio_button_hotplug
<7>[ 2177.426081] CPU: 0 PID: 16503 Comm: nft Tainted: G S 5.10.176 #0
<7>[ 2177.433379] Hardware name: Linksys E8450 (UBI) (DT)
<7>[ 2177.438249] pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
<7>[ 2177.444266] pc : 0xffffffc008a61a28 [nf_tables@0000000030e5fcf7+0x24000]
<7>[ 2177.450961] lr : 0xffffffc008a61a18 [nf_tables@0000000030e5fcf7+0x24000]
<7>[ 2177.457651] sp : ffffffc01324b5b0
<7>[ 2177.460957] x29: ffffffc01324b5b0 x28: ffffffc008a5393c
<7>[ 2177.466261] x27: 0000000000000000 x26: ffffffc008a53230
<7>[ 2177.471565] x25: ffffff800205d8d0 x24: 0000000000000002
<7>[ 2177.476870] x23: ffffff80025f8000 x22: ffffff8003ee2c00
<7>[ 2177.482174] x21: ffffff800205d800 x20: ffffff80036f5900
<7>[ 2177.487478] x19: 0000000000000000 x18: 0000000000000000
<7>[ 2177.492784] x17: 0000000000000000 x16: 0000000000000000
<7>[ 2177.498088] x15: 0000007f92b32690 x14: 0003000880020018
<7>[ 2177.503393] x13: 0411a8c000010008 x12: ffffffffffffffff
<7>[ 2177.508698] x11: 0000000000000040 x10: 0000000000000007
<7>[ 2177.514002] x9 : 0000000000000000 x8 : ffffff80025f9000
<7>[ 2177.519306] x7 : 0000000000000000 x6 : 000000000000003f
<7>[ 2177.524610] x5 : 0000000000000040 x4 : ffffffc01324b588
<7>[ 2177.529915] x3 : 0000000000000001 x2 : 0000000000000b20
<7>[ 2177.535220] x1 : 0000000000000000 x0 : 0000000000000018
<7>[ 2177.540524] Call trace:
<7>[ 2177.542966] 0xffffffc008a61a28 [nf_tables@0000000030e5fcf7+0x24000]
<7>[ 2177.549313] 0xffffffc008a5393c [nf_tables@0000000030e5fcf7+0x24000]
<7>[ 2177.555659] 0xffffffc008a53e24 [nf_tables@0000000030e5fcf7+0x24000]
<7>[ 2177.562016] 0xffffffc008900844 [nfnetlink@00000000cd5bbb49+0x3000]
<7>[ 2177.568277] 0xffffffc008900e3c [nfnetlink@00000000cd5bbb49+0x3000]
<7>[ 2177.574533] 0xffffffc0106c7f00
<7>[ 2177.577664] 0xffffffc0106c8190
<7>[ 2177.580795] 0xffffffc010637180
<7>[ 2177.583927] 0xffffffc01063a508
<7>[ 2177.587059] 0xffffffc01063a5c4
<7>[ 2177.590190] 0xffffffc01063a630
<7>[ 2177.593321] 0xffffffc010010ef0
<7>[ 2177.596453] 0xffffffc010010fbc
<7>[ 2177.599584] 0xffffffc010809174
<7>[ 2177.602715] 0xffffffc010809590
<7>[ 2177.605846] 0xffffffc0100025c8
<0>[ 2177.608982] Code: aa0003f7 b40017e0 b1006260 540003a0 (39401001)
<4>[ 2177.615066] ---[ end trace dbc3deb609cf28ad ]---
It's clearly a null reference exception, but how do I get debug information that would help lead to a fix? Do I need to install a package, or do I need to rebuild a kernel from scratch?
22.03.3 was fine.
WiFi 6 performance from this router on my MacBook Pro M2 Pro is out of this world!
Connecting to host 10.1.0.1, port 5201
[ 5] local 10.1.0.165 port 49408 connected to 10.1.0.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 98.6 MBytes 826 Mbits/sec
[ 5] 1.00-2.00 sec 102 MBytes 854 Mbits/sec
[ 5] 2.00-3.00 sec 104 MBytes 872 Mbits/sec
[ 5] 3.00-4.00 sec 103 MBytes 863 Mbits/sec
[ 5] 4.00-5.00 sec 102 MBytes 858 Mbits/sec
[ 5] 5.00-6.00 sec 102 MBytes 858 Mbits/sec
[ 5] 6.00-7.00 sec 104 MBytes 869 Mbits/sec
[ 5] 7.00-8.00 sec 100 MBytes 839 Mbits/sec
[ 5] 8.00-9.00 sec 106 MBytes 887 Mbits/sec
[ 5] 9.00-10.00 sec 102 MBytes 857 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 1023 MBytes 858 Mbits/sec sender
[ 5] 0.00-10.01 sec 1023 MBytes 857 Mbits/sec receiver
iperf Done.
Running OpenWrt SNAPSHOT r22573-72780e3eac with HW and WED acceleration enabled, network is on HE80 mode channel 132 with he_su_beamformer and bss color set.
Congratulations to all the devs working on this project 
PD: WireGuard server is also able of maxing out my 250/250 mbps connection.
EDIT: iperf3 from WireGuard interface over WiFi 6
Connecting to host 10.1.99.1, port 5201
[ 5] local 10.1.99.4 port 49613 connected to 10.1.99.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 48.0 MBytes 403 Mbits/sec
[ 5] 1.00-2.00 sec 45.9 MBytes 385 Mbits/sec
[ 5] 2.00-3.00 sec 46.4 MBytes 389 Mbits/sec
[ 5] 3.00-4.00 sec 47.1 MBytes 395 Mbits/sec
[ 5] 4.00-5.00 sec 46.4 MBytes 389 Mbits/sec
[ 5] 5.00-6.00 sec 47.0 MBytes 394 Mbits/sec
[ 5] 6.00-7.00 sec 44.9 MBytes 377 Mbits/sec
[ 5] 7.00-8.00 sec 46.4 MBytes 390 Mbits/sec
[ 5] 8.00-9.00 sec 45.9 MBytes 385 Mbits/sec
[ 5] 9.00-10.00 sec 47.0 MBytes 394 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 465 MBytes 390 Mbits/sec sender
[ 5] 0.00-10.01 sec 464 MBytes 389 Mbits/sec receiver
iperf Done.
7 Likes
According to FCC test data, this device is indeed measured(and certified) with 995mW at U-NII-3, and 541mW at U-NII-1, with stock firmware.
It's interesting that in 5Ghz, the maximum allowed power in OpenWrt is always seems to be 1/2 of the certified power. Last time I saw this is due to external amplifier. But since we all know there is no external amplifier in RT3200, it's kinda weird.
6 Likes
Thank you for finding that. Antenna gain is below 6 dB too. So U-NII-1 should be good for 27 dBm (versus 23 dBm limit in OpenWrt) and U-NII-3 for 30 dBm (versus 27 dBm in OpenWrt).