RT-N66U firmware 3.0.0.4.374.720 released

[SN_]

I would need confirmation first that it really resolves the issue. At first glance it would surprise me, since when I queried the driver using the wl command during my tests yesterday (I forgot which command I used - not at home at the moment), it did tell me it was already set for US. Unless for some odd reason the driver would require that setting to get re-applied?

Pls, dont forget that the default value for my router is DE or EU but for sure not US...

 

[SN_]

Forgot to mention, "wl -i eth2 txpwrlimit" was before and after the command "1 mW (0.0 dBm)". This should make clear that txpwrlimit is irrelevant with SDK6.

 

[RMerlin]

Pls, dont forget that the default value for my router is DE or EU but for sure not US...

In that case this isn't necessarily related to the issue at hand - you might simply be compensating for it by using a country region that allows higher output power than is legally allowed in DE. In this case, this isn't something that I will support, for various reasons.

 

[SN_]

... - you might simply be compensating for it by using a country region that allows higher output power than is legally allowed in DE. In this case, this isn't something that I will support, for various reasons.

Sure, thats why i dont use it and switched back to 33b1.

Anyway my point on this was a different one. With SDK6 changing the country region immediately changed tx power and is so far the only way i found out to change it. On the other hand with SDK5 it changes only the limit but does not change the tx power itself.

In short, SDK6 seems to have build in fixed tx power settings that may or may not comply local laws. In my case SDK6 is just broken and useless.
Otherwise, assuming that it is working fine means in consequence that all my other devices and all the devices in my neighborhood do break local regulations and that is more than hard to believe.

 

[PrivateJoker]

Hi, Just a note: I found that spatial orientation of both router antennae and laptop (usually screen with build in antennae) makes vast difference in signal strength, saw variation of 20dB at the same location.
For me having screen side instead of back to router had best results.

So when measuring it is important to also keep the spatial orientation the same.

This post was from a few days ago, but I happened to be in a spot today that I could actually test it and I got some very interesting results.

I was in my kitchen at the "breakfast bar" (aka a small counter area) on my 2013 MacBook Pro, almost equidistant (and LCD side directly facing) to my RT-N66U, 3 walls behind me (and about 20 feet), and sitting LCD away side, directly in front of my secondary AP (a latest gen Apple Airport Express) - which was about 10' in front of me, but also 3 walls. I use the APE where it is for AirPlay (it's plugged into a speaker) and it also gives me good wifi outside in my workshop, where my main router just has no signal at all.

My home is old, the walls are plaster, not drywall, and some of it's a mix of traditional plaster on lathe and also plaster on wire construction (plaster, especially on a wire backing, being a pretty unfriendly RF environment). Here's a pic (changing a switch out) with the exposed plaster on wire.



So I used OSX's built in wifi scanner, the middle line in both screenshots is not my AP, but channels 1 & 161 are the RT-N66, and channels 3 & 149 are the Apple Airport Express (link to SNB review of current gen APE, and internal pics of its antennas).



Essentially, in this unscientific test - rotating my laptop 180 degrees (and the antennas are built into, or around the laptop's display panel, on the periphery of the LCD IIRC) had no meaningful change to the RSSIs on either of the 2.4ghz signals, and actually no meaningful impact on the RT-N66's 5ghz channel, yet it did lop 10 dBi off the APE if it had its back towards it, vs. facing it.

So, laptop/device orientation does (can) make a measurable difference, especially on 5ghz, but the some APs will be more affected than others. . .weird.

Someone please advise if this post should be moved or deleted, I just was trying to reply to original post that happened to be in this thread regarding laptop placement & WiFi signal.

 

[PrivateJoker]

Out of curiosity, can you try the same test after running the following commands on your router?

nvram set wl0_reg_mode=h
nvram set wl1_reg_mode=h
nvram commit
reboot

That updated it in my scan right away. What does the _reg_mode=h command do? (please say unleash furious powers)

 

[RMerlin]

That updated it in my scan right away. What does the _reg_mode=h command do? (please say unleash furious powers)

The reg_mode setting controls two different 802.11 extensions:

802.11h: this addresses some output management in regard to potential interferance source such as radars. DFS is one thing that is related to it, and is required for the 5 GHz band to be usable on certain channels.

802.11d: This extends the regulatory domains supported by the devices.

reg_mode can have the following values:

off: Disables 802.11d and 802.11h
d: Enable 802.11d
h: Enable 802.11h + 802.11d
strict_h: Enable 802.11h

Some Mac owners have reported in the past they were unable to connect unless that setting was set to "h".

My guess is, you need 802.11d for that country definition to work properly.

I've been debating for quite some time to add this option to the wireless configuration page. I just haven't gotten around to it yet as I first need to check the firmware to ensure it won't override what I set through the webui (there is at least two instances in the FW where it can set that value and override the user setting).

 

[wouterv]

Do I see two yet not confirmed conclusions:

1. The 3.0.0.4.347.720 build for RT-N66U suffers an issue with 2.4 GHz related to the router region setting? (e.g. I am in the Netherlands EU and do not see serious issues with this build, except a slight decrease in signal strenght, rate and throughput seems to be ok).
2. Does the RT-N66U support DFS, through the 802.11h standard?

I never saw any signs of support for DFS in the RT-N66U, due to EU regulations I can only select 4 of the many 5 GHz channels and in Auto, it allways use one of those 4 channels.

Not mentioned yet, can there be an issue with the older and newer RT-N66U hardware versions? Mine is an older version and seems to be happy with this build.

 

[SN_]

Do I see two yet not confirmed conclusions:

1. The 3.0.0.4.347.720 build for RT-N66U suffers an issue with 2.4 GHz related to the router region setting? (e.g. I am in the Netherlands EU and do not see serious issues with this build, except a slight decrease in signal strenght, rate and throughput seems to be ok).
2. Does the RT-N66U support DFS, through the 802.11h standard?

I never saw any signs of support for DFS in the RT-N66U, due to EU regulations I can only select 4 of the many 5 GHz channels and in Auto, it allways use one of those 4 channels.

Not mentioned yet, can there be an issue with the older and newer RT-N66U hardware versions? Mine is an older version and seems to be happy with this build.

You are located in Netherlands and there is only a slight decrease in 2.4GHz signal strenght? Wow i am confused now
What does the command 'wl country' report on your router? Mine returns 'EU (EU/3) EUROPEAN UNION'.

BTW I have tried setting country to EU, DE, FR, RU and even CA without observing any difference in signal strength. But setting it to US did all the magic to get the signal strength back to the level of a SDK5 based FW. Looks more and more like a random issue to me...

 

[wouterv]

Yes, I am in the Netherlands and the router is purchased in the Netherlands.

ASUSWRT RT-N66U_3.0.0.4 Wed Sep 11 07:34:01 UTC 2013
admin@RT-N66U:/tmp/home/root# wl country
EU (EU/3) <unknown>

As you see, a slight difference...<unknown> instead of "UROPEAN UNION".
And yes, 2.4 GHz seems to have a slightly less signal strenght compared to the 270 build.
I have to admit that my 2.4 GHz is set to fixed 20 MHz and a fixed channel, no b/g Protection, no Optimized for Xbox, with AES encryption.
I did set it to 20 MHz due to the large amount of accesspoints in the neighborhood.
The router is downstairs, the furthest client is two concrete floors up and is a Linksys WRT54GL as Client Bridge (with DD-WRT) and a printer wired to it.
Here I see that the 2.4 GHz signal is slightly less strong (lower SNR), but the wireless rate hardly ever goes below 54 Mbps (which is the maximum for the WRT54GL). Various wireless "N" 2.4 GHz clients usually indicate the expected maximum rate of 72 or 75 Mbps.
With the 270 build, the wireless rate at the WRT54GL often dropped to 18 Mbps (which I allways believed was fair due to the relative long distance).
The wireless speed on 2.4 GHz is suitable for our Internet download speed.
Clients that require higher speeds are on 5 GHz.
In time I may replace the WRT54GL by a dual band repeater or the RT-N66U.

 

[mikey]

Anyway my point on this was a different one. With SDK6 changing the country region immediately changed tx power and is so far the only way i found out to change it. On the other hand with SDK5 it changes only the limit but does not change the tx power itself.

What is the exact command you are issuing to see the improved tx power? I've tried wl -i eth1 txpwr1 100 both before and after wl -i eth1 country "US" and it seems to have no effect. I'm still way down on signal strength with SDK6.

Thanks,
Mike

 

[SN_]

Yes, I am in the Netherlands and the router is purchased in the Netherlands.

ASUSWRT RT-N66U_3.0.0.4 Wed Sep 11 07:34:01 UTC 2013
admin@RT-N66U:/tmp/home/root# wl country
EU (EU/3) <unknown>

As you see, a slight difference...<unknown> instead of "UROPEAN UNION".

I wonder where this difference comes from. Thought the country default settings are part of the bootloader and not of the FW... strange but maybe a hint for the experts.
I am using similar settings for 2.4GHz like you.

BTW my previous router was also a WRT54GL. A rock solid device. Had never ever any problems with it.

 

[SN_]

What is the exact command you are issuing to see the improved tx power? I've tried wl -i eth1 txpwr1 100 both before and after wl -i eth1 country "US" and it seems to have no effect. I'm still way down on signal strength with SDK6.

Thanks,
Mike

As said in a previous post, 'wl -i eth1 country "US"' did all the magic on its own. I did not enter any other commands. But the default country of my device is EU maybe thats the reason. BTW, with SDK6 'wl -i eth1 txpwr1 XX' is a NOP and
totally useless.

 

[mikey]

As said in a previous post, 'wl -i eth1 country "US"' did all the magic on its own. I did not enter any other commands. But the default country of my device is EU maybe thats the reason. BTW, with SDK6 'wl -i eth1 txpwr1 XX' is a NOP and
totally useless.

OK. Thanks. That's what I tried with no change. Now that you said that, I changed to "EU" and then back to "US" just to see if changing the country is what keys the power limit to change. Still no change. I even did these commands:

nvram set pci/1/1/ccode=EU
nvram set pci/2/1/ccode=EU
nvram set wl0_country_code=EU
nvram set wl1_country_code=EU
nvram set regulation_domain=EU
nvram set regulation_domain_5G=EU
nvram commit
reboot

Followed by these commands:

nvram set pci/1/1/ccode=US
nvram set pci/2/1/ccode=US
nvram set wl0_country_code=US
nvram set wl1_country_code=US
nvram set regulation_domain=US
nvram set regulation_domain_5G=US
nvram commit
reboot

Still no change. One thing I did try were these commands:

nvram set wl_TxPower=120
nvram set wl0_TxPower=120
nvram set wl1_TxPower=120
nvram commit
reboot

Interestingly, if you change the power level on the professional tab in wireless, it ONLY affects the middle one above. The top and bottom stay at the default 80. If you issue the above three commands, all three stick through a reboot, showing 120 for all three if you use "get" instead of "set". So I thought that might make a difference.

Still no dice. The one thing I did do was I was able to find a channel that gives me slightly better signal (channel 9). Now I'm "only" down 10 dBM from SDK5 and my devices in the back room can at least stay connected (barely) but the speeds are very slow compared to SDK5 presumably because of the -80 dBM signal (SDK5 gives me -70). But I'm going to leave it here for now and run SDK6 for a while (33 beta 3) because as long as you're not in a fringe location, everything seems smoother and faster on the beta 3 SDK6. Even the devices connected via wired Cat5 seem to respond faster with less latency.

So we'll see.

Hope my info helps in some way. BTW, I reinstalled beta 3 from scratch before doing any of the above. Installed it, did mtd-erase -d nvram and then reboot. Then set everything up from scratch.

Edit: just issued the command: wl -i eth1 txpwr1 and I get this response:
TxPower is 127 qdbm, 31.75 dbm, 1496 mW Override is Off

What do you get?

Mike

 

[SN_]

OK. Thanks. That's what I tried with no change. Now that you said that, I changed to "EU" and then back to "US" just to see if changing the country is what keys the power limit to change. Still no change.

At least my router seems to be less stubborn than yours as it went back to normal tx power with country setting US while yours does not care for country settings at all

Regarding the drop in signal strength our routers seem to be in the same range. Mine dropped level by 10 to 12dB.

Edit: just issued the command: wl -i eth1 txpwr1 and I get this response:
TxPower is 127 qdbm, 31.75 dbm, 1496 mW Override is Off

What do you get?

Mike

Haven't tried the output of 'wl -i eth1 txpwr1' with beta3... anyway do you believe that your router has a tx power of nearly 1.5W as it reports? I do not even believe the transmitter is able to transmit at that power level.

 

[RMerlin]

nvram set wl_TxPower=120
nvram set wl0_TxPower=120
nvram set wl1_TxPower=120

Interestingly, if you change the power level on the professional tab in wireless, it ONLY affects the middle one above.

These settings are instanced. The webui writes wl_* settings. Then, the web server checks if you are working on the 2.4 GHz (instance 0) or 5 GHz (instance 1) band. It will then copy the setting to the appropriate instance (wl0_* or wl1_*).

Think of the wl_* settings are just temporary storage.

 

[mikey]

Haven't tried the output of 'wl -i eth1 txpwr1' with beta3... anyway do you believe that your router has a tx power of nearly 1.5W as it reports? I do not even believe the transmitter is able to transmit at that power level.

No. I can now report with confidence that the power level in beta 3 is just completely broken. It does absolutely nothing. I've tried setting it to 5 mW, 50 mW, 100 mW, and even 500 mW. There is no difference whatsoever in signal strength. Tried setting it via the command line and through the web GUI. I'm not sure what the signal strength is set to but it seems to be hard coded at somewhere around 30 mW. I may go back to beta 1 until this is fixed as much as I want to run beta 3.

Mike

 

[SN_]

Sorting out all the different feedback regarding tx power, it looks to me like a typical problem of an uninitialized pointer.
Without having access to the technical documentation there is no way to fix it and also no way to find out whom to blame. Maybe ASUS does not properly initialize the SDK6 or BC has delivered a broken SDK...or both. We just dont know.

 

[mikey]

Sorting out all the different feedback regarding tx power, it looks to me like a typical problem of an uninitialized pointer.
Without having access to the technical documentation there is no way to fix it and also no way to find out whom to blame. Maybe ASUS does not properly initialize the SDK6 or BC has delivered a broken SDK...or both. We just dont know.

Being a software developer myself, it does have the "stink" of an uninitialized variable or a bad pointer reference. But something that happened yesterday makes me wonder. I went back to 33 beta 1 (because 33 beta 3-SDK5 has the bug where you can't change channels) and I noticed something odd. When going from 33 beta 3b back to 33 beta 1, I went straight back and I forgot to do my normal nvram reset. Anyway, when I went straight from 33 beta 3b back to 33 beta 1 and rebooted, I noticed that the signal strength on beta 1 was bad (10 dBM down). How could this be when beta 1 is SDK5?

I then did the nvram reset on beta 1 and set it up again: boom... back up to normal signal strength and the tx power was working. So it's like something with beta 3b "broke" something in the nvram which has to be cleared even if you go back to an SDK5 firmware before you get your signal strength back. I didn't think to totally power off the N66U before clearing the nvram though.

Again, maybe just another piece of the puzzle. Hope this can get worked out because I did like how the beta 3b (SDK6) ran. Also, I'm posting this here instead of in the beta 3 thread because this seems to be where a lot of the SDK5 versus SDK6 discussion seems to be. Hope I'm doing right as I wasn't sure which place to post. Merlin seems to be keeping an eye on both threads though, so thanks Merlin! I also realize this is not Merlin's issue but I figure if anyone can figure it out, it's him! Also, even though he doesn't have access to source for the drivers, maybe it's possible to effect a fix outside of the driver (some type of workaround). Or what about a clever way of merging at least parts of the old WiFi driver into the new SDK6 until it's fixed? Having been an Android developer, we'd do that a lot to fix issues with WiFi, GPS, etc: find which binary is involved and sometimes you can merge an old binary into a new library and fix it without destroying new functionality. It's a hack, sure, but worth a try and it can give you a lead sometimes.

Mike

 

[wouterv]

Another one, with the last post in mind:
Are there differences in how to "reset memory" with either one of the 3 methods:

1. Hard reset, pushing the reset button over 5 seconds, wait for the power LED to flash in slow pace.
2. GUI reset: Administration>Restore/Save/Upload>Factory default-Restore.
3. Telnet clear NVRAM: mtd-erase -d nvram

Does one or the other leave some settings, parameters or pointers unchanged?

I did the hard reset (option 1) after the upgrade from 270 to 374_720, entered the settings manual again, and am quite happy.