Asuswrt-Merlin 374.40 Beta 2 is available

[RMerlin]

Found why Regulation Mode was once again broken. Looks like the router applies default wireless values every time the radio is restarted, which caused reg_mode to be once again set to off. I had added that code after fixing the original issue so that European AC68U users would still be able to use DFS.

Now I enforce "d" only if we have a DFS-capable router and if it was set to "off".

 

[vdemarco]

No idea where that'd be from, since 159 is not a valid channel. It's probably 157+161 rather.

This is what i see.

 

[KevTech]

RT-N66U...North America

Loaded beta 2, reset to defaults and manually reconfig.

Same issue but now I also get the wep entries showing when selecting 40Mhz channel bandwidth.

Seems the wireless mode does not matter.

Select 20/40 and wep entries not present - can still select channels after applying setting

Select 20 and wep entries not present - can still select channels after applying setting

Select 40 and wep enties not present at first but are after applying settings.

Selected channel 36 and after applying setting when wireless comes back up the blank wep entries are there and wireless channels can not be selected.

I looked in the wireless log and 5GHz channel is set to 157 even though before applying setting I selected 36.

This same issue happens in the latest stock firmware as well.

 

[RMerlin]

This is what i see.

This is a display issue. The channel isn't properly extrapolated most likely.

 

[RMerlin]

RT-N66U...North America

Loaded beta 2, reset to defaults and manually reconfig.

Same issue but now I also get the wep entries showing when selecting 40Mhz channel bandwidth.

This same issue happens in the latest stock firmware as well.

Looking at the empty fields, this looks like the webui code crashed on a syntax error, so you get a half-rendered webui.

Check in your browser console to see what Javascript error is blocking it.

 

[RMerlin]

RT-N66U...North America

Loaded beta 2, reset to defaults and manually reconfig.

Same issue but now I also get the wep entries showing when selecting 40Mhz channel bandwidth.

Seems the wireless mode does not matter.

Select 20/40 and wep entries not present - can still select channels after applying setting

Select 20 and wep entries not present - can still select channels after applying setting

Select 40 and wep enties not present at first but are after applying settings.

Selected channel 36 and after applying setting when wireless comes back up the blank wep entries are there and wireless channels can not be selected.

I looked in the wireless log and 5GHz channel is set to 157 even though before applying setting I selected 36.

This same issue happens in the latest stock firmware as well.

I was able to reproduce it by switching to Internet Explorer. This is a browser issue, here's the explanation:

http://stackoverflow.com/questions/...-in-javascript-for-internet-explorer-browsers

 

[KevTech]

I was able to reproduce it by switching to Internet Explorer. This is a browser issue, here's the explanation:

http://stackoverflow.com/questions/...-in-javascript-for-internet-explorer-browsers

Ya it only happens in the the latest stock and Merlin 40 betas.

Fixed IE and Firefox compatibility issues

Whatever Asus changed in the code broke IE instead of fixing it.

Will have to fire up Firefox and see how it is. Used to only use Firefox but tending away from it since they will soon be stopping add ons.

 

[KevTech]

I was able to reproduce it by switching to Internet Explorer. This is a browser issue, here's the explanation:

http://stackoverflow.com/questions/...-in-javascript-for-internet-explorer-browsers

Ya it only happens in the the latest stock and Merlin 40 betas.

Fixed IE and Firefox compatibility issues

Whatever Asus changed in the code broke IE instead of fixing it.

IE 11 works on all firmware versions for me until the latest.

Will have to fire up Firefox and see how it is.

 

[RMerlin]

Whatever Asus changed in the code broke IE instead of fixing it.

AFAIK, that fix Asus mentioned was specific to the flashing warning icon that didn't work properly on these two browsers.

Meanwhile, while "fixing" the chanspec management, they used a function that is not supported by IE, which broke it. That's in addition to that same code chopping off half of the US channels, something they probably didn't notice either. That smells like unfinished code that got rushed out due to the recent security issues.

This should take care of this latest one.

Will have to fire up Firefox and see how it is. Used to only use Firefox but tending away from it since they will soon be stopping add ons.

I switched from Firefox to Chrome about two years ago. I don't miss Firefox at all, tho I still use it at work. Chrome integrates just much better with all my different computers and devices.

 

[KevTech]

This should take care of this latest one.

Next beta?

 

[RMerlin]

Once 374.40 is released, I'm going to sit on this and wait for Asus to release a stable codebase. The past 4 months of releases have been a mess, on top of which sits the current unstable AC68U firmware. Having to fix so many new bugs each time I merge a new GPL code is getting really frustrating.

I'm always supportive of their work, and have even defended them on quite a few occasions, but this is getting a bit silly, to be blunt. Take my changelog, and look for how many time "Asus bug" comes up in the past four or five months of firmware releases. A lot of those fixed bugs were actually introduced in their last FW version. Just patching up each new GPL release has turned this whole project into a chore - and a frustrating one, as the tone of my recent forum posts have probably shown.

 

[RMerlin]

Next beta?

Yes, I just pushed that code to Github.

 

[darkknight74]

Can anyone say if this beta2 works fine on rt-n66u?
Will it be better wifi in beta2?

Beta1 works very good on rt-n66u for me!
Thanks merlin for the update!

 

[Builder71]

Once 374.40 is released, I'm going to sit on this and wait for Asus to release a stable codebase.
...
Having to fix so many new bugs each time I merge a new GPL code is getting really frustrating.
...

Best thing you can do. Let it rest, it's hobby.
Nobody wins if you get frustrated.

Don't make the ASUS coders lazy because you always sift through their code.

Because Beta1 is close to Beta2 I assume I can flash it on top of it.
Without resetting to default.

Thx for Beta2!

 

[Builder71]

Can anyone say if this beta2 works fine on rt-n66u?
Will it be better wifi in beta2?

Beta1 works very good on rt-n66u for me!
Thanks merlin for the update!

Test it yourself and let us know.

 

[HeadBanger]

Best thing you can do. Let it rest, it's hobby.
Nobody wins if you get frustrated.

Don't make the ASUS coders lazy because you always sift through their code.

Because Beta1 is close to Beta2 I assume I can flash it on top of it.
Without resetting to default.

Thx for Beta2!

I have to agree. Take a break RMerlin for a while if it is becoming a chore. I'd much rather future quality firmwares but less frequently rather than none at all from you should give it up out of frustration.

HB

 

[darkknight74]

I can't see any changes for rt-n66u in the changelog for beta2!

 

[Chrysalis]

What region are you in? I'm unable to reproduce this specific issue here. It might however be related to a separate issue I recently fixed that would cause some channels to be missing.

Give Beta 2 build a shot to see if it was the same issue that was fixed in it (I'm hoping to be able to upload this new build later tonight).

will this fix the issue I reported which is this.

on older firmware the chanell I select on 5ghz with 80mhzx shows properly in the wifi logo popup display. eg. if channel 36 it shows 36 + 42 if channel 40 it shows 40+ 42.
On .40 beta1 it always shows just 36 regardless of channel picked. It only seems to work properly in auto channel which then picks high channels which are much weaker signals than the lower ones.

 

[Chrysalis]

Once 374.40 is released, I'm going to sit on this and wait for Asus to release a stable codebase. The past 4 months of releases have been a mess, on top of which sits the current unstable AC68U firmware. Having to fix so many new bugs each time I merge a new GPL code is getting really frustrating.

I'm always supportive of their work, and have even defended them on quite a few occasions, but this is getting a bit silly, to be blunt. Take my changelog, and look for how many time "Asus bug" comes up in the past four or five months of firmware releases. A lot of those fixed bugs were actually introduced in their last FW version. Just patching up each new GPL release has turned this whole project into a chore - and a frustrating one, as the tone of my recent forum posts have probably shown.

I was going to say it seems all the asus firmwares since january or so have been "broken"

is it possible to make 374.40 but based on the asus firmware you used for the excellent 3.0.0.4.374.35_4 build?

why are asus doing rewrites of stable code?

 

[Builder71]

I can't see any changes for rt-n66u in the changelog for beta2!

Here.
(If there is no specific device mentioned, it's valid for all supported devices.)