1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice

Welcome To SNBForums

SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.

If you'd like to post a question, simply register and have at it!

While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!

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

Discussion in 'Asuswrt-Merlin' started by john9527, Aug 14, 2014.

  1. kfp

    kfp Senior Member

    Joined:
    Jun 26, 2014
    Messages:
    271
    Just disappearing from Merlin supported models I guess, but alive and well in other brands eg. entire EdgeRouter line. Plus, the recently released Asus Blue Cave is also MIPS.
     
  2. Please support SNBForums! Just click on this link before you buy something from Amazon and we'll get a small commission on anything you buy. Thanks!
  3. ColinTaylor

    ColinTaylor Part of the Furniture

    Joined:
    Mar 31, 2014
    Messages:
    5,516
    Location:
    UK
    @john9527 While looking at a problem with DNSFilter in Merlin's firmware here we seem to have stumbled across the same problem in your firmware.

    Even though your firmware does it slightly differently the principle is much the same. So when DNSFilter's Global Filter Mode is set to anything other than "No filtering" the last rule in the IPv6 mangle/DNSFILTER chain should be DROP, but it's missing. So it needs the following to make the client retry using IPv4:

    ip6tables -t mangle -A DNSFILTER -j DROP
     
  4. Dfects

    Dfects Occasional Visitor

    Joined:
    Feb 25, 2015
    Messages:
    11
    I have an original AC66u I think, not sure on the exact revision as I can't see any sticker indicating which it is. In the web interface, I can only see 1 core though. I noticed in the upgrade matrix that the AC66U_B1 is supported, but guessing that means my older one isn't? Unless the AC66 entry without the U is where I should be looking? Just want to confirm before I try restoring.

    Looking to migrate away from merlin now its no longer supported :)
     
  5. ColinTaylor

    ColinTaylor Part of the Furniture

    Joined:
    Mar 31, 2014
    Messages:
    5,516
    Location:
    UK
    @Dfects Your router is supported :). If it's got a single core then it's an original RT-AC66U with a MIPS processor (like the RT-N66U). The AC66U_B1 is a re-badged AC68U with a dual core ARM processor. AC66 = RT-AC66U
     
    Dfects likes this.
  6. Dfects

    Dfects Occasional Visitor

    Joined:
    Feb 25, 2015
    Messages:
    11
    Thank you very much :) Just backed up my settings with John's other awesome tool so will give it a go soon.
     
  7. msilenus

    msilenus Occasional Visitor

    Joined:
    Jun 6, 2018
    Messages:
    10
    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.
     
  8. ColinTaylor

    ColinTaylor Part of the Furniture

    Joined:
    Mar 31, 2014
    Messages:
    5,516
    Location:
    UK
    @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.
     
    popxunga likes this.
  9. kfp

    kfp Senior Member

    Joined:
    Jun 26, 2014
    Messages:
    271
    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?
     
  10. SomeWhoCallMeTim

    SomeWhoCallMeTim Occasional Visitor

    Joined:
    Jul 15, 2013
    Messages:
    24
    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?
     
  11. ColinTaylor

    ColinTaylor Part of the Furniture

    Joined:
    Mar 31, 2014
    Messages:
    5,516
    Location:
    UK
    There's a thread about it here.
     
    oso2276 and SomeWhoCallMeTim like this.
  12. SomeWhoCallMeTim

    SomeWhoCallMeTim Occasional Visitor

    Joined:
    Jul 15, 2013
    Messages:
    24
    Thanks!

     
  13. msilenus

    msilenus Occasional Visitor

    Joined:
    Jun 6, 2018
    Messages:
    10
    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.
     
  14. kfp

    kfp Senior Member

    Joined:
    Jun 26, 2014
    Messages:
    271
    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.
     
  15. msilenus

    msilenus Occasional Visitor

    Joined:
    Jun 6, 2018
    Messages:
    10
    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.!:D)
     
  16. ColinTaylor

    ColinTaylor Part of the Furniture

    Joined:
    Mar 31, 2014
    Messages:
    5,516
    Location:
    UK
    @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)
     
    Last edited: Jun 7, 2018
  17. msilenus

    msilenus Occasional Visitor

    Joined:
    Jun 6, 2018
    Messages:
    10
    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!
     
  18. ColinTaylor

    ColinTaylor Part of the Furniture

    Joined:
    Mar 31, 2014
    Messages:
    5,516
    Location:
    UK
    @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.
     
  19. kfp

    kfp Senior Member

    Joined:
    Jun 26, 2014
    Messages:
    271
    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.
     
  20. punchsuckr

    punchsuckr Regular Contributor

    Joined:
    May 17, 2014
    Messages:
    196
    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.
     

    Attached Files:

    • n66.PNG
      n66.PNG
      File size:
      14.2 KB
      Views:
      67
    Waylo and OMNI619 like this.
  21. OMNI619

    OMNI619 Occasional Visitor

    Joined:
    Feb 3, 2018
    Messages:
    39
    Were you downloaded John for can you please post the link thanks

    Sent from my SAMSUNG-SM-G920AZ using Tapatalk
     
Please support SNBForums! Just click on this link before you buy something from Amazon and we'll get a small commission on anything you buy. Thanks!