[SOLVED]O2 Box 6432: speedtest crashes router/modem

Installing and Using OpenWrt Network and Wireless Configuration
1

I have a weird behaviour with my Arcadyan VGV7510KW22 (o2 Box 6431) running 18.06.02.

When starting a speedtest from speedtest[.]net, everything is fine. As soon as I use the Speedtest app for Android, the modem led turns off, connection is lost and the box reboots.

This also happens when using the Speedtest app on my Mac.

I tried 3 different firmwares, but always the same behaviour. When using the ADSL-Firmware that allows max speeds of 15Mbit/1.5Mbit (the one that comes with openWrt), these reboots don't happen.

Has anyone with this Box the same issue?

Best
Toni

3

Turns out I was close. I need to set the MTU to 1472 for both LAN and PPPoE and I need to disable MSS clamping in the firewall settings

4

Thanks that you write here and give a solution too

Hmm why is
option mtu '1492'
needed ?

Anyway i try it with and without the mtu settings, with your android app but not with aple-app and HTML-speedtests, without problems
(Modem firmware are from Fritzbox 7360 6.30)
So my Router does not reboot but i have no fast Wifi devices i thing my smartphone have only 1 Stream and the 40Mhz channel size does not work.
So i connected with 72Mbit/s only (speedtest result 20-35Mbit/s)
How fast are you connected ?

5

To take in account the overhead added by PPP. (under design considerations)
For calculating your optimal MTU check this.
On LAN you don't need to mess with MTU.

6

OK but i was thinging it was done into /etc/config/firewall

config zone
	option name 'wan'
	option masq '1'
	option mtu_fix '1'
	...
7

In case of this device it is necessary. If Lan and Wan don't have the same MTU the box crashes.

8

You need to remove the last line or set it to 0.

I had to set the MTU for both interfaces to 1972 to avoid crashes. Just make the ping test as @trendy said and set it to this value. Don't add the 28 byte header they recommend.

That said if you don't experience crashes you may not need to changes these values.

What I also had to do was to disable the WiFi and use another device just for my WiFi. The WiFi driver was constantly crashing on high load and took down the entire system.

9

Here is an excerpt of my config files:

/etc/config/network

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0.1'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option mtu '1472'

config interface 'wan'
	option proto 'pppoe'
	option ipv6 '1'
	option ifname 'dsl0.7'
	option username 'xxxx@t-online.de'
	option password 'xxxx'
	option mtu '1472'
	option peerdns '0'
	option dns '1.1.1.1 1.0.0.1'

/etc/config/firewall

config zone
	option name 'wan'
	list network 'wan'
	list network 'wan6'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'

Regarding MTU. MTU means Maximum Transfer Unit. It is the maximum size a package is allowed to have before it gets fragmented. In thsi case it means that the maximum is 1472 bytes. If a package of 1500 bytes is sent, it needs to be split in a package of 1472 bytes and another one with 28 bytes. This is done by the sending side. Here it seems that the router has problems with fragmented packages.

Just a guess, though.

10

No with IPv4 it is the device that can not pass the packet on due to size, so it is the router that needs to fragment packets. The odd thing is that typically PPPoE is configured to do MSS clamping on uplink (and your ISP is responsible for the downlink).

This seems wrong to me,this way the largest ethernet payload is 1492 and the largest PPPoE-payload should be 1492-8 = 1484, are you sure that you really require to set MTU on dsl0, because if only pppoe-wan feeds dsl0, it will never see an MTU larger than 1472+8 = 1480 so the 1492 are seemingly superflous and should never trigger...

11

I removed the post with 1492. That was all wrong. The wan_dev device is not needed here. The values in my last post are the correct one. With them I haven't had a single random reboot when running the speedtest.

I wonder if I might have a faulty device, though.

12

I know this might be annoying, but if you try to increase the MTU value again, do you see the crashes reappear again at MTU 1473?

So one theory about speedtest/load related crashes is that potentially the PPPoE LCP(link control protocol) keep-alive packets might be queued up behind the data packets for long enough to trigger a PPPoE disconnect. One thing to test would be to use sqm-scripts on pppoe-wan (if you do not actually see pppoe-wan as a device you might have bigger issues) with the shaper set appropriately for your link (I am happy to help out there), but at say 80% of the syncrate). That way there should always be enough bandwidth for the LCP packets to pass...

13

Will try this tomorrow. If I do this now my housemates are gone lynch me. :laughing:

14

The problem isn't solved. The app still crashes the box. I installed sqm but it doesn't help either.

config queue 'eth1'
	option qdisc_advanced '0'
	option upload '35000'
	option debug_logging '0'
	option verbosity '5'
	option qdisc 'cake'
	option script 'piece_of_cake.qos'
	option linklayer 'ethernet'
	option overhead '34'
	option download '75000'
	option interface 'pppoe-wan'
	option enabled '1'
15

Ah, okay, but that is without "mtu_fix '1'" in /etc/config/firewall, correct? Anyway, thanks for testing, it does not look like this is the issue, as it would not explain your issue of reboots of the router...

16

SQM was with mtu_fix '1' in /etc/config/firewall. I also removed mtu '1472' from /etc/config/network.

17

Thanks for the information, but I had not fully appreciated what described as

That does not look like something SQM might help with. If you would not use a Telekom link I would be suspicious of your ISP sending Baby-Jumboframes on the DSL link (to allow MTU1500 to the internet, and hide the effect of the PPPoE header) and either the dsl modem chip or the switch being allergic to Baby jumbo frames... Can you enable support for jumbo frames in the switch?

18

Can you tell me where?

19

Like this?

config interface 'lan'
        option type 'bridge'
        option ifname 'eth0.1'
        option proto 'static'
        option ipaddr '192.168.1.254'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option mtu '9000'
20

Setting Jumbo Frames seems to have done the trick. I will repeat the speedtests later this day.

21

There were a few other threads which showed issues with unsolicited reboots upon reception of unexpected jumbo-frames, so I just voiced a wild guess. If this fixes the issue, great, but it leaves the question why both the android and the macosx ookla speedtest triggered this...
Then again, it might be spurious and setting the switch/lan to jumbo 9K might not actually have fixed the issue, time will tell hopefully.