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

[mustafa803]

I did a factory reset for the RT-N16 and adjusted the wireless settings in the General/professional pages to what it was before factory reset and here is what I got this time.

if I try to use the command nvram get wl_txpower I get no result but if I use nvram get wl_TxPower I get a result of 80

nvram get wl0_TxPower also gives me a result of 80.

nvram get wl1_TxPower does not give me any result. Is this expected?

Also I noticed that the my wireless signal is a lot weaker than before resetting. I am getting a number between -54dbm and -58dbm. Definitely not the result I was hoping for especially that I was getting around -45dbm before resetting.

 

[john9527]

But one thing I noticed with the bandwidth limiter, is that the download speed it capped, but the upload speed still remains uncapped.

Thanks for the report.....was able to recreate it. When I changed the method of clearing the iptables entries for QoS I missed a required change in the bandwidth limiter (need to move one line of code). I'll get an update out for the weekend.

I still have the problem with QOS in general, that is when I turn it on, I lose about 20Mb/s download speed straight off.

Remember that QoS will disable CTF.....so you will lose the HW acceleration benefit when enabling QoS. What speeds are we talking about?

 

[john9527]

I did a factory reset for the RT-N16 and adjusted the wireless settings in the General/professional pages to what it was before factory reset and here is what I got this time.

if I try to use the command nvram get wl_txpower I get no result but if I use nvram get wl_TxPower I get a result of 80

nvram get wl0_TxPower also gives me a result of 80.

nvram get wl1_TxPower does not give me any result. Is this expected?

Also I noticed that the my wireless signal is a lot weaker than before resetting. I am getting a number between -54dbm and -58dbm. Definitely not the result I was hoping for especially that I was getting around -45dbm before resetting.

So things are now back in line with the base Merlin as I would have expected.

The -45 dBm was definitely unexpected vs the base Merlin of -55dBm (it represents over an 8X increase in the transmitted power). It's likely there was a change in the driver such that the fork driver was now not interpreting the 'newer' driver parameters correctly. It's anybody's guess as to what was really happening (you may have had higher power, but much increased noise or ower throughput). Best way to compare levels is by doing some actual throughput tests.

You still can adjust the power level on the fork at the bottom of the Professional page (value in mW, default is 80mW). Just as a quick reminder for everyone, this is but one input into determining the maximum power. Regional restrictions and router/client negotiations for 'best' signal can override this setting.

As far as the wl1_ parameters, those are for the 5GHz radio, not present on the N16.

 

[mustafa803]

So things are now back in line with the base Merlin as I would have expected.

The -45 dBm was definitely unexpected vs the base Merlin of -55dBm (it represents over an 8X increase in the transmitted power). It's likely there was a change in the driver such that the fork driver was now not interpreting the 'newer' driver parameters correctly. It's anybody's guess as to what was really happening (you may have had higher power, but much increased noise or ower throughput). Best way to compare levels is by doing some actual throughput tests.

You still can adjust the power level on the fork at the bottom of the Professional page (value in mW, default is 80mW). Just as a quick reminder for everyone, this is but one input into determining the maximum power. Regional restrictions and router/client negotiations for 'best' signal can override this setting.

As far as the wl1_ parameters, those are for the 5GHz radio, not present on the N16.

Thanks for the explanation.

There is no power level adjustment at the bottom of the professional page. Does that mean that the rt-n16 router has a constant tx power value? Or does it mean that the router adjusts that number automatically?

 

[john9527]

Thanks for the explanation.

There is no power level adjustment at the bottom of the professional page. Does that mean that the rt-n16 router has a constant tx power value? Or does it mean that the router adjusts that number automatically?

Interesting as it never came up before, but you are correct that ASUS doesn't support changing the max power level on the N16 (I checked the code). So, it's basically under the router's control.

If you are an 'experimenter', you could try changing that max power setting manually and see if you see any difference.

nvram set wl0_TxPower=number

where number is between 20 and 200 ( the default is 80). Reboot the router after making the change.

 

[Nullity]

Interesting as it never came up before, but you are correct that ASUS doesn't support changing the max power level on the N16 (I checked the code). So, it's basically under the router's control.

If you are an 'experimenter', you could try changing that max power setting manually and see if you see any difference.

nvram set wl0_TxPower=number

where number is between 20 and 200 ( the default is 80). Reboot the router after making the change.

@mustafa803

Also, remember to "nvram commit" after modifying nvram parameters. (Then restart.)

 

[john9527]

@mustafa803

Also, remember to "nvram commit" after modifying nvram parameters. (Then restart.)

Duh...brain check on my part.....thanks!

 

[mustafa803]

Ok. Here are my findings.

I changed the number from 80 to 200 but I kept getting the same signal strength...around -55dbm.

So I did the following:

I installed 380.57.7_HGG-FINAL and did a factory reset just to see what would happen. I checked the nvram txpower and it gave me 70. I am assuming it is 70%.......the signal strength was around -55dbm (I installed 380.57.7_HGG-FINAL a few days ago just to try it out and I got a signal strength of around -45dbm so I was really confused as to why it didn't give me a similar number this time)

After installing 380.57.7_HGG-FINAL and doing a factory reset I installed Merlin 378.50 without doing a factory reset and I got a signal strength of -55dbm.

Then I installed V17E8 without doing a factory reset and I got a signal strength of -45dbm. Then I did a factory reset and the signal strength dropped to -55dbm.

In all cases I made sure all the wireless settings were the same and the signal strength measurement was taken from the same place.

Would it be a good idea to install merlin 378.5 then install V17E without doing a factory reset just to maintain the strong wireless signal? This is the second time I try this method and in both times I got a similar strong signal strength of around -45dbm.

I live in a very crowded area and I see anywhere between 12-15 different wireless connections on the 2.4GHZ band. Does this have any effect on the wireless signal strength?

Also, what is the difference between wl_TxPower and wl0_TxPower?

I have been using an Asus RT-Ac68U for the past 10 months with merlin firmware and I was getting a strong signal on both the 2.4GHZ and 5GHz band...around -45dbm...The signal was strong up to FW 378.56_2. After installing 380.57 and 380.58 the signal strength dropped so I had to revert back to 378.56_2 to maintain the strong signal again. I then decided to downgrade to RT-N16 after wiring all my major devices using ethernet. I was hoping to get a similar wifi performance out of the n16 given that both the N16 and AC68U use 3x2dbi antennas.

The 2 issues I am having with the Rt-N16 is the weaker wifi signal strength and also some stuttering when I try to cast my phone screen onto the tv using chromecast. I notice freezing and stuttering that I did not see when I was using the AC68U 5GHz band. I never tried casting using the AC68U 2.4GHz.

So, I still have not decided if I will keep it or just sell it and go back to AC68U.

 

[Nullity]

Ok. Here are my findings.

I changed the number from 80 to 200 but I kept getting the same signal strength...around -55dbm.

So I did the following:

I installed 380.57.7_HGG-FINAL and did a factory reset just to see what would happen. I checked the nvram txpower and it gave me 70. I am assuming it is 70%.......the signal strength was around -55dbm (I installed 380.57.7_HGG-FINAL a few days ago just to try it out and I got a signal strength of around -45dbm so I was really confused as to why it didn't give me a similar number this time)

After installing 380.57.7_HGG-FINAL and doing a factory reset I installed Merlin 378.50 without doing a factory reset and I got a signal strength of -55dbm.

Then I installed V17E8 without doing a factory reset and I got a signal strength of -45dbm. Then I did a factory reset and the signal strength dropped to -55dbm.

In all cases I made sure all the wireless settings were the same and the signal strength measurement was taken from the same place.

Would it be a good idea to install merlin 378.5 then install V17E without doing a factory reset just to maintain the strong wireless signal? This is the second time I try this method and in both times I got a similar strong signal strength of around -45dbm.

I live in a very crowded area and I see anywhere between 12-15 different wireless connections on the 2.4GHZ band. Does this have any effect on the wireless signal strength?

Also, what is the difference between wl_TxPower and wl0_TxPower?

I have been using an Asus RT-Ac68U for the past 10 months with merlin firmware and I was getting a strong signal on both the 2.4GHZ and 5GHz band...around -45dbm...The signal was strong up to FW 378.56_2. After installing 380.57 and 380.58 the signal strength dropped so I had to revert back to 378.56_2 to maintain the strong signal again. I then decided to downgrade to RT-N16 and I was hoping to get a similar wifi performance out of it given that both the N16 and AC68U use 3x2dbi antennas but I still have not decided if I will keep it or just sell it and go back to AC68U.

As john9527 mentioned, you should be doing real-world throughput tests rather than relying on the reported signal strength.

iperf or simply observing a LAN file transfer (SMB, FTP, etc) is a "real-world" measurement.

 

[Qu4d]

I've updated to the latest version on 17.04; everything is working great since then.

 

[tyspeed42]

Installed 17E8 on newly acquired Asus AC68W, super smooth firmware upgrade from the Asus stock, no issues what so ever, and it comes clocked at 1000/800. Thanks again John

Decided to overclock this router abit since John firmware has been rock solid, safe to say its running at 1400,800 stable 68c temps, im not complaining, thanks again John for the hard work.

 

[john9527]

Just a quick note....it seems Microsoft has done something to change it's relationship with Bitly, so the download link has changed....

http://bit.ly/24kEGp6

(also updated in the first post)

 

[john9527]

For those who would like the latest...and...
This beta includes some fixes for QoS Bandwidth Limiter. If you are using the new Bandwidth Limiter function, it is recommended that you upgrade to this release.

BETA RELEASE: Update-18B1
25-April-2015
Merlin fork 374.43_2-18B1j9527
Download http://bit.ly/1UGjcOX
============================

The major changes/notes are:

• Fixes for Bandwidth Limiter
  • Upload limits not working - @snb
  • Priorities not being set correctly when adding new entries
    Important: If you are using the bandwidth limiter with multiple entries, please remove and re-add all the entries such that the priorities can be set correctly.
• AC56 and AC68 ARM routers are now compiled with a 64M rootfs
  For fork users with a current CFE, upgrade to this firmware as usual, then you will be able to change to Merlin builds without the need for an intermediate code upgrade.
  If you have an AC68U/R and still haven't updated your CFE for 64M rootfs support (CFE level 1.0.2.x - check on Tools>Sysinfo page), you will need to do a one-time intermediate firmware load to update your CFE prior to loading V18. The official ASUS level with the upgrade are in folder ASUS-OEM-CFE in the same directory with the beta code.
  It appears that all released CFEs for the AC56U/R include 64M rootfs support.
• Enhancements to the firmware upgrade process (backport)
• Default NAT loopback method changed to ASUS implementation - @topmusic
  This should reduce problems with NAT loopback on MIPS based routers.
• GUI warning (exclamation point) on low NVRAM space
• Router no longer reboots when adding or deleting port forwards - @Sprokket
• System log > DHCP Leases page is now sorted by time remaining
• Fix for unneccessary router logons when refreshing gui pages
• mktemp command supported
  For those who wish to use EasyRSA 3 to generate certs on the router.

As always, a reminder to users with MIPS routers to have a backup of /jffs just in case!

SHA256

0ece72d0ff2f76f639d87d29931bcc1e4457af826410f1c2265d74806e3d7ce4 *RT-AC56U_3.0.0.4_374.43_2-18B1j9527.trx
a8a67baf8723310cde13f8177bcd08a2e816d0dc21830dfc68ce357688e3db18 *RT-AC66U_3.0.0.4_374.43_2-18B1j9527.trx
164f522647d13b1b9b6b6b28658e9f90fe31d83133cc055b555667a1a92af37c *RT-AC68U_3.0.0.4_374.43_2-18B1j9527.trx
b3a7240176e0b1841c9105579b9ec221511b527e425b20ef76daffea85290b0a *RT-N16_3.0.0.4_374.43_2-18B1j9527.trx
b522042e3955b9628fc6500ece4d25cf804e99834913b4560621bb97cd51e54c *RT-N66U_3.0.0.4_374.43_2-18B1j9527.trx

 

[jrmwvu04]

Fix for unneccessary router logons when refreshing gui pages

I'm still seeing this behavior. Safari 9.1, 10.11.4

Apr 27 20:03:33 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:03:36 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:03:37 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:03:51 dropbear[1269]: Child connection from 192.168.1.50:50894
Apr 27 20:03:53 dropbear[1269]: Password auth succeeded for 'admin' from 192.168.1.50:50894
Apr 27 20:04:18 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:04:19 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:04:36 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:04:37 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:04:39 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:04:40 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:04:53 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:04:53 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:04:55 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:04:56 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:04:59 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:05:00 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:05:02 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:05:03 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:05:06 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:05:07 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:05:16 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:05:17 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:05:19 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:05:32 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:05:34 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:05:35 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:06:09 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:06:10 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:06:13 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:06:14 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:06:16 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:06:17 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:06:20 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:06:21 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:06:27 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:06:28 HTTP login: login 'admin' successful from 192.168.1.50

edit: otherwise, everything is smooth. I don't know if it's required, but I reset the nvram after upgrading to 18B1. Force of habit.

 

[wbennett77]

Just did the two step upgrade as my CFE was at 1.0.1.9. Even after processing both steps the CFE has not changed to the desired 1.0.2x. The firmware is showing 3.0.0.4.374.43_2-18B1j9527. Should I try it again?

 

[jrmwvu04]

Just did the two step upgrade as my CFE was at 1.0.1.9. Even after processing both steps the CFE has not changed to the desired 1.0.2x. The firmware is showing 3.0.0.4.374.43_2-18B1j9527. Should I try it again?

If you haven't already, clear the nvram and power cycle. It seems to be less problematic if you physically remove power from the device as opposed to rebooting via GUI. I've seen reports in other threads that sometimes the values will still be reading from your nvram if you do not.

 

[wbennett77]

If you haven't already, clear the nvram and power cycle. It seems to be less problematic if you physically remove power from the device as opposed to rebooting via GUI. I've seen reports in other threads that sometimes the values will still be reading from your nvram if you do not.

Just did all that and still shows 1.0.1.9. Not sure what else I can try.

 

[john9527]

I'm still seeing this behavior. Safari 9.1, 10.11.4

Apr 27 20:03:33 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:03:36 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:03:37 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:03:51 dropbear[1269]: Child connection from 192.168.1.50:50894
Apr 27 20:03:53 dropbear[1269]: Password auth succeeded for 'admin' from 192.168.1.50:50894
Apr 27 20:04:18 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:04:19 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:04:36 HTTP login: login 'admin' successful from 192.168.1.50
Apr 27 20:04:37 HTTP login: login 'admin' successful from 192.168.1.50
...
Apr 27 20:06:28 HTTP login: login 'admin' successful from 192.168.1.50

edit: otherwise, everything is smooth. I don't know if it's required, but I reset the nvram after upgrading to 18B1. Force of habit.

This one is going to be tough. The fix that was referenced was actually reverting a change from V17 that I thought may have helped the case when you tried to logon from two different clients at once, and had a side effect that on a page refresh (or page change) it would cause a re-logon. Unfortunately, I have no way to test Safari....I check
Firefox, IE11 under Windows 7
Firefox, Chrome under Linux Mint (Ubuntu)

If you switch to another gui page, and then back to the syslog page, did the logons continue while you are on the other page (that is, is this unique to the syslog page?)

 

[jrmwvu04]

Just did all that and still shows 1.0.1.9. Not sure what else I can try.

If you're adventurous you can try this.

http://www.snbforums.com/threads/cfe-bootloader-update.8259/

Be careful though. If you don't know what you're doing you can do damage.

 

[john9527]

Just did the two step upgrade as my CFE was at 1.0.1.9. Even after processing both steps the CFE has not changed to the desired 1.0.2x. The firmware is showing 3.0.0.4.374.43_2-18B1j9527. Should I try it again?

If the firmware is showing as V18B1, it means it took and you have the 64M rootfs.....so, one of two things....
For some reason NVRAM isn't being updated, or I'm mistaken on the CFE level for 64M support on the AC56U (1.0.1.9 was the initial release level, and I thought it was 32M rootfs).

To rule out the first case, ssh/telnet to the router and enter

cat /dev/mtd0 | grep bl_version

If that shows 1.0.1.9 also, I'm going to assume that the initial AC56U release also included 64M support and I'll update the doc.

Thanks for the 'test'.