I have an annoying bug with my Linksys WRT1900AC loaded with LEDE Reboot 17.01.4 r3560-79f57e422d. Everytime the WAN connection drops my router locks up; the router doesn't respond to pings, the Wi-Fi LED's on the front of the physical router freeze (don't flicker) and the LuCI interface is unaccessible.
I previsouly made a forum post about this and I was recommended to use the Travelmate package and make a new thread to get some help setting it up.
Is the the package to use to solve the problem mentioned above? If so could someone please go through how to set it up in the LuCI interface?
In the old thread there was no travelmate recommendation regarding your problem (wired WAN). Travelmate is only a Wireless WAN-Manager (WWAN), this package is mainly intended for travel router.
Sorry, I have no idea. Maybe you should reset your config and start with a fresh install, personally I've never seen such behaviour. And please change the misleading title of this thread ... thanks.
This is not expected behavior, there is no reason why a router should lock when it loses WAN connection. Please, post your "/etc/config/network" file here. Also, it would be interesting to open a SSH session, execute "logread -f", and then cut the WAN connection; perhaps we can get some log message about why is this happening.
Last night I've managed to note down how to replicate my problem. I simply unplugged the WAN cable from my fibre-optic modem and then disconnected from the 5GHz AP and then re-connected. I then went to my router's LuCI interface page and was presented with this message.
Looks like your router gets out of RAM when the WAN goes down... that's weird, I cannot imagine why.
Could you please try the test that I suggested in my last post?
and pulled out the WAN cable out. Is there a way I can hide maybe even filter out my personal information as I would like to hide but there is so much of it?
To give you a timescale of what happened to the physical router, pretty much after pulling the cable out the LuCI GUI was slow and the webpages were taking a long time to load. After about ten minutes the Wi-Fi AP dropped out (the lights on the front of the unit confirmed this).
Also is there a way to generate this log to a file instead or is that not recommended?
I opened Command Prompt on Windows and ran a constant ping to the router (192.168.1.1) and never dropped, and then I ran the following command in PuTTY:-
logread -f >> /mylogread.txt
and I unplugged the cable form the WAN port left it it for five minutes and then disconnected from the AP on my Android phone, to which it then failed to re-connect. Also the LuCI GUI became inaccessible showing this message:-
After about 6/7 minutes I decided to reconnect the CAT6a cable and see if the WAN re-establish. Weirdly enough the LuCI started working again but it was ridiculously slow. However, at no surprise the WAN didn't reconnect even after starting it through LuCI > Network > Interfaces.
There are lots of DNS queries for "localhost" from your own router... that looks odd to me. You seem to be running a script or a program that is constantly launching those queries.
WAN connection is lost at about 11:49:29, I guess that is when you unplug the ethernet wire.
Device then keeps trying to re-establish the WAN connection.
At 11:51:28, you open a new connection from your computer.
At 11:54:58, the disaster starts: uhttpd fails (Segmentation Fault) and starts reporting "Out of memory".
At 11:58:24, squid also fails because there is not enough memory.
Thus, my two cents are:
Your device is not crashing, just getting out of RAM.
With the popularization of HTTPS, web proxies such as SQUID become useless.
Perhaps it is not related to the issue here, but I would investigate about the DNS requests.
I've had a quick look into the DNS. It could possibly be the DNSCrypt and/or Dynamic DNS packages I have installed. I'll try disabling them, re-test and report back.
As a side note in relation to RAM, is there a way to monitor or log RAM usage?
Hey Guys I'm back and unfortunately with bad news...
I ended up re-installing LEDE Reboot 17.01.4, updated all my packages via SSH using PuTTY and installed the following packages:
luci-ssl
luci-app-upnp
luci-app-sqm
luci-app-ddns
ca-bundle
ddns-scripts
hostapd-common
hostapd-utils
wpad
qm-scripts
I then disabled the DDNS scripts package thinking this was the cause of the DNS request via the menu 'System > Startup' and clicked on the 'Enabled' button which turned into to 'Disabled'. Finally I rebooted my router and left if for a few minutes before then unplugging the WAN cable, sitting and waiting patiently for LuCI to start behaving slow and locking up after about 15 minutes or so. On the overview page I took some screenshots of the RAM usage available when it slowly drifted down to 9% compared to the 78% I have when everything is all up and working. As well slow loading webpages within LuCI I would also get an out of memory message in plain text. What's weird is when I could get to the 'Status > Processes' page and look under the RAM usage column there wasn't anything over 1%. I was expecting something to be hogging the RAM resources...
How are you updating the packages? It is not recommended to update core packages because it can introduce issues related to kernel versions and other dependencies.
My recommendation would be to re-flash with 17.01.4 and only setup the basics (do not update any existing packages, do not install any new ones). Test at this point.
Then, one at a time, install packages (again, do not update core packages; installing new packages is fine, though)... do it one at a time (aside from direct dependencies, of course) and test between each package installation. At some point, the problem will show up again and you should have a better idea of what might be causing the issue (base install, or a specific package, etc.). The best way to troubleshoot is to keep it simple and isolate variables.
When I updated the packages I did it through SSH using OPKG Packet Manager commands. If you recommend not updating the packages and only flashing the firmware and installing the fresh packages I do want, I'll give that a go and let you know.
Yes, please try what I recommended. Start simple. Does the problem manifest when you have a fresh install (with no extra packages installed, no upgrades). If so, you are either dealing with a bug or a configuration issue with the base firmware. Installing packages one-by-one after verifying that the base install is okay (assuming that is the case) will help narrow down the packages responsible for the issue.
Read this thread (and feel free to search for other threads related) for information about why it is not recommended to update the core packages. If you are really intent on updating those core packages, it would probably be best to build your own firmware from the source or to use a snapshot.