Where did you hear it was set to 100mw by default?
Where did you hear it was set to 100mw by default?
The FCC ruling prevents users with routers manufactured after mid 2017 from changing the transmitting power.
Unless something has changed, there is no way to bypass this and set the radios to the max 100mW for transmitting, as it’s hard coded for a specific value, and while I can’t recall what that value is, it’s not 100mW.
It's actually 1 watt (1000mw) https://www.air802.com/fcc-rules-and-regulations.html
There's no dates listed as to when that was last updated, and 1W was the previous bar prior to the new regulations that took effect in 2017. Most, if not all, routers manufactured for the US after the regulation took effect have non-customizable power transmit values that are hard coded.
It varies by channel:
I recall reading that the manufacturers had to lock it down. The options were to stay propitiatory so than open source software couldn't be used, or store the settings in ROM.
The copyright is listed as 2006-2018. That would be the last time it was edited, which makes it as old as 01/01/2018.
Not that this really matters now, but here is some history as to why the FCC did the lock down. We had, and still do have, community members that purposefully take wifi power levels outside of approved specifications.
As someone who maintains a FCC radio certification, the FCC take this very seriously, and it doesn't surprise me that they took action.
That's the site's copyright, not that page's... You are aware private citizens cannot copyright information put forth by a governmental agency, such as the FCC, right?
You be you, friend. I'm out of this.
The regulatory bodies set the maximum allowable transmit power, they do not mandate that the device has to use that, and only that, transmit power. The device driver should be allowed to use a lower power, but mwlwifi does not allow this. IC (CA), and FCC (US), pretty much dictate the same regulations (something to do with a shared ~8900 km border), and from a rango:
root@bsaedgy:~# iw reg get
global
country CA: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
(5470 - 5600 @ 80), (N/A, 24), (0 ms), DFS
(5650 - 5730 @ 80), (N/A, 24), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
phy#1
country CA: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
(5470 - 5600 @ 80), (N/A, 24), (0 ms), DFS
(5650 - 5730 @ 80), (N/A, 24), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
phy#0
country CA: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
(5470 - 5600 @ 80), (N/A, 24), (0 ms), DFS
(5650 - 5730 @ 80), (N/A, 24), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
what I get from mwlwifi is dictated by the channel I choose. For example choosing 149, yields 30 dBm TX-power(and 30 dBm == xxxx mW , and only that is allowed. There is no reason that the device should be shouting at something 2 floors down, when that device cannot shout back.
This is of course true on all wrtpac devices with the baked in eeprom power tables, rango, and V2 flavours of the other units. This discussion keeps on happening.
Exceeding the FCC regulation was never my intention of bringing this up. Want to be able to reduce the power output because I don't need the full power. Just a like a CPU would scale down as well.
Scaling works fine on the R7000 and R7800. The WRT3200ACM for example, is fixed at a higher limit at the driver level, I would like to reduce it as needed.
Not sure what the actual WRT series is fixed at (doubt it's 1000mW that would be absurd), but I'm running the R7000 right now at 25mW and it works great, low power output for a smaller apartment, etc. WRT routers should be able to do this as well, that is all.
Yes, I understood from your original response to the Frequency Scaling link above that your desire was to lower the TX power from the mwlwifi default.
My post was in response to the misconception that the reason behind mwlwifi fixing the TX power at the maximum was due to a dictate by some regulatory body, and not due to a design decision behind mwlwifi.
fwiw, the driver can be modified to accept a DTS powertable rather than hardcoded (quite trivially, I’ve got a patch lying around somewhere) so maybe it can be modded to allow dropped power levels as well.
I never actually used a spectrum analyser to check if it was obeying what I set though.
So, using the latest build (with slabinfo enabled so I can actually use slabtop and /proc/slabinfo), it looks like skbuff_head_cache is leaking memory, although even that doesn't account for most of the memory leaking, which I still haven't been able to track down.
I have no idea what this means practically, but it's at least something I can start looking in to
Near crashing slabtop shows:
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
425592 100046 0% 0.31K 35466 12 141864K skbuff_head_cache
At boot time it's more around
32844 32813 0% 0.31K 2737 12 10948K skbuff_head_cache
Anyone with Oneplus 5, 5t or 6? Or some recent phone with Qualcomm chipset and Android 8.1.
Can you please test what is the upload speed after re-association? For me it is about 1Mbit/s.
So setup two APs with same SSID, roam back to Linksys so that it reassociates on 5GHz channel.
I have wrote more details here (as bbogey)
https://github.com/kaloz/mwlwifi/issues/295#issuecomment-391610963
Edit: issue will be fixed by OnePlus
I have a PixelXL w/ Android 8.1 and a Qualcomm MSM8996 chipset. I don't see any limiting of wifi. I move things to and from it at about 150-200 Mbps on 'AC', 75-100Mbps on 'N'.
My wife's Pixel2 has about the same speeds.
So it is the upload speed after reassociation?
Let me put my results here also
Initial association
Connecting to host 192.168.1.33, port 5201
[ 4] local 192.168.1.181 port 46364 connected to 192.168.1.33 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 77.7 MBytes 642 Mbits/sec
[ 4] 1.01-2.00 sec 76.2 MBytes 646 Mbits/sec
[ 4] 2.00-3.00 sec 75.0 MBytes 629 Mbits/sec
[ 4] 3.00-4.02 sec 75.0 MBytes 622 Mbits/sec
[ 4] 4.02-5.01 sec 77.5 MBytes 655 Mbits/sec
[ 4] 5.01-6.00 sec 76.2 MBytes 644 Mbits/sec
[ 4] 6.00-7.01 sec 75.0 MBytes 623 Mbits/sec
[ 4] 7.01-8.01 sec 71.2 MBytes 596 Mbits/sec
[ 4] 8.01-9.00 sec 60.0 MBytes 509 Mbits/sec
[ 4] 9.00-10.02 sec 76.2 MBytes 627 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.02 sec 740 MBytes 620 Mbits/sec sender
[ 4] 0.00-10.02 sec 740 MBytes 619 Mbits/sec receiver
iperf Done.After reassociation
Connecting to host 192.168.1.33, port 5201
[ 4] local 192.168.1.181 port 46300 connected to 192.168.1.33 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 947 KBytes 7.67 Mbits/sec
[ 4] 1.01-2.04 sec 0.00 Bytes 0.00 bits/sec
[ 4] 2.04-3.04 sec 368 KBytes 3.01 Mbits/sec
[ 4] 3.04-4.04 sec 0.00 Bytes 0.00 bits/sec
[ 4] 4.04-5.02 sec 0.00 Bytes 0.00 bits/sec
[ 4] 5.02-6.04 sec 382 KBytes 3.08 Mbits/sec
[ 4] 6.04-7.04 sec 0.00 Bytes 0.00 bits/sec
[ 4] 7.04-8.02 sec 0.00 Bytes 0.00 bits/sec
[ 4] 8.02-9.02 sec 0.00 Bytes 0.00 bits/sec
[ 4] 9.02-10.04 sec 382 KBytes 3.07 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.04 sec 2.03 MBytes 1.70 Mbits/sec sender
[ 4] 0.00-10.04 sec 1.10 MBytes 920 Kbits/sec receiver
iperf Done.
Just installed r7093 on my Rango and appears DarkMatter theme is a bit broken.
Had the same issue with my WRT32X. Darkmatter Theme was jumbled. The Bootstrap and Material Themes were fine.
Also, Advanced Reboot doesn't recognize the dual-partitions.
Advanced Reboot working fine here @r7093.... edit: but i'm using a WRT3200ACM.
This is where in Github the theme is pulled from --> https://github.com/apollo-ng/luci-theme-darkmatter
Appears there are two contributors to the project.