But my router just reboots spontaneously and often. It can run for an hour without problem, then the whole system reboot. Most of the times the router reboots every 10-15 minutes, sometimes with 5 minutes interval. Here is my logread: https://pastebin.com/7BMsZfvr
Anyone know what to do and try. I have spent hours to figure it out
I'd say your best bet would probably be a snapshot of master before the ath10-ct switch @slh has that specific device so maybe he can fill in some more.
I can't reproduce that behaviour, but I'm using current master snapshots and not 18.06.x (although that shouldn't make much of a difference here).
One thing to test, in case you have enabled flow-offloading, it might be interesting to test with it being disabled (it has been implicated in similar issues in the past, not just for ipq806x).
You can keep an eye on cat /sys/class/thermal/thermal_zone*/temp (ipq806x, like any highend ARM routers, tend to run hot) or you could set up remote syslogging in the hope to catch why it fails (might help, if not you may need a serial console).
Or you can try more recent master snapshots (ath10k-ct isn't working that well for QCA9984 so far though).
I build/ update to current master every week or two, currently with the mac80211/ backports updates reverted (due to problems with ath10k and ath10k-ct in WDS mode).
So i got time to go back and look at the problem again. My router still reboots. I have noticed that the problem occur everytime my Arch laptop have been connected to the router for some minutes. I dont have downloads running or something like that, that could generate a session overload of the router.
I activated syslog and directed it to a remote syslog server. Here are the log from a crash: https://pastebin.com/a9E5NifT
I just looked at my laptop. Seems like MTU is setup correctly, but I must admit that your guess is likely true.
$ ip link show | grep mtu
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
4: wlp61s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
7: wwp0s20f0u6: <BROADCAST,MULTICAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
Its just wierd that this suddenly happens after i upgrade to 18.06.1 if it was the switch in the router that didnt support jumbo frames. I have run with OpenWRT for a year with older versions without the reboots happening.
It could also be an Arch update on my laptop that is causing it, but I cant find anything thats related to jumbo frames. :-/
I also just experienced a crash after 12 days uptime on my NBG6817 (OpenWRT 18.06.1). Unfortunately, I couldn't read any useful logs, as they are setup to be in /tmp by default and therefore not available on next boot, but I'll setup a syslog server for the next time.
I want to add, that I experienced more frequent instability issues in the past, when I was using LEDE 17.x. Also included WiFi stability issue, but also random reboots. I reverted to stock Zyxel firmware, which ran fine with months of uptime and absolutely no issues. So I'd opt out any hardware issues.
Other than stock, I have Software Flow Offload enabled, SQM, UPnP and DDNS installed. This device is facing WAN and doing PPPoE. Temps are somewhere around 60 - 70°C.
I'll report back, when I have something in the syslogs (may take a while).
