Sadly that did not help. The android app doesn't crash the router anymore when MTU is set to 9000. But the mac app still does.
I ran Wireshark to see if I could spot any difference between the mac app and running the test in Firefox. The main difference was that the mac app opened a UDP port and started to send packages with the length of 16byte.
I'm uncertain what else I could do. I tried to change the TCP congestion algorithm from cubic to reno, but no success. I furthermore tried to get any info from dmesg and the system.log but there is no output at all when the device decides to restart.
Maybe I just got unlucky and my device has a hardware fault?
could be, you could also try setting up remote logging, so you might catch some kernel output that you normally do not see as the network goes down. A hardware fault is also possible, but then if your MTU 1472 trick helps I believe software should at least be involved somewhat.
The 1472 did not help, got the crashes again.... I guess I was just lucky.... Fiddling around seems to please the android app somehow. And in some instances the mac app. But nothing I could really pinpoint.
I currently write the log files to /root/. I also installed the full fledged dmesg and started it like this:
But nothing. The last lines in the log file are always:
[ 140.964711] enter showtime
[ 141.890179] pppoe-wan: renamed from ppp0
How could external logging help here? Since device looses all network connection, it would stop writing output to another computer the same way it stops writing to the file. The only way would be the serial port I guess, but I don't have the equipment to do this.
BTW I have xRX200 rev 1.2 what is your revision. @Plonk34 what is yours?
Since the boxes are not that expensive, I ordered another one from eBay. The one I'm using right now was pretty beaten up. Don't know what the previous owner did with the box....
Oh, I do not have this box, I use a bt homehub5a as bridged modem (running openwrt) and an old wndr3700v2 as router (running a relative recent openwrt master build, it is this secondary router that runs the PPPoE client).
[quote="stonerl, post:25, topic:34258"]
But nothing. The last lines in the log file are always:
[ 140.964711] enter showtime
[ 141.890179] pppoe-wan: renamed from ppp0
Aha, enter showtime and the low time (140 seconds after boot) indicates that nothing intersting hit dmesg, so maybe you need to look at logread and how to direct that onto disk or to a server: https://openwrt.org/docs/guide-user/base-system/log.essentials
Did external logging with ncat, but nothing. No output when the device restarts.
But I observed something new. I connected a TP-Link TL-WR841N with OpenWrt 18.06.02 via Ethernet to the o2 Box and used it as a Wi-Fi AP. And surprisingly no reboots, when I'm connected to the TP-Link AP Wi-Fi.
As soon as I connect to the o2 Box' Wi-Fi or Ethernet-Port. The box reboots when I'm running the speedtest apps.
For Christ's sake... This box has completely erratic behaviour. Everything in the following block-quote were my observations. And they were true until the moment I intended to post it. Tested this several times and now... all for nothing. This f***ing box must be broken.
Another find. If I do anything MTU related on the o2 Box, it crashes. For example when I set the MTU for lan to 9000 but leaf it 1500 for the wan interface, it crashes regardless of the TP-Link settings.
When I leave the lan mtu settings at 1500 but enable sqm for the wan interface it crashes, since sqn fiddles with the MTU. The same happens when I only set wan to 1472 or 1492 but leave the lan untouched.
So it seems the MTU on the o2 Box must not be different for the wan and lan interface. But also the TP-Link AP must not have an MTU of 1500. Every other value I tested (9000, 1972) is fine.
The culprit is that I need to connect via the TP-Link that has an MTU different of 1500. Every direct connection to the o2 Box regardless of LAN or Wi-Fi crashes the box when I run the app.
I've experienced that issue on a different device for over 7 years. I have that erratic rebooting on https://openwrt.org/toh/zinwell/zw4400 (I don't know why this device isn't in the Table of Hardware, too.)
OpenWrt versions 14 and 15 were horrible. LEDE Rebboot (v17) was a great improvement - it rarely happens now. I tracked this improvement to the addition of NAPI to the OpenWrt kernels.
I hope this is helpful and relevant to your issue.
Well I'm waiting for the new box to arrive, and see if it behaves different.
If I remember correctly, I had Fritz.box a couple of years ago, which had a similar issue. Spontaneous reboots, especially under heavy load. Several firmware updates couldn't fix this issue. Finally, I got it replaced by the manufacturer and the problem disappeared.
AFAIK, it had a similar chipset. So cross fingers...