[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

[atkinsom]

However, still the same results: 5ghz wifi not broadcasting (also made sure to wait long enough for the signal to pop up, it didn't)
I reverted back to 26E4 for the time being.

Can anyone with a RT-AC68U Rev. A1 confirm that the new firmware is working correctly for them (particularly the 5ghz wifi) ?

I ran into a similar problem once...see if this helps or at the very least it's worth a try. Did do a factory reset in between but no difference until I tried what I did below.
https://www.snbforums.com/threads/f...lts-releases-v27e5.18914/page-276#post-312099

 

[john9527]

I ran into a similar problem once...see if this helps or at the very least it's worth a try. Did do a factory reset in between but no difference until I tried what I did below.
https://www.snbforums.com/threads/f...lts-releases-v27e5.18914/page-276#post-312099

Interesting....not sure I can explain it, but can't argue with success.

@JLL
The other possibility is that ASUS decided to tweak the Japan regulation values 'under the cover' in some of the new closed source code. A 'mismatched' regulation revision value can cause the Channel 0 problem you saw. Unfortunately, when they change this part of the code it's not always consistent. I've made a post in the Merlin fw thread asking someone to check these values so we can compare to yours.

 

[sirwifi]

Is this firmware version a good one to run a RT-AC68U in AP mode? I don't need any fancy features, just AP mode as my RT-AC68U is behind another router, with the best possible wifi drivers and performance. The latest releases of Merlin give me a hard time with 2.4Ghz. Or any other version recommendations for best AP WiFi?
(I understand that the downgrade process on this one could be tricky)

 

[jrmwvu04]

Updated my 1900P to current with no issues. Getting prepared to do the remote AC68U, which is an A1 revision. Loss of the 5Ghz network wouldn't be catastrophic, so I might roll the dice and see what happens.

 

[JLL]

On the Wireless > Professional page, in the very lower right hand corner is a set of characters in ( )...like (US/0) What are they?

It says

Set the capability for transmission power. The maximum value is 200mW and the real transmission power will be dynamically adjusted to meet regional regulations. (JP/47)

and the Tx power adjustment setting is set to 80mW

Me, my Rt-AC68u rev A1 is working correctly on both band ( US/0)

Thanks for the confirmation ! Looks like my region might be the problem...

I ran into a similar problem once...see if this helps or at the very least it's worth a try. Did do a factory reset in between but no difference until I tried what I did below.
https://www.snbforums.com/threads/f...lts-releases-v27e5.18914/page-276#post-312099

I'll give it a try tonight - thanks for the hint.

@JLL
The other possibility is that ASUS decided to tweak the Japan regulation values 'under the cover' in some of the new closed source code. A 'mismatched' regulation revision value can cause the Channel 0 problem you saw. Unfortunately, when they change this part of the code it's not always consistent. I've made a post in the Merlin fw thread asking someone to check these values so we can compare to yours.

Ok thanks for the help ! If you need any additional info please let me know.

EDIT: I ran the commands you posted on the other thread and got the following

1:ccode=JP
0:regrev=45
0:ccode=JP
1:regrev=47
size: 49660 bytes (15876 left)

 

[rtn66uftw]

Flashed to 27E5 from 26E3 on AC68U, AC68R, TM-AC1900 routers. Things have been great in the last 24 hrs. Thanks again John!

 

[jrmwvu04]

Can anyone with a RT-AC68U Rev. A1 confirm that the new firmware is working correctly for them (particularly the 5ghz wifi) ?

AC68U A1 updated with no problems.

1:ccode=JP
0:regrev=45
0:ccode=JP
1:regrev=47

First I've ever seen those regrev values different from one another.

 

[john9527]

EDIT: I ran the commands you posted on the other thread and got the following

1:ccode=JP
0:regrev=45
0:ccode=JP
1:regrev=47
size: 49660 bytes (15876 left)

Can you also check the output of
strings /dev/mtd0 | grep -E "ccode|regrev|bl_"

First I've ever seen those regrev values different from one another.

A bit unusual for the ARM routers, but pretty common on the MIPS based routers. The values are just pointers into a table.

 

[JLL]

Can you also check the output of
strings /dev/mtd0 | grep -E "ccode|regrev|bl_"

Here's the output

0:ccode=JP
1:ccode=JP
bl_version=1.0.1.6
0:regrev=45
1:regrev=47

I should also add that all values (including the ones with the nvram command) are with the 26E4 firmware.
Are they expected to be any different with 27E5 ? Should I flash 27E5 and run those commands again ?

 

[jrmwvu04]

bl_version=1.0.1.6

That predates some changes, if I recall correctly. I believe that loading Merlin 378.55 updates the bootloader to 1.0.2.0 or 1.0.2.1, at least for US versions.

If you feel like tinkering with that idea, you can load Merlin 378.55 briefly, then come back to the fork and factory reset.

 

[JLL]

That predates some changes, if I recall correctly. I believe that loading Merlin 378.55 updates the bootloader to 1.0.2.0 or 1.0.2.1, at least for US versions.

If you feel like tinkering with that idea, you can load Merlin 378.55 briefly, then come back to the fork and factory reset.

Is there a specific procedure for that ? Or I can just upgrade and downgrade without any particular steps (nvram, factory reset etc) ?

 

[jrmwvu04]

Is there a specific procedure for that ? Or I can just upgrade and downgrade without any particular steps (nvram, factory reset etc) ?

I generally do factory resets following changing firmware levels as an abundance of caution sort of measure, but you probably don't need to do that after loading 378.55. You certainly should do it after coming back to fork 27E5.

 

[john9527]

If you feel like tinkering with that idea, you can load Merlin 378.55 briefly, then come back to the fork and factory reset.

@JLL - Good advice from jrmmv04 (and why I wanted to check the bl_version). I don't know for sure without having another Japan router to compare to, but it's possible that the bl update will update the regrev values. I verified that in the new wireless drivers, 5GHz regrev 47 does disable the radio (and on the older code, you were actually running 'crippled' not having all the channels that should be available in Japan).

You can load 378.55 through the gui, then just reload 27E5 through the gui and factory reset after it boots on 27E5. By using 378 code, you stay out of having to worry about the firmware downgrade 'lock' on the 380 series.

Then run the last command again to get the new bl_version and see if the regrev value has changed.

 

[atkinsom]

I'm running John's Fork with the OpenVPN server function and have a question about one function that seems to be missing from the fork. In various threads they talk about the options below BUT "Advertise DNS to clients" as an option is missing. Was this removed from the fork? My understanding is that it tells the clients the IP address of the router that they can use as a DNS server. Or is it really not needed if you enable options 2 and 3 below. Thanks very much.

1. Push LAN to Clients
2. Direct clients to redirect Internet traffic
3. Respond to DNS
4. Advertise DNS to clients

EDIT: oops my bad need to enable Respond to DNS to see option 4 DUH

 

[JLL]

@JLL - Good advice from jrmmv04 (and why I wanted to check the bl_version). I don't know for sure without having another Japan router to compare to, but it's possible that the bl update will update the regrev values. I verified that in the new wireless drivers, 5GHz regrev 47 does disable the radio (and on the older code, you were actually running 'crippled' not having all the channels that should be available in Japan).

You can load 378.55 through the gui, then just reload 27E5 through the gui and factory reset after it boots on 27E5. By using 378 code, you stay out of having to worry about the firmware downgrade 'lock' on the 380 series.

Then run the last command again to get the new bl_version and see if the regrev value has changed.

Unfortunately, it didn't seem to have changed except for the bootloader version
What I did:
- update to 378.55
- load up 27E5
- reboot
- factory reset
- nvram clean restore
- (check wifi and values here - no change)
- factory reset
- manual settings
- (recheck again, no change)

Currently running on 27E5 now, here are the values

nvram show | grep -E "ccode|regrev"
size: 41642 bytes (23894 left)
1:ccode=JP
0:regrev=45
0:ccode=JP
1:regrev=47
strings /dev/mtd0 | grep -E "ccode|regrev|bl_"
0:ccode=JP
1:ccode=JP
bl_version=1.0.2.0
0:regrev=45
1:regrev=47

Did I screw up by not rebooting right after updating to 378.55 ?

 

[cybrnook]

You doing any factory resets / nvram erase in the middle to load default values?

 

[JLL]

You doing any factory resets / nvram erase in the middle to load default values?

I'm only doing factory reset via the GUI. I haven't done any nvram erase yet (just restore)

Also, I updated to 378.55 to check and 5ghz wifi works (and indeed I have a lot more options for the control channels)
All values are also as posted above.

 

[cybrnook]

@john9527

Maybe a dump to > nvramnew.txt and nvramold.txt and run a diff?

 

[john9527]

Also, I updated to 378.55

What's the result of the nvram show ... command on 378.55?

 

[jrmwvu04]

What's the result of the nvram show ... command on 378.55?

Just to add on because I said it didn't matter, it's probably worth it to do a factory reset after loading 378.55 before checking that.