Asuswrt-Merlin 376.44 Beta 1 is out

[RMerlin]

Since updating to 376.44 Beta 1 my country code has been locked to US instead of AU.

I purchased this router in an Australia store to be used in Australia.

Other than channels 12 and 13 on 2.4ghz I think nothing else would change but many other countries have different rules and those users may be forced to break the laws in their country with this firmware.

Maybe a warning should be given that this firmware is incapable of correctly setting country code and therefore breaks the law in many countries other than USA.

What router model?

The firmware does not enforce any particular country code, that code is entirely untouched and unmodified from Asus's own code.

 

[RMerlin]

I just did not get it:



How should i do that? The factory reset is not enough in my case

Please let me know what to do

Thanks

Don't worry about that if coming from stock firmware - you weren't using the JFFS partition then.

 

[RMerlin]

@merlin

Hi and good Morning aus Germany

I can not set 40 MHz in the new Beta , he set always 20MHz
Chanspec: 2.4GHz channel 13 20MHz (0x100d)

The router will automatically downgrade to 20 Mhz if there's any interference, as required by the 802.11 specifications.

 

[DrTeeth]

Unfortunately it seems to get more and more questionable for Europeans to buy products that are developed with the US in mind.<snip>

It is not made with the US in mind IMHO. They have just been lazy and chosen to use the 4 common 5 GHz channels for the whole of Europe.

 

[DrTeeth]

What router model?

The firmware does not enforce any particular country code, that code is entirely untouched and unmodified from Asus's own code.

In my case the router is N66U. I could not get my original wi-fi settings back at all with the beta. As soon as I loaded the .43 release, all was well and the customisations were still present - they must have been invisible to the driver in the beta.

 

[RMerlin]

I removed all regional restrictions on my N66U - but do operate it legally. I do not wish to risk my ham licence.

Loading this beta made it change to EU (which is not a regulatory domain) losing me 13 legal 5GHz channels. Reinstalled 374.43 and all was well again. I hope that this is something that will not be in the final.

I don't have that many 5GHz devices, but on principle, I want access to all my legal channels.

There's not a single line of code in the firmware that sets the region to "EU". I just did an actual grep, and there are only checks to see if EU is set - not a single nvram_set() call:

merlin@mint-dev ~/asuswrt/release/src/router/rc $ grep "\"EU\"" * -r
init.c:		if (	nvram_match("wl1_country_code", "EU") &&
lan.c:				if (	nvram_match(strcat_r(prefix, "country_code", tmp), "EU") &&
lan.c:				if (	nvram_match(strcat_r(prefix, "country_code", tmp), "EU") &&
lan.c:					nvram_match(strcat_r(prefix, "country_code", tmp), "EU") &&
lan.c:					nvram_match(strcat_r(prefix, "country_code", tmp), "EU") &&
services.c:	if (nvram_match("wl1_country_code", "EU"))
sysdeps/init-broadcom.c:					else if (nvram_match(strcat_r(prefix, "country_code", tmp), "EU"))
sysdeps/init-broadcom.c:					else if (nvram_match(strcat_r(prefix, "country_code", tmp), "EU"))
sysdeps/init-broadcom.c:				nvram_match(strcat_r(prefix, "country_code", tmp), "EU") &&
sysdeps/init-broadcom.c:				nvram_match(strcat_r(prefix, "country_code", tmp), "EU") &&
sysdeps/init-broadcom.c:				nvram_match(strcat_r(prefix, "country_code", tmp), "EU") &&
sysdeps/ralink/ralink.c:	else if (!strcasecmp(cc, "EU")) ;
sysdeps/init-broadcom-em.c:					else if (nvram_match(strcat_r(prefix, "country_code", tmp), "EU"))
sysdeps/init-broadcom-em.c:					else if (nvram_match(strcat_r(prefix, "country_code", tmp), "EU"))
sysdeps/init-broadcom-em.c:				nvram_match(strcat_r(prefix, "country_code", tmp), "EU") &&
sysdeps/init-broadcom-em.c:				nvram_match(strcat_r(prefix, "country_code", tmp), "EU") &&
sysdeps/init-broadcom-em.c:				nvram_match(strcat_r(prefix, "country_code", tmp), "EU") &&
merlin@mint-dev ~/asuswrt/release/src/router/rc $

 

[RMerlin]

No problems downloading here. Been running the beta for about 90 minutes now.

I like the new CPU/RAM usage graphs. No issues with the migration at this point, and my OpenVPN client connection works fine.

I am hoping wireless is better in this build than that past few; I don't attribute that to Merlin, but to ASUS. I had to relocate my router this year due to poorer signal strength, and I don't have that large of a house. The only other thing I could attribute it to is changing my Wireless bridge from a Buffalo N-series to a newer Buffalo AC-series; it works great for communication between the router and the bridge, but I suppose it could cause issues with other clients (though that sounds unlikely to me).

I'm still using a wireless driver from October 2013 on the RT-AC66U because people were complaining about the range/performance of newer Asus releases.

 

[RMerlin]

What I do need is the allowed range of 5ghz channels in the Netherlands. If newer firmware versions would take away the possibility to use the allowed range of channels, than I will stay on 374.42. And after that no more ASUS.

Other manufacturers won't let you do that any more than Asus. They will all have to play by the new established rules. This isn't Asus's decision.

 

[RMerlin]

My network map only shows 3 clients, but I have about 15 clients on my network. I am using a 10. prefix on my network with 255.255.0.0 netmask. Would this cause any issues with that?

I have this issue on .43, but held off on posting since .44 has network map fixes, but still occurring with .44.

Yes. Networkmap is currently hardcoded for /24 only.

 

[RMerlin]

Comparing NVRAM before and after nvram reset and reload....Notable changes between .42 and .44

N66U:

1) Power is now capped at 100mw for both 2.4 and 5 GHz bands
--->wl_TxPower=200, wl1_TxPower=200, wl0_TxPower=200 all changed to values of 100.
2) wl1_country_rev=0 changed to wl1_country_rev=2
3) wl1_nband=1 changed to wl1_nband=0
4) wl0_country_rev=2 changed to wl0_country_rev=39
5) wl0_gmode=1 changed to wl0_gmode=-1
6) wl_chanspec=157l changed to wl_chanspec=153u
7) pci/1/1/ccode=US changed to pci/1/1/ccode=Q2

BEFORE - 5GHz, -68, -66 dBm
AFTER- 5GHz, -72, -73, -70, -71 dBm
RESULT - Lost about 4-7 dBm on 5 GHz from this update

BEFORE - 2.4GHz, -51, -62 dBm
AFTER- 2.4GHz, -55, -56, -56, -57 dBm
RESULT - Lost about 4 dBm on 2.4 GHz from this update

Looks like many changes with country codes and power. Power also can't be set past 100% in the GUI, which appears to correspond to the 100mw cap.

Any ideas what is going on with the country codes? I'm in the US, so shouldn't they all be US? Thanks.

The switch from US to Q2 on the RT-N66U is caused by the engineering mode code that I have re-implemented as an experiment (that code was removed by Asus a few months ago). I wanted to see if that code was responsible for bringing wireless performance back to the old SDK5 days. So far I get conflicting reports (some people claim an improvements and others saw a downgrade), so there's no reliable final answer I'm afraid.

Following these conflicting RT-N66U performance reports, I will revert back to non-EM mode, upgrade the wireless driver to the Asus 1071 release, and wash my hands off these wireless problems.

 

[RMerlin]

Huawei e3276s still not working.Why not fixed?Maybe possible with script connect to 4g internet with this modem?

Don't ask me, ask Asus. I have no way of testing anything related to 3G/4G devices, I merely merge their code in. They were saying it was fixed in their release notes. <shrug>

 

[RMerlin]

In my case the router is N66U. I could not get my original wi-fi settings back at all with the beta. As soon as I loaded the .43 release, all was well and the customisations were still present - they must have been invisible to the driver in the beta.

I'll revert the experimental EM code back to Asus's stock GPL code, and upgrade the December 2013 driver to the Asus 376_1071 version. All those experiments in an attempt to resolve the complains about reduced range on the RT-N66U are simply a huge time sink for me at this time, so I'm giving up on that.

If after that people are still unhappy about the N66U range, they are welcome to buy a different router model that will give them improved range and performance. I've already done everything I could (and some more) in attempts at getting this resolved, there's nothing more I can do.

 

[W500]

It is not made with the US in mind IMHO. They have just been lazy and chosen to use the 4 common 5 GHz channels for the whole of Europe.

That has been there for a while. But, there were ways around it. Because off FCC demands the detours are getting cut off. Merlin wrote about that between the lines.

 

[DrTeeth]

<snip>
If after that people are still unhappy about the N66U range, they are welcome to buy a different router model that will give them improved range and performance. I've already done everything I could (and some more) in attempts at getting this resolved, there's nothing more I can do.

I, for one, appreciate your efforts. It's always worth a try.

 

[RMerlin]

I, for one, appreciate your efforts. It's always worth a try.

Yes, that was part of the point of this beta, as I wanted broader testing that what myself and two testers could do these past couple of nights.

I'm still at a loss as to why a few of the past releases were able to bring performance level back to SDK5 coverage when I find out that the special driver wasn't even properly included in these releases (and I no longer have it to re-test that properly).

 

[White_Knight]

Things that will require special testing:

• Check SMB sharing stability and performance. Initial reports from testers reported improvements both for MIPS and ARM devices.
  
• DLNA sharing. Asus upgraded to 1.1.3, please confirm there is no regression. Once I get confirmation this is looking at least as good as the last release, I will see if there are additional unmerged patches required.
  
• I did a few experiments for the RT-N66U wifi, including re-implementing some code Asus had removed a few months ago. Just let me know if you notice any increase in overall range/performance if you had a drop in 374.42/374.43.

Hello Merlin,

I have N66U ( MIPS ) Router and want to say about this 3 points.

First, SMB sharing now working better, i has no more router reboots when copy big file/files ( more then 1 Gb )

Second, I use external DLNA 1.1.3 debian server with only one issue, i need sometime recreate database of files because when i add some file i can't see in minidlna file list ( soon i switch to internal dlna server for test and report here )

Third,Wi-Fi work good i don't has problem with speed or setup ... increase overal speed Upload\Download stability ( Now i don't see 'Jumping' speed ) tested by speedtest.net

 

[cvx01]

The switch from US to Q2 on the RT-N66U is caused by the engineering mode code that I have re-implemented as an experiment (that code was removed by Asus a few months ago). I wanted to see if that code was responsible for bringing wireless performance back to the old SDK5 days. So far I get conflicting reports (some people claim an improvements and others saw a downgrade), so there's no reliable final answer I'm afraid.

Following these conflicting RT-N66U performance reports, I will revert back to non-EM mode, upgrade the wireless driver to the Asus 1071 release, and wash my hands off these wireless problems.

No complaints about WiFi range on the .43 build and most prior. Build 43 had some weird issue with wifi just being non-responsive. Link to client and AP is up, just no data returned or very very slow, requiring a reboot. Power was fine on .43 for me. Reverted to .42, which power was also fine. 99% of my clients are 5GHz, so I'm primarily watching that piece personally.

On a side note, on .44 trying to nvram set the previous mentioned variables back to what they previously doesn't survive a reboot. Not sure if Asus changed something, but in the past all values survived a reboot.

Thanks for all the hard work on this.

 

[W500]

I've already done everything I could (and some more) in attempts at getting this resolved, there's nothing more I can do.

This range and performance discussion may be no more than a ghost chase. The ASUS products with external antennas will outperform ANY normal (laptop’s, smartphones and printers) client. We are talking about bidirectional communication. Both ways have to perform equally well to get a 100% result. Cranking up the power on an access point is only one end of the chain. It does not help the client to be heard better.
Of course there could be a zillion other issues in the radio firmware, but that is a Broadcom issue. I do not think there were serious issues on the Broadcom side.
There were very serious issues with intel clients, but they seem to be resolved by now.

 

[Andu]

Is the new QoS system already in place? And if it is can I use it with a N66U?

 

[RMerlin]

Is the new QoS system already in place? And if it is can I use it with a N66U?

The new QoS engine is strictly for the RT-AC87U. Asus might eventually implement it on the AC56 and AC68, but there's no official word on this yet.

The N66 and AC66 will definitely not get it, as they lack the additional CPU power requirements of the new engine.