srw985 wrote: ↑Fri Nov 16, 2018 10:03 am
It's tricky, as it can take 5 min+ to load a page from the WebGUI once the issue has occurred. I've just done a reboot before seeing this post, and have attached the current full log here https://pastebin.com/pWYWN57G
I'll check back in a couple hours and try to retrieve a new log once the issue has occurred. Any way I can I get the logs via SSH or something?
Thats great, I checked the latest logs, and nothing there worth mentioning, (as you have just rebooted the device I assume) If the web gui is unreachable you will probably have the same issue trying to SSH into the device (If i remember correctly you can use the command 'syslog dump' if you are able to SSH/telnet in)
Or setup a syslog server (attached guide)
You do not have the required permissions to view the files attached to this post.
Thanks. Have the syslog server set up on Windows for now and looking into getting one running on my unRAID server.
Router is yet to crash since reboot.
Nov 16 11:58:29 kern warn kernel: br0: received packet on wl0 with own address as source address
Should these lines concern me or is this normal behaviour? Not entirely sure what it means, worried me the other day that another device was trying to use the router IP address but no longer think its that?
srw985 wrote: ↑Fri Nov 16, 2018 12:13 pm
Thanks. Have the syslog server set up on Windows for now and looking into getting one running on my unRAID server.
Router is yet to crash since reboot.
Nov 16 11:58:29 kern warn kernel: br0: received packet on wl0 with own address as source address
Should these lines concern me or is this normal behaviour? Not entirely sure what it means, worried me the other day that another device was trying to use the router IP address but no longer think its that?
I have seen this log on the older 7800 series, it was nothing to worry about at the time, but a updated log once the issue has occurred, should shed more light on the situation .
WebGUI is now unresponsive again. Latest log here, can't upload .txt as attachment it seems https://pastebin.com/MWX6BZQb
This line seems to match first failed attempt to load the webgui
11-16-2018 13:28:30 Daemon.Info 192.168.0.1 Nov 16 13:28:00 syslog: MDM lock is held by httpd (pid=31141) for 4294967 seconds
srw985 wrote: ↑Fri Nov 16, 2018 1:30 pm
WebGUI is now unresponsive again. Latest log here, can't upload .txt as attachment it seems https://pastebin.com/MWX6BZQb
This line seems to match first failed attempt to load the webgui
11-16-2018 13:28:30 Daemon.Info 192.168.0.1 Nov 16 13:28:00 syslog: MDM lock is held by httpd (pid=31141) for 4294967 seconds
Ok this seems to be a different issue, I have updated our engineers, at least we are not seeing the 'mroute: pending queue full, dropping entries"' anymore, but that might start when you start streaming
I'm running a Plex server with remote access, sometimes 2-3 outward streams at a time. In addition to an inbound netflix/iplayer stream or two. Should this be problematic?
You're right about the MDM lock entries being a different issue, as the WebGUI is now fully responsive again and not throwing any errors to the log when I try to access it. When the main issue occurs, the WebGUI doesn't sort itself out until a restart.
srw985 wrote: ↑Fri Nov 16, 2018 1:51 pm
I'm running a Plex server with remote access, sometimes 2-3 outward streams at a time. In addition to an inbound netflix/iplayer stream or two. Should this be problematic?
You're right about the MDM lock entries being a different issue, as the WebGUI is now fully responsive again and not throwing any errors to the log when I try to access it. When the main issue occurs, the WebGUI doesn't sort itself out until a restart.
Ok, I don't think the streaming should be a issue, I am hoping the newer firmware resolved your streaming issues.
Lets wait for the engineers to reply and take it from there