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).
Hi all,
Does anybody has ideas on how to reduce power consumption on Belkin RT3200 router? Other than powering off WiFi, of course. Curious about the options.
Genuinely curious about this... do you find power consumption to be costly with this device? Or are you seeking opportunities to lower power consumption just for the sake of it? Just curious as to the motivation behind the ask.
I think I saw you had posted something about this earlier in this thread, though I don't recall the details. I assume you've tried switching to ondemand governor?
Not that I recommend it, but you could force your max CPU frequency to something like 600mhz, I suppose:
echo 600000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
Just bear in mind, performance and power generally scale together. So you will sacrifice performance to save power.
Wouldn't using hardware offloading and friends help?
This is a belkin rt3200 device. I have searched this thread and the internet but could not find anyone having this problem. I don't have a serial port so I don't have much diagnostic information. Decided to post here to see if anyone had this problem before connecting a serial port.
Does not matter if I ssh into the device and type "reboot" or use the web interface to "reboot" the device, then result is the same the power light goes off and the device is off. I have to turn the switch off and on to turn the device on. I have another belkin rt3200 and it works fine with the "reboot" command. Now for the crazy part when I type "poweroff" it works like a reboot on both devices. So the work around is to use "poweroff" for the device that won't reboot with the "reboot" command.
I removed this device as the router and made it a dumb access point. So not a big deal if does not reboot. Otherwise the device works fine. This is only a problem with upgrades. After a firmware upgrade I have to power cycle the device with the switch.
Strange.
1 Like
Very. Can you check the versions of busybox on both machines? That might show something.
$ opkg info busybox
Package: busybox
Version: 1.35.0-5
$ ls -l /sbin/poweroff /sbin/reboot
lrwxrwxrwx 1 root root 14 Apr 9 05:27 /sbin/poweroff -> ../bin/busybox
lrwxrwxrwx 1 root root 14 Apr 9 05:27 /sbin/reboot -> ../bin/busybox
Differences there might suggest something.
I wouldnt say its costly. It is fairly efficient but i use WiFi on my routers and wan, the rest is not needed so i am curious what can be done to lower it.
I am using ondemand governor however changing governors are quite sensitive and might lead to weird behaviour so i tend not to change them if i dont have to. I was more referring to some neat tricks like disabling lan and usb ports etc.
I use hw offload since i have no need for sqm at this time. I dont have WED enabled yet, unsure would that change things (and introduce unnecessary instabilities?).
I definitely understand the concern. However, the issue with the governors in the past, AFAIK, was around the CPU speed being set too low during boot, and the resulting undervoltage due to that would cause the boot process to hang. You can still mitigate the potential for this issue by setting the scaling_min_freq, if you choose to pursue that route.
I wouldn't personally recommend enabling WED at this point because it seems to be exhibiting odd behavior and there is a lot of discussion around it in more recent posts here:
I will say, when I have seen WED working properly, it is quite impressive the positive effect it has on CPU load in the TX direction (from the AP). So once it is working more smoothly and consistently, I would definitely keep it on your list of efficiency tweaks.
2 Likes
Speaking of, do you expect to see WED enabled by default/GUI toggle in the next major OpenWrt release for RT3200 devices? I have tried it however for low demand users it can be a challenge to test (my whole household is low demand network wise) so i cannot be sure how effective it will be in the future with this option enabled. This router is too powerful for me and I struggle to saturate the connection easily to properly test it. Brief saturation, while downloading single large files from static remote locations (eg. DVD iso images from FTP servers), is possible however in 2023. most of consumer services are fairly optimized so saturation is not easily achievable for me. We do use download mostly in my household so it will help in the future however i have no clue how much.
except for Zoom: that thing is really bandwidth hungry sometimes, i cannot say i liked it when i used it