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

[john9527]

Really liking this firmware with the Asus RT-AC68P, doing great here, has made this my go-to router. John, any thoughts about picking up RMerlin's new cosmetics for the wireless log? The new format is easier on the eyes and more accessible, but the information is there in the current format as well. I realize that merging new stuff into an older framework isn't easy, but it would be nice.

Just curious if you've given this any thought? And what those thoughts might be *smile*?

Yes, I gave it some thought, and that's why I did the format update to the current log .

Believe it or not, that change is over 1200 lines of code, across 7 files. Plus it has code in it to support the Quantenna hardware and AC3200 that would have to be ripped out. It's still on my list of possibles, but I'd probably end up using Merlin's code as a guide (especially the web code) and migrating the existing code from scratch.

Having said that, I had been playing with another change to the existing code to color code the wireless connections.....green for primary network and yellow for guest networks. I think it also makes the connections a bit easier to pick out. What do you think?

 

[Blinkyz]

Yes, I gave it some thought, and that's why I did the format update to the current log .

Believe it or not, that change is over 1200 lines of code, across 7 files. Plus it has code in it to support the Quantenna hardware and AC3200 that would have to be ripped out. It's still on my list of possibles, but I'd probably end up using Merlin's code as a guide (especially the web code) and migrating the existing code from scratch.

Having said that, I had been playing with another change to the existing code to color code the wireless connections.....green for primary network and yellow for guest networks. I think it also makes the connections a bit easier to pick out. What do you think?

View attachment 3668

Look great.Can you make the page refreshing every 3 sec like merlin?

 

[RMerlin]

Believe it or not, that change is over 1200 lines of code, across 7 files.

And that was one of the things that helped me decide to drop RT-N16 support, as I would have needed to rewrite that code once more, for that one SDK5 device.

Part of the change involves reverting my past changes to the various wireless log functions (so future GPL merges would be easier), and then write a separate set of routine to handle my display. Once for SDK6, and once for QTN.

 

[RMerlin]

Look great.Can you make the page refreshing every 3 sec like merlin?

Switching to an Ajax display would require a major internal redesign of the Asus display code (which amounts to a large part of those 1200 lines of changes ). The httpd code has to be rewritten to provide data in an array format rather than directly output the result to the webpage, like Asus's original code does.

 

[RogerSC]

Yes, I gave it some thought, and that's why I did the format update to the current log .

Believe it or not, that change is over 1200 lines of code, across 7 files. Plus it has code in it to support the Quantenna hardware and AC3200 that would have to be ripped out. It's still on my list of possibles, but I'd probably end up using Merlin's code as a guide (especially the web code) and migrating the existing code from scratch.

Having said that, I had been playing with another change to the existing code to color code the wireless connections.....green for primary network and yellow for guest networks. I think it also makes the connections a bit easier to pick out. What do you think?

I do like adding the colors, it does help draw one's eye to the significant information. I understand about the difficulty of porting code, you'd have to have a lot of uncommitted time to get that one done. Not likely that higher priorities wouldn't intervene *smile*.

Thanks so much for doing all the porting work, big job!

 

[Lusa]

About a week I have a strange problems with the AC68U router.
several times a day the router have internet drops and internet is slow.
I have turned off the modem for 30 minutes and reboot the router but the problem continues.
The router is connected to a Technicolor 7200 modem (Ziggo) the modem is set to bridge.
In the log of the modem are no strange messages. The ziggo webcare read the modem and could not discover problems.
Between the modem and router is a cat6 UTP cable.
UTP cat6 is good and for the test replace for another Cat6 UTP cable but the problem remains.
The log from the router showed the following:
DHCP query frequency set to Normal

Asus AC68U | Firmware:374.43_2-10j9527 (Merlin fork)

Apr 21 13:57:53 WAN Connection: Ethernet link up.
Apr 21 13:57:53 rc_service: wanduck 511:notify_rc restart_wan_if 0
Apr 21 13:57:53 dnsmasq[531]: read /etc/hosts - 5 addresses
Apr 21 13:57:53 dnsmasq[531]: read /etc/hosts.dnsmasq - 7 addresses
Apr 21 13:57:53 dnsmasq-dhcp[531]: read /etc/ethers - 9 addresses
Apr 21 13:57:53 dnsmasq[531]: using nameserver 62.179.xxx.xxx#53
Apr 21 13:57:53 dnsmasq[531]: using nameserver 213.46.xxx.xxx#53
Apr 21 13:57:53 stop_wan(): perform DHCP release
Apr 21 13:57:53 kernel: Attempt to kill tasklet from interrupt
Apr 21 13:57:53 kernel: device eth0 left promiscuous mode
Apr 21 13:57:53 kernel: br0: port 1(vlan1) entering forwarding state
Apr 21 13:57:54 kernel: device eth0 entered promiscuous mode
Apr 21 13:57:54 kernel: br0: topology change detected, propagating
Apr 21 13:57:54 kernel: br0: port 1(vlan1) entering forwarding state
Apr 21 13:57:54 kernel: br0: port 1(vlan1) entering forwarding state
Apr 21 13:57:54 miniupnpd[20416]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
Apr 21 13:57:54 miniupnpd[20416]: Failed to get IP for interface eth0
Apr 21 13:57:54 miniupnpd[20416]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Apr 21 13:57:54 dnsmasq[531]: read /etc/hosts - 5 addresses
Apr 21 13:57:54 dnsmasq[531]: read /etc/hosts.dnsmasq - 7 addresses
Apr 21 13:57:54 dnsmasq-dhcp[531]: read /etc/ethers - 9 addresses
Apr 21 13:57:54 dnsmasq[531]: using nameserver 62.179.xxx.xxx#53
Apr 21 13:57:54 dnsmasq[531]: using nameserver 213.46.xxx.xxx#53
Apr 21 13:57:54 dnsmasq[531]: read /etc/hosts - 5 addresses
Apr 21 13:57:54 dnsmasq[531]: read /etc/hosts.dnsmasq - 7 addresses
Apr 21 13:57:54 dnsmasq-dhcp[531]: read /etc/ethers - 9 addresses
Apr 21 13:57:55 rc_service: udhcpc 23193:notify_rc start_firewall
Apr 21 13:57:55 dnsmasq[531]: read /etc/hosts - 5 addresses
Apr 21 13:57:55 dnsmasq[531]: read /etc/hosts.dnsmasq - 7 addresses
Apr 21 13:57:55 dnsmasq-dhcp[531]: read /etc/ethers - 9 addresses
Apr 21 13:57:55 dnsmasq[531]: using nameserver 62.179.xxx.xxx#53
Apr 21 13:57:55 dnsmasq[531]: using nameserver 213.46.xxx.xxx#53
Apr 21 13:57:55 rc_service: udhcpc 23193:notify_rc stop_upnp
Apr 21 13:57:55 rc_service: waitting "start_firewall" via udhcpc ...
Apr 21 13:57:55 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Apr 21 13:57:56 rc_service: udhcpc 23193:notify_rc start_upnp
Apr 21 13:57:56 rc_service: waitting "stop_upnp" via udhcpc ...
Apr 21 13:57:56 miniupnpd[20416]: shutting down MiniUPnPd
Apr 21 13:57:57 dhcp client: bound 77.xxx.221.25 via 77.xxx.221.1 during 300 seconds.
Apr 21 13:57:57 miniupnpd[23243]: HTTP listening on port 51690
Apr 21 13:57:57 miniupnpd[23243]: Listening for NAT-PMP/PCP traffic on port 5351
Apr 21 14:07:20 WAN Connection: Ethernet link up.
Apr 21 14:07:20 rc_service: wanduck 511:notify_rc restart_wan_if 0
Apr 21 14:07:20 dnsmasq[531]: read /etc/hosts - 5 addresses
Apr 21 14:07:20 dnsmasq[531]: read /etc/hosts.dnsmasq - 7 addresses
Apr 21 14:07:20 dnsmasq-dhcp[531]: read /etc/ethers - 9 addresses
Apr 21 14:07:20 dnsmasq[531]: using nameserver 62.179.xxx.xxx#53
Apr 21 14:07:20 dnsmasq[531]: using nameserver 213.46.xxx.xxx#53
Apr 21 14:07:20 stop_wan(): perform DHCP release
Apr 21 14:07:20 kernel: Attempt to kill tasklet from interrupt
Apr 21 14:07:20 kernel: device eth0 left promiscuous mode
Apr 21 14:07:20 kernel: br0: port 1(vlan1) entering forwarding state
Apr 21 14:07:21 kernel: device eth0 entered promiscuous mode
Apr 21 14:07:21 kernel: br0: topology change detected, propagating
Apr 21 14:07:21 kernel: br0: port 1(vlan1) entering forwarding state
Apr 21 14:07:21 kernel: br0: port 1(vlan1) entering forwarding state
Apr 21 14:07:21 miniupnpd[23243]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
Apr 21 14:07:21 miniupnpd[23243]: Failed to get IP for interface eth0
Apr 21 14:07:21 miniupnpd[23243]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping.
Apr 21 14:10:48 miniupnpd[23393]: Failed to get IP for interface eth0
Apr 21 14:10:48 miniupnpd[23393]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Apr 21 14:10:48 dnsmasq[531]: read /etc/hosts - 5 addresses
Apr 21 14:10:48 dnsmasq[531]: read /etc/hosts.dnsmasq - 7 addresses
Apr 21 14:10:48 dnsmasq-dhcp[531]: read /etc/ethers - 9 addresses
Apr 21 14:10:48 dnsmasq[531]: using nameserver 62.179.xxx.xxx#53
Apr 21 14:10:48 dnsmasq[531]: using nameserver 213.46.xxx.xxx#53
Apr 21 14:10:48 dnsmasq[531]: read /etc/hosts - 5 addresses
Apr 21 14:10:48 dnsmasq[531]: read /etc/hosts.dnsmasq - 7 addresses
Apr 21 14:10:48 dnsmasq-dhcp[531]: read /etc/ethers - 9 addresses
Apr 21 14:10:54 WAN Connection: ISP's DHCP did not function properly.

The log continues
What goes wrong?
I apologize for my bad english..

 

[RMerlin]

Asus AC68U | Firmware:374.43_2-10j9527 (Merlin fork)

Apr 21 13:57:53 WAN Connection: Ethernet link up.

You probably also had a "Ethernet link down" message before that. This indicates a problem with either your modem or your ISP, as your modem physically disappeared from the router's Ethernet port. This most commonly happen if your modem crashed and rebooted.

 

[Lusa]

You probably also had a "Ethernet link down" message before that. This indicates a problem with either your modem or your ISP, as your modem physically disappeared from the router's Ethernet port. This most commonly happen if your modem crashed and rebooted.

Hi Merlin,
No I've searched for the "Ethernet link down" message but the firs message in the log is "WAN Connection: Ethernet link up."

Apr 23 01:10:22 HTTP login: logout successful
Apr 23 02:57:08 dnsmasq-dhcp[531]: DHCPNAK(br0) 192.xxx.xxx.201 54:fa:3e:20:4f:8d wrong server-ID
Apr 23 09:49:21 WAN Connection: Ethernet link up.
Apr 23 09:49:22 rc_service: wanduck 511:notify_rc restart_wan_if 0
Apr 23 09:49:22 dnsmasq[531]: read /etc/hosts - 5 addresses
Apr 23 09:49:22 dnsmasq[531]: read /etc/hosts.dnsmasq - 7 addresses
Apr 23 09:49:22 dnsmasq-dhcp[531]: read /etc/ethers - 9 addresses
Apr 23 09:49:22 dnsmasq[531]: using nameserver 62.xxx.xxx.196#53
Apr 23 09:49:22 dnsmasq[531]: using nameserver 213.xxx.xxx.196#53
Apr 23 09:49:22 stop_wan(): perform DHCP release

Today it's very onstabel again and drops a lot of time.
below a few lines from the log

Apr 23 09:49:58 WAN Connection: Ethernet link down.
Apr 23 09:49:58 stop_nat_rules: apply the redirect_rules!
Apr 23 09:50:03 WAN Connection: Ethernet link up.

Apr 23 09:50:09 WAN Connection: WAN was restored.
Apr 23 09:51:19 WAN Connection: Ethernet link up.
Apr 23 09:51:19 rc_service: wanduck 511:notify_rc restart_wan_if 0

Apr 23 09:51:19 stop_wan(): perform DHCP release
Apr 23 09:51:19 kernel: Attempt to kill tasklet from interrupt
Apr 23 09:51:19 kernel: device eth0 left promiscuous mode
Apr 23 09:51:19 kernel: br0: port 1(vlan1) entering forwarding state

Apr 23 09:51:20 miniupnpd[30325]: Failed to get IP for interface eth0

Apr 23 09:51:23 dhcp client: bound 77.xxx.xxx.25 via 77.xxx.xxx.1 during 259200 seconds.
Apr 23 09:51:23 miniupnpd[30394]: HTTP listening on port 59106
Apr 23 09:51:23 miniupnpd[30394]: Listening for NAT-PMP/PCP traffic on port 5351
Apr 23 09:51:30 WAN Connection: Ethernet link up.

Apr 23 09:51:31 stop_wan(): perform DHCP release

Apr 23 09:53:56 WAN Connection: Ethernet link up.

Apr 23 09:59:33 WAN Connection: Ethernet link down.
Apr 23 09:59:33 stop_nat_rules: apply the redirect_rules!
Apr 23 09:59:38 WAN Connection: Ethernet link up.
Apr 23 09:59:38 stop_wan(): perform DHCP release

Apr 23 09:59:43 WAN Connection: WAN was restored.
Apr 23 09:59:58 WAN Connection: Ethernet link up
Apr 23 10:00:04 WAN Connection: ISP's DHCP did not function properly.

Apr 23 10:00:09 WAN Connection: WAN was restored.
Apr 23 10:00:59 WAN Connection: Ethernet link up

Apr 23 10:01:00 stop_wan(): perform DHCP release

Apr 23 10:01:10 WAN Connection: Ethernet link up

Apr 23 10:01:11 stop_wan(): perform DHCP release

Apr 23 10:33:08 WAN Connection: Ethernet link up.

Apr 23 10:33:09 stop_wan(): perform DHCP release

Apr 23 10:33:29 WAN Connection: Ethernet link up

Apr 23 10:33:30 stop_wan(): perform DHCP release
>> No start WAN Connection: Ethernet link up <<

Apr 23 10:40:36 WAN Connection: Ethernet link down

Apr 23 10:40:41 WAN Connection: Ethernet link up

Apr 23 10:40:41 stop_wan(): perform DHCP release

Apr 23 10:40:47 WAN Connection: WAN was restored.
Apr 23 10:40:57 WAN Connection: Ethernet link up

Apr 23 10:40:58 stop_wan(): perform DHCP release

Apr 23 10:44:00 WAN Connection: Ethernet link up.

Apr 23 10:44:00 stop_wan(): perform DHCP release

Apr 23 10:44:06 WAN Connection: ISP's DHCP did not function properly.

Apr 23 10:44:11 WAN Connection: WAN was restored.
Apr 23 10:46:51 WAN Connection: Ethernet link down.
Apr 23 10:46:51 stop_nat_rules: apply the redirect_rules!
Apr 23 10:47:07 WAN Connection: Ethernet link up.

Apr 23 10:47:13 WAN Connection: WAN was restored.

I have use a other switch port of the TechniColor modem (in Bridge mode) but not solved the problem.
The log from the modem have no errors and at the time the link is down i see no strange things in the modem. It's a very strange problem.

 

[RMerlin]

Hi Merlin,
No I've searched for the "Ethernet link down" message but the firs message in the log is "WAN Connection: Ethernet link up."

Your second log contains multiple "Ethernet Link is down" messages. Start by replacing the Ethernet cable between the modem and the router, if it still fails check with your ISP. As I said, this is most likely either a modem, or an ISP issue (cablemodems will reboot themselves if they are having RF issues).

 

[RogerSC]

Hi Merlin,
No I've searched for the "Ethernet link down" message but the firs message in the log is "WAN Connection: Ethernet link up."

Today it's very onstabel again and drops a lot of time.
below a few lines from the log

Apr 23 09:49:58 WAN Connection: Ethernet link down.
Apr 23 09:59:33 WAN Connection: Ethernet link down.
Apr 23 10:40:36 WAN Connection: Ethernet link down
Apr 23 10:46:51 WAN Connection: Ethernet link down.

I have use a other switch port of the TechniColor modem (in Bridge mode) but not solved the problem.
The log from the modem have no errors and at the time the link is down i see no strange things in the modem. It's a very strange problem.

Just a quick comment here. You can use your browser text search functionality to search the router's system log. I use Chrome here, and typing "control-f" brings up the text search widget. It will then search the whole log, not just the part that's currently visible. This has been valuable to me for searching for errors or particular text strings in the router log.

If you already knew that, never mind *smile*.

 

[Blinkyz]

Hi.
For those on 11B
Im on V10E fork and it rock solid since but im willing to try 11B .I just want to know if someone have noticed any issues with V11 beta.

 

[endlesszeal]

first of all, thank you so much John for all the hard work you do!


my issue is, i noticed that switch from version 8 to version 10, my connections aren't as solid as before. My range seems like its not as far for both 2.4 and 5 and twice, my connection dropped for both signals.

Time Warner -> motorola SB6121 -> Tmobile w/ASUS 68U CFE and john fork v10 -> iPad, Macbook Pro, 2x Win7 ultimate and 2xSamsung S3.

When i flashed from 8 to 10, i telnet to clear nvram and used default settings except change ssid/wpa2 keys for WLAN and thats it. I did same thing when i flashed to V8 from previous version too. So I'm not sure why I am experiencing such a change when everything is exact same, room layout and gear. Only other thing is maybe a neighbor added a new router or some sort.

Any suggestions? I was thinking of flashing back to V8 if problem persist. Im not sure how to check the log and I rebooted last night to see if thats what it needed. I parcticulaty had a problem with google last night and youtube. both wouldn't load for 10 mins at a time for about an hour or so.

 

[jim769]

Been using VER-10 since it's release on my AC68R and have had no issues what so ever. In fact when i tried Merlins latest 52_2 i had to switch back to John's fork because certain devices were dropping the 5GHZ band and my Ipad was freezing loading web pages, switching back to VER-10 and all is good again. I would do a factory reset again using the WPS button method and reconfigure your settings and see if that helps.

 

[john9527]

Any suggestions? I was thinking of flashing back to V8 if problem persist. Im not sure how to check the log and I rebooted last night to see if thats what it needed. I parcticulaty had a problem with google last night and youtube. both wouldn't load for 10 mins at a time for about an hour or so.

Sorry I don't have any suggestions or ideas for you....the wireless subsystem hasn't changed at all during the life of the fork. Unfortunately, we're at the whim of a lot of things outside of our control...not only new access points being introduced in our neighborhoods, but other electronics as well....microwave ovens, baby monitors (this one seems a popular disruptor lately), wireless alarm systems.....

For your browsing problem, it sounds like more of an ISP problem. I just went through the same sort of problem, with slow loading pages and pauses. Did all the diagnostics...modem logs, syslogs, reviewed all my latest 'beta' commits. Then after about 2 days, I find my modem had rebooted and I had a new WAN address. I'm now running better than I ever had.

 

[endlesszeal]

Sorry I don't have any suggestions or ideas for you....the wireless subsystem hasn't changed at all during the life of the fork......

I figured as much, but I was hoping maybe there was some sort of magic super setting that I might not know about haha. I hoping and not hoping it is an issue with ISP and it gets resolved. However, I do hate that I have TW because out of ATT/SBC, Comcast, and Charter, I feel like TW is the worst ISP i have ever had due to mainly it being down so often (once a month is a lot to me).

So i did as Jim suggested and resetted the nvram via WPS method and restarted my modem. Ill see how that goes for a few days.

Thanks again John for everything.

 

[ml70]

So i did as Jim suggested and resetted the nvram via WPS method and restarted my modem. Ill see how that goes for a few days.

On my AC66 i have noticed that sometimes after a fw upgrade, even a small next version, the router starts rebooting itself arbitrarily, approx once per day. The only solution is to reset the settings to factory defaults and then reconfigure the router, after which it will be rock solid and stay up at least a month without problems.

 

[ml70]

Would there be any chance of getting the fixed ipv6 (tunnel) code into this release? 374.43 is infamous for disabling the hw acceleration with an ipv6 tunnel, something that's very intolerable as ipv6 is the only way to have a public ip address on a normal isp nat'ed (or double nat'ed) connection.

This should be fixed in the recent versions of Asus fw, unfortunately i have no idea at which point the fix was done. Changing to recent versions is not possible since minidlna/inotify is broken there and this is one of the main uses for my router, without inotify a minidlna -R scan will take several hours and is out of the question.

 

[RogerSC]

On my AC66 i have noticed that sometimes after a fw upgrade, even a small next version, the router starts rebooting itself arbitrarily, approx once per day. The only solution is to reset the settings to factory defaults and then reconfigure the router, after which it will be rock solid and stay up at least a month without problems.

Yes, this is a good reason why resetting to factory defaults after flashing firmware, and then reconfiguring is often recommended as a "best practice". Remember though, if you ever find any firmware that is good enough to stay with for a while, aside from security fixes, which we do need, then you can do a lot less firmware upgrades. Unless you like testing and playing with new firmware versions for fun...I've heard that there are people that enjoy doing that *smile*.

 

[john9527]

Would there be any chance of getting the fixed ipv6 (tunnel) code into this release? 374.43 is infamous for disabling the hw acceleration with an ipv6 tunnel, something that's very intolerable as ipv6 is the only way to have a public ip address on a normal isp nat'ed (or double nat'ed) connection.

This should be fixed in the recent versions of Asus fw, unfortunately i have no idea at which point the fix was done. Changing to recent versions is not possible since minidlna/inotify is broken there and this is one of the main uses for my router, without inotify a minidlna -R scan will take several hours and is out of the question.

Sorry to disappoint, but the ipv6 stack is one of the items that I'm not going to touch on the fork. My feeling from reading the various threads is that whether one implementation works better that another (or conflicts with NAT acceleration) is largely tied to the ISP and their ipv6 implementation. Changing it may make some users happy, but could just as easily create issues for others. Plus, it's such a large change, there's just too much opportunity for error.

As far as the minidlna/inotify issue, that has been fixed in Merlin's FW for a long time, and then also in ASUS's stock firmware.

From Merlin's commit log...
- minidlna: Staticly link with a precompiled libsqlite3 that has safe threading enabled, so BWDPI can continue using the shared, non-thread safe build.
then later
- minidlna Remove our static sqlite3 lib for minidlna now that Asus has reverted to building bwdpi with threadsafe support enabled in sqlite3

Just as an FYI....you can also turn off the scan that occurs during a reboot by

nvram set dms_rescan=0
nvram commit

 

[john9527]

On my AC66 i have noticed that sometimes after a fw upgrade, even a small next version, the router starts rebooting itself arbitrarily, approx once per day. The only solution is to reset the settings to factory defaults and then reconfigure the router, after which it will be rock solid and stay up at least a month without problems.

When staying within the 'fork' releases, there really shouldn't be a reason to have to do a factory reset. I basically haven't done one in months even when moving up and down between fw levels for testing and development, sometimes doing 3 or 4 firmware loads in a day (the exception recently doing a factory reset to test my NVRAM Utility).

The one thing to check on (especially if you are using multiple OpenVPN certificates) is your nvram usage on the tools page. Once you start running out of space, a factory recent can provide some temporary relief from all sorts of strange issues. And if you are running low on space, there are a couple of wiki entries on how to move the OpenVPN certs out of nvram to free up space.