What's new

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

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

My deepest condolences to John and his family through this difficult time. The forums and users will hold until you get back. Your work and Merlin's are always much appreciated.

Sincerely,
 
I've been seeing a strange-looking Tools page for at least several versions. The page takes a long time to load, and then it only partially appears. Note the missing data items. Any ideas?
Glad you got it figured out. I've only seen this a couple of times, most recently before you on someone who 'converted' a TM1900 to AC68U. It can always be fixed with a factory reset. I've never been able to recreate it, so haven't been able to track down what was corrupted in nvram. If anyone ever sees it again, please save your nvram settings with 'nvram show' to a file so I might be able to see what's up.
 
This 15x-release is troubled.

For the first time since using John's fork on my AC56U I had to go back a release. I've tried 15E3 and 15E5, and with both, my Android devices (Galaxy Note 3, Moto X Play, Xperia Z Ultra) tended to drop connection sometimes during their standby. They are on 5 GHz, on 2.4 I have no permanently connected devices going into a standby (the Chromecast stick never does). Now back on 14E1, the connections are solid again.


Edit: no resets were made, Regulation Mode is off, regional limits are off with "#a/0", 5 GHz set to 200 mW.

If you are using any of the '#a' mods, make sure that you specify a channel for the 5GHz band, otherwise the router may 'auto' change to a different channel that isn't supported by your client. (Nothing changed in this in the V15 builds over previous builds, but there may have been some external noise causing the change).
 
I'm noticing that in a version 14 i was able to connect to the vpn with both my laptop and my iphone using openvpn. This isnt the case anymore and its trying to assign an IP thats already assigned. see this in the logs:

MULTI: new connection by client 'client' will cause previous active sessions by this client to be dropped. Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect
Hmmm.....there was a change that removed an invalid topology parm for VPN servers running in TAP mode. Shouldn't have affected things, but????

I did do a check against the latest code, and they did explicitly add the 'duplicate-cn' option as part of the auto config gen when it didn't conflict with other options. I backported those changes for the V16 release so it shouldn't be required to be added manually then.
 
I have a small question, maybe somebody can help me out.
Using my RT-N66U in a student residence as a wireless acces point.
Students only gain internet access after logging into the university network,
so the access point itself isn't connected to the internet.
Everytime I do a firmware upgrade, I manually adjust the date through ssh with the "date -s ...." command since NTP needs a live internet connection.
With the last release the AP keeps flooding my logs. (probably John has been busy with the new NTP functions)

"Nov 24 14:11:12 ntp: NTP update failed after 5 attempts"


Is there a way to disable the NTP log messages? I know it doesn't sync, but no need to remind me every minute ;-)

Thanks a lot.
Interesting environment, and actually needs a bit more than just disabling the update failed messages (more things are becoming dependent on the router 'knowing' it has a valid date, for instance the new reboot scheduler). I'm working on an update/option that will disable the NTP updates entirely, but fake out the router that it has a valid date/time so you can then set the time manually...
 
Flashed to 15e5, seems stable however I can no longer see RSSI values for 2.4Ghz. Only shows '??dbm' for connected devices.

Edit:My bad..it happens on 14e1 as well at times...doesn't affect anything though. Great release. Will post back on stability after a few days.
This is a known problem with the older drivers in the fork. I worked with another user in the past trying to add retries to the data collection in case it was a short transient to no avail. The RSSI values will come back at the drivers discretion :) Sorry.
 
So it looks to me like whatever mechanism is used to obtain the traffic stats is getting corrupted (overflow?) somewhere between 106Mbps and 158Mbps. Although it is strange that it would also effect to smaller upload values.

Is this a known feature/bug? Does anybody know how the router obtains the traffic stats? Can anyone confirm what I am seeing or is it something unique to my setup?

Just curious. TIA
My ISP tops out at about 60Mbps so I can't test that end. But I did do a measure between a wireless AC client and wired PC which showed up correctly in the monitor (on both the wired and wireless 5GHz tabs) at my usual ~250Mbps.

One thing that's been a contributor to things like this in the past is NAT Acceleration.....are you running with it on or off?
 
Last edited:
Thanks for coop! That was interesting and long way to go. Sometimes it worked, sometimes not, yet it bugged me that ping/traceroute6/wget were always fine to ipv6.test-ipv6.com page. Win10 was also highly suspicious in my list of candidates to rule out.

John, do you still have HE ipv6 tunnel setup? If yes, have you set HW acceleration disabled?
Yes, still using HE Tunnel and it works fine with my AC68 with HW acceleration. Sorry I missed it, but what router are you using? There have been some reports of problems on the MIPS based routers in the past with IPv6/HW acceleration.

Just for an experiment, you might try unchecking the 'Enable IPv6 MTU Advertisement' checkbox near the bottom of the IPv6 setup page. For some unknown reason, this has helped native IPv6 to work on some ISPs....maybe it might help here as well.
 
Just thought I'd add a pointer to this post for anyone wishing to move from this fork to the latest Merlin builds on the ARM routers.
http://www.snbforums.com/threads/updating-to-latest-merlin-build-for-rt-ac68u.28873/#post-221522

Net is that with the increasing size of the firmware levels, an updated CFE is no longer sufficient to allow the upgrade directly. In addition to having an upgraded CFE, the base 'come from' code must also support a 64M ROOTFS. So, in order to upgrade, you'll need to do an intermediate upgrade....376.3636 ASUS OEM or 378.55 Merlin will do the trick to get you to 378.56 and above.
 
My ISP tops out at about 60Mbps so I can't test that end. But I did do a measure between a wireless AC client and wired PC which showed up correctly in the monitor (on both the wired and wireless 5GHz tabs) at my usual ~250Mbps.

One thing that's been a contributor to things like this in the past is NAT Acceleration.....are you running with it on or off?
Hi John. Thanks for asking but I think it's a bit of a red herring actually.

After testing different kinds of download (with and without NAT acceleration) it's only a problem when I max out the download bandwidth using something like speedtest.net.

Other types of download, like multiple torrents, or downloads which never quite reach 100% capacity are not a problem. Even at 99.9% the traffic monitor works OK.

But with speedtest.net as the download speed approaches 150Mbps the routers SIRQ goes up to 100% and the webui becomes almost completely unresponsive. Even an SSH session only responds in fits and starts. WAN to LAN transfers are unaffected though.

When the speed test completes the traffic graph does a kind of "accelerated catch up". It's at this point that the graph draws the stupidly high values.

So I guess it's something to do with the single-threaded nature of the speed test. As it doesn't appear to impact the LAN clients, and it only happens when performing a synthetic benchmark, I'm inclined to just ignore it.


P.S. In case you're wondering, I did the testing with different browsers, and with the download running on one PC whilst I watched the traffic monitor on another.
 
Dear John, after installing your -fantastic- firmware on my N66U, I decided to install it on my brand new AC68U.
Everything is fine with exclusion of NTP.
After rebooting the router didn't synchronize the time automatically but I have to hit APPLY on the ADMINISTRATION->SYSTEM menu.
Otherwise it not synchronize and timestamp on the attached hard disk are completely wrong.

Thank you for your fantastic work!

P.S. Here below extract of my log file after hitting APPLY
Jan 2 02:51:56 syslogd started: BusyBox v1.20.2
Jan 2 02:51:56 kernel: klogd started: BusyBox v1.20.2 (2015-11-11 07:51:25 MST)
Jan 2 02:51:56 dropbear[4374]: Running in background
Jan 2 02:51:56 httpd: start httpd
Jan 2 02:51:56 start_nat_rules: apply the nat_rules (/tmp/nat_rules_ppp0_eth0)!
Nov 21 21:53:24 start_nat_rules: (/tmp/nat_rules_ppp0_eth0) success!
Nov 21 21:53:24 rc_service: ntp 4366:notify_rc restart_upnp
Nov 21 21:53:24 rc_service: waiting "restart_time;restart_upnp" via ..

If the NTP update failed, there should be failure messages in the syslog (will put out a log entry for every 5 consecutive attempts that fail).
Also, the default is to not log successful NTP updates. You can change this and also log the successful updates by entering via telnet/ssh

Code:
nvram set ntp_log=1
nvram commit

It's possible that there was a bad nvram entry that hitting apply corrected. Please post back if you continue to have a problem.
 
Ok, I can confirm that Aicloud Sync is broken in this fork.
I personally don't use AICloud Sync... Is anyone else using AICloud Sync successfully? I did see that in the newer code levels it's listed as AICloud 2.0, but I'm not sure what has changed.
Also "config save" seems broken, because if I save my config, do a factory reset and insert the saved config a lot of parameters remain defaulted and not mine.
I just tested a save/reset/restore and everything came back fine. Just to make sure, remember you cannot restore the settings from one code level to another with the built in Save/Upload settings.
 
If the NTP update failed, there should be failure messages in the syslog (will put out a log entry for every 5 consecutive attempts that fail).
Also, the default is to not log successful NTP updates. You can change this and also log the successful updates by entering via telnet/ssh

Code:
nvram set ntp_log=1
nvram commit

It's possible that there was a bad nvram entry that hitting apply corrected. Please post back if you continue to have a problem.


Hi John ..

First of all .. My condolences to you and your family.

I am running the RT-AC68U since 3 weeks without reboot - no problems so far.
Today I have seen that the router time has 7 seconds difference to the ntp servers time.

The ntpd daemon does not keep the time in sync anymore ?

Thanks for your help.
 
Hi John ..

First of all .. My condolences to you and your family.

I am running the RT-AC68U since 3 weeks without reboot - no problems so far.
Today I have seen that the router time has 7 seconds difference to the ntp servers time.

The ntpd daemon does not keep the time in sync anymore ?

Thanks for your help.
Actually, it's the opposite. Prior to V15, the ntp update code was bugged such that it never fired again after the router was booted and set the time.

Just to make sure, try setting the router to log successful updates via telnet/ssh with
Code:
nvram set ntp_log=1
nvram commit
reboot not necessary after changing this setting.

Then you should see entries like this in the syslog
Code:
Dec  3 05:59:57 ntp: start NTP update
Dec  3 05:59:57 ntp: NTP update successful after 1 attempt(s)

For me, it's been very accurate. I have a PC that I'm using with Windows Media Center as my main home theater that has a RTC that runs a bit fast. I'm using the router as my network SNTP server to update it's clock and it's kept things right in sync (comparing the PC clock with the clock on my cable box that I still have)

I may also re-think the default logging setting for the next release.
 
First, my thanks to all the users who helped out each other during my absence over the last couple of weeks. It was a tough holiday for me, as my mother passed away unexpectedly. Things are still going to be a bit hectic for me, but I'll have a bit more time now to start easing back into things.

I'll be making a pass through recent posts over the next few days to catch up on the activity and seeing what, if anything, I may be able to add to the discussions.

Thanks again to everyone for their help.
Sorry for your loss. My condolences. Please take care of your family and yourself in this difficult time.
 
Yes, still using HE Tunnel and it works fine with my AC68 with HW acceleration. Sorry I missed it, but what router are you using? There have been some reports of problems on the MIPS based routers in the past with IPv6/HW acceleration.

Just for an experiment, you might try unchecking the 'Enable IPv6 MTU Advertisement' checkbox near the bottom of the IPv6 setup page. For some unknown reason, this has helped native IPv6 to work on some ISPs....maybe it might help here as well.
Ah, forget that your AC68 is ARM. Yep cristobal07 and me happened to have RT-N16 and HE tunnel set up. He had a problem that IPv6 tests from the router such as ping, traceroute6, wget -6 ipv6.test-ipv6.com worked out moreless nicely, but failed miserably on any device behind the router (Win10, Win7, Android smartphone).
He had run and presented enormous quantity of tests until it bugged me that HW Accel could do something wrong with IPv6 tunneled traffic. He just disabled HW Acceleration and got his first 10/10 test-ipv6.com result.
I've had HW Accel disabled since I've turned on IPtraffic monitoring and mostly no problems with IPv6 HE tunnel. The strange thing I found out is that even with IPtraffic monitoring=off and HW Accel=on in my setup IPv6 HE tunnel still works just the same.

P.S. Regarding what you have proposed 'Enable IPv6 MTU Advertisement' didn't have had any noticeable impact. I've it checked and running fine, as is cristobal07.
 
This is a known problem with the older drivers in the fork. I worked with another user in the past trying to add retries to the data collection in case it was a short transient to no avail. The RSSI values will come back at the drivers discretion :) Sorry.

No need to apologise for Asus' mistakes John! :D :) It has been a week now with the router on, no dropped connections on any of the iphones in the house (switching between 2.4/5 at their liking, same SSID) or any other device. Shows full strength on my TV at 5Ghz, which wasn't the case with newer drivers. Media server works without rescanning on every reboot, I even upgraded to 15e5 without a rescan. Openvpn has been working without issues.
All in all a great release. Thanks a lot man.

EDIT: this is on a n66u
 
Last edited:
What is the best way to use your
NVRAM Save/Restore Utility
Should I have it on a USB Drive?
The QuickStart file included in the download describes how to set it up on a USB stick, which is the simplest way, especially for Windows users that may not be familiar with Linux. You could use a USB drive by adjusting the paths to point to the install directory on that drive. I'm always looking to improve the directions, so if you run into problems please follow up in the utility thread.....
http://www.snbforums.com/threads/user-nvram-save-restore-utility-r22.19521/
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top