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

[Dfects]

Thank you very much Just backed up my settings with John's other awesome tool so will give it a go soon.

 

[msilenus]

Hi all,

We have an old RT-AC66U that's served us well and is set up how we like and which we'd very much like to keep. However, after recently switching ISPs to a small local fiber provider (no modem or DSL in the picture), we started getting network disconnects/dropoffs with it. Maybe once every few days it will just lose the ability to connect to the WAN until I have it re-detect settings. With the Merlin/stock firmware it complains that the "ISP's DHCP does not function properly." Now I'm on John's fork and the error is less specific ("Unable to connect to the Internet. Please double-check your account data...") --but I suspect it's the same underlying issue.

This is with a pretty basic setup. We're getting a public DHCP address down from them, and NATing it out to about ten clients. We have a hard drive plugged in, but aren't using most of the other special features. IPv6 is disabled.

I did raise the issue with the new ISP, and they think it's the router. Probably correct, because googling suggests that a lot of people complain about this with Asus routers. I've tried tweaking the DHCP renewal aggressiveness setting with no luck. I've tried latest Asus firmware, Merlin firmware, and now I'm on John's fork.

Any ideas for other things to try? It's a small ISP so there's a small chance that if there's a known common incompatibility that the ISP could configure away then they might do that, but it'd obviously be much easier if there's something I can tweak on the client.

 

[ColinTaylor]

@msilenus Unfortunately you seem to have tried the usual suggestions, DHCP aggressiveness and other firmwares. There really isn't anything else to tweak in the GUI. Look in the syslog and try and find any errors that coincide with the problem. We're assuming it's linked to a DHCP renewal but it might not be.

You say you don't have a modem but the router must be connected to something? Try changing/reseating the Ethernet cable.

If the syslog does show it to be a DHCP problem we might be able to apply some manual overrides to the router's DHCP client. Or perhaps make a note of your current WAN IP settings and set them up as static entries on the WAN interface.

 

[kfp]

This is with a pretty basic setup. We're getting a public DHCP address down from them

Is it really a public address? I ask this because I know at least one fibre ISP in the Toronto area that forces their customers to use the routing functionality from their GPON modems, with no ways to put it into bridge mode (by the customers).

Since you said “no modem or DSL”, I’m assuming you’re saying that you didn’t get a box that ‘converts’ a fibre line to ethernet? Do you plug the WAN port of your Asus to an ethernet port on the wall?

 

[SomeWhoCallMeTim]

I saw an update to the VPNFilter router malware story that seemed to indicate that a number of ASUS routers are now considered to be vulnerable after all. Other than pushing in the reset button for five seconds, and reloading current firmware does anyone know if there is anything else we need to do to protect ourselves?

 

[ColinTaylor]

I saw an update to the VPNFilter router malware story that seemed to indicate that a number of ASUS routers are now considered to be vulnerable after all. Other than pushing in the reset button for five seconds, and reloading current firmware does anyone know if there is anything else we need to do to protect ourselves?

There's a thread about it here.

 

[SomeWhoCallMeTim]

Thanks!

There's a thread about it here.

 

[msilenus]

Thanks! To answer the questions I see quickly: I'm pretty sure the address is public because it's in the 157. prefix. I plug the router into an ethernet cable in the wall, which goes to a utility closet outside where the ISP has installed a Cisco Catalyst 2960G to serve the building. Don't know anything about the configuration.

I've dug around in the syslogs I found under jffs. What jumps out at me is that syslog.log starts with a ton of lines from Dec 31, then jumps forward in time to today, right around the time of the interruption. There's an NTP call that resolves right around the time when it transitions:

Dec 31 15:00:13 syslogd started: BusyBox v1.25.1
Dec 31 15:00:13 kernel: klogd started: BusyBox v1.25.1 (2018-04-02 10:06:06 MST)
Dec 31 15:00:13 kernel: start_kernel
...
Dec 31 15:00:16 WAN_Connection: ISP's DHCP did not function properly.
...
Dec 31 15:02:15 wan6: wan6 interface eth0 is down
Dec 31 15:02:15 stop_wan(): perform DHCP release
...
Dec 31 15:02:32 WAN_Connection: WAN was restored.
Dec 31 15:02:32 rc_service: wanduck 318:notify_rc start_firewall
Dec 31 15:02:32 rc_service: waiting "start_ntpc" via udhcpc ...
Dec 31 15:02:32 ntp: start NTP update
Jun 6 16:46:14 rc_service: ntp 587:notify_rc restart_upnp
Jun 6 16:46:14 miniupnpd[584]: shutting down MiniUPnPd
Jun 6 16:46:14 rc_service: ntp 587:notify_rc restart_diskmon
Jun 6 16:46:14 disk_monitor: be idle
Jun 6 16:46:14 ntp: NTP update successful after 1 attempt(s)​

I'm not fluent in *nix syslogs, but this smells to me like a reboot/recovery, presumably after a crash. Unfortunately, I don't see any indication as to what caused it to hork. There's a syslog-1.log file, which I'm guessing is the previous log epoch, but the last entry is four days ago:

Jun 2 01:45:13 dnsmasq-dhcp[344]: DHCPACK(br0) 192.168.1.119 ...
​

I see a smattering of "WAN_Connection: ISP's DHCP did not function properly." in both logs.

Is any of that helpful? In case it isn't, I'm increasing the syslog/router message verbosity in the to Debug/Info, respectively. I can set both to debug if that's likely helpful. I turned off NTP logs at the same time to try to attenuate the verbosity, but I can undo that if that would be helpful.

 

[kfp]

Thanks! I'm pretty sure the address is public because it's in the 157. prefix. I plug the router into an ethernet cable in the wall, which goes to a utility closet outside where the ISP has installed a Cisco Catalyst 2960G to serve the building. Don't know anything about the configuration.

I’m at a loss then if you’re getting a public IP. The Cisco is just a switch, the modem(+ maybe router) is somewhere else.

 

[msilenus]

I got another repro with the added log vebosity:

Jun 7 10:17:16 (none) daemon.warn openvpn[630]: Could not determine IPv4/IPv6 protocol. Using AF_INET
...
Jun 7 10:17:58 (none) cron.err crond[398]: time disparity of 3909196 minutes detected
...
Jun 7 10:24:44 (none) daemon.warn dnsmasq-dhcp[395]: Ignoring domain XXREDACTEDXX for DHCP host name XXREDACTEDXX
...
Jun 7 14:16:45 (none) daemon.notice openvpn[630]: XXREDACTEDXX :56442 TLS: Initial packet from [AF_INET]XXREDACTEDXX :56442, sid=12121212 12121212
Jun 7 14:17:45 (none) daemon.err openvpn[630]: XXREDACTEDXX :56442 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Jun 7 14:17:45 (none) daemon.err openvpn[630]: XXREDACTEDXX :56442 TLS Error: TLS handshake failed
Jun 7 14:17:45 (none) daemon.notice openvpn[630]: XXREDACTEDXX :56442 SIGUSR1[soft,tls-error] received, client-instance restarting
Dec 31 16:00:12 (none) syslog.info syslogd started: BusyBox v1.25.1
Dec 31 16:00:12 (none) user.notice kernel: klogd started: BusyBox v1.25.1 (2018-04-02 10:06:06 MST)
Dec 31 16:00:12 (none) user.warn kernel: start_kernel
​

Looks like it might have something to do with VPN activity? My wife uses VPN to connect to her work. Her IT department would be in control of all of that on the client. It's a large company and I'm sure you know how that goes.

Looking earlier in the syslogs, I see that TLS negotiation failure before the previous repro as well, but it got hidden in DHCP server spam so I didn't catch it last time.

If this is a VPN-related crash, then that opens up a lot of config space, but I don't think I've ever mucked with this stuff. Here's what I see in the UI:

VPN - Status:
OpenVPN Server 1 is "Running" with a current last update. All of the others are stopped.

VPN Server:
Enable VPN Server: Off

VPN Details:
VPN Server Mode: PPTP
Broadcast Support: Disable
Authentication: Auto
MPEE Encryption: all checked
Connect to DNS/WINS: both Yes
MRU/MTU: Both 1450
Client IP address: 192.168.10.2-.10.11 (Rest of network is in 192.168.1.X)

PPTP/L2TP Client:
No data in table

OpenVPN Client:
Client1
Service state: Off
Start with WAN: No
Interface/PRotocol: TUN/UDP
Service Address/Port: Blank/1194
Firewall: Auto
Auth: TLS
UN/PW Auth: No
TLS controlc hannel security: disabled
Create NAT on tunnel: Yes
Pol interval: 0
Accept DNS config: Disabled
Cipher Negotiation: Enable w/ fallback
Negotiable ciphers: Four flavors of AES
Legacy/fallback cipher: default
Auth digest: Default
Compression: LZ0 Adaptive
TLS renegotiate/Connection REtry: -1/30
Verify server cert: No
Redirect Internet traffic: No​

Phew. Sorry for the massive dump --I don't know much about VPN, so I don't have a good sense of what matters up there. I'm a little puzzled that in places it looks like this is disabled, but in the syslog there's clearly daemon activity that's failing. Any suggestions to try?

Thanks again for the help. (And let me know if this isn't appropriate for this thread and I should buzz off.!)

 

[ColinTaylor]

@msilenus

1. What's a "repro"?

2. The router has no battery-backed clock so it will go back to the default date and time (Dec 31) when it is (re)booted until it can sync with NTP.

3. When looking at the VPN Server/Detail pages you have to change the "Server mode" selection to see the appropriate information.

4. After the VPN log entry at Jun 7 14:17:45 what was the actual time when it next re-synced with NTP. Knowing that time and subtracting the time it took to boot to that point gives you the precise time the router crashed.

5. Knowing the answer to 4. we can compare it to the log entry at Jun 7 14:17:45 and deduce whether the crash happened at that moment or some time later.

EDIT:
6. You say your wife uses a VPN to connect to work. But presumably that is a VPN client on her computer. The log entries and the VPN information you posted show that you have a VPN server running on the router. Is this deliberate? Have you setup remote access to your router? If you don't need it you can turn it off. (VPN > VPN Server > Select "Server mode=OpenVPN" and "Server instance=Server 1". Toggle the "Enable VPN Server" button)

 

[msilenus]

1. Repro == reproduction; esp. when you're excited about a bug showing up again because you want to squash it.
2. Thanks for confirming. That's a big part of why I thought those sections demarked unscheduled reboots/crashes.
3. I missed that. Thanks!
4-5. Gah. I lost those logs to a JFFS reformat + reset to factory settings. Some more googling turned up a thread where someone advised that when your VPN server is running even though you think it ought to be off. I hadn't seen your (2) above, yet, so I figured that was describing my situation and gave it a shot. Should have backed up the logs first, but didn't.
6. Not deliberate. The resets seem to have corrected that bit, as I can't find any hint now that the VPN server is trying to run. UI, syslog, ps all show no signs of it.

I am still seeing the complaints about the ISP's DHCP behavior, but the context around those suggests they might be self-correcting; so I'm hopeful that this will improve the stability. In hindsight, I probably should have done a factory reset earlier in the troubleshooting process. Hopes notwithstanding, I've kept the syslog verbosity high, and will try the timestamp analysis you're suggesting if I do get another repro.

Thanks again for the help!

 

[ColinTaylor]

@msilenus I have a vague recollection from way back (so I could be wrong) that the setting used to store whether that VPN server was on or off was used the opposite way around in Asus vs. Merlin/John firmware. So this meant that when people migrated from Asus' firmware their previously off VPN server turned itself on. Resetting to factory defaults fixed this (and other things).

If you have the problem again try and save the complete log (remove your WAN IP address) to somewhere like pastebin so we can see the whole thing in context.

 

[kfp]

I am still seeing the complaints about the ISP's DHCP behavior, but the context around those suggests they might be self-correcting; so I'm hopeful that this will improve the stability.

Since you said the ISP is new, it’s more likely that the ISP screwed something up, especially if you get another ‘repro’.

Another avenue of investigation would be to ask your neighbours, if ISP screwed up it can’t be just you that’s having this problem.

 

[punchsuckr]

It's been long since I checked out this thread... but read through like 40 pages to catch up with what's happening with this fork I like so much. I had initially decided to upgrade to an AC router but decided to hold off for a bit.

I had been away from home and my N66U was on 23e4, up continuously for 280 odd days (screenshot attached), that's some reliability!
However the recent vpnfilter hacks had me really wary and updating the firmware was the first thing I did upon getting back.

Realised there are now 2 separate update paths, decided to test out the E release but first updated to 32L4 and then switched to 32E4 and it has been working really well for the past half hour without a reset.

Pleasantly surprised to see the range has not suffered for the 5Ghz like it used to, probably because of the updated db regulation limits. Working excellently as always.

Thanks again @john9527 for your work and help in squeezing all useful life out of this excellent hardware of its era. I have moved all heavy stuff like the vpn server off it anyways.

 

[OMNI619]

Were you downloaded John for can you please post the link thanks

Sent from my SAMSUNG-SM-G920AZ using Tapatalk

 

[ColinTaylor]

Were you downloaded John for can you please post the link thanks

Same answer as when you asked this question before, see post #1.

 

[OMNI619]

Same answer as when you asked this question before, see post #1.

Thanks for your answers I didn't mean to interrupt your valuable time

Sent from my SAMSUNG-SM-G920AZ using Tapatalk

 

[IsaacFL]

I am now using my RT-1900P (same as RT-AC68U) as a Wi-Fi AP only.

I am using it as the AP for my "trusted" Wi-Fi devices which are all Apple (iPhones, iPads, and Apple TVs) with heavy Ipv6 use too.
​

I am currently using Merlin 384.5, but since I no longer use any of the advanced features, I was wondering if this build would be a better fit? Or maybe the "Official" Asus build? I don't have another Asus, so AiMesh is not a factor.

I have a pfSense router upstream that is providing the dedicated subnet and firewall protection.

Edit: The reason I am asking, is it seems like it is non-trivial to switch from 384.5 so want to know if it would be advantage.

 

[ColinTaylor]

@IsaacFL If you're only using it as an access point for your wireless devices I doubt you'd find any difference between any of the firmwares.