Lowering the MTU for a modem may result in a kernel crash

[majorz]

Affects both US and EU modem variants. Both Quectel EC25 and Simcom SIM7600G were tested a Fin board. Reproduced by customer on both balenaOS 2.95.8 (kernel 5.10.83-v7) or balenaOS 2.72.0+rev1 (kernel 5.4.83-v7).

1. Make the wwan0 primary interface: nmcli c down 'Wired connection 1'

2. Lower the MTU value to 1358 from the original default (we have enforced via config MTU of 1500 as default): ip link set mtu 1358 dev wwan0

3. Try generating traffic with fragmented packets:

   • ping -s 2800 172.16.1.1

   • base64 /dev/urandom | head -c 5000 > output.txt && curl -X POST -d @output.txt https://staging-api.bpcorp.xyz/

4. If that does not cause the crash alternatively VPN traffic may do that.

Logs of the crashes (not all the time it is possible to capture the logs before the device reboots).

[ +0.000052] br-a678f29ddfc0: port 10(vethba3cece) entered disabled state
[Apr29 21:13] dwc_otg: DEVICE:005 : update_urb_state_xfer_comp:750:trimming xfer length
[ +0.032241] python3: page allocation failure: order:0, mode:0xa20(GFP_ATOMIC), nodemask=(null),cpuset=docker-c128e732dc738a10d2a03a2ded16993b655cb2e88f2631b91337dbd61d89e6b4.scope,mems_allowed=0
[ +0.000034] CPU: 0 PID: 4191 Comm: python3 Tainted: P C O 5.4.83-v7 #1
[ +0.000005] Hardware name: BCM2835
[ +0.000005] Backtrace:
[ +0.000017] [<8010e1a4>] (dump_backtrace) from [<8010e518>] (show_stack+0x20/0x24)
[ +0.000008] r7:ffffffff r6:00000000 r5:600b0113 r4:816a2b8c
[ +0.000011] [<8010e4f8>] (show_stack) from [<80a1a024>] (dump_stack+0xd4/0x118)
[ +0.000012] [<80a19f50>] (dump_stack) from [<802eda88>] (warn_alloc+0xe0/0x174)
[ +0.000009] r10:00000000 r9:89936000 r8:00000000 r7:ffffe000 r6:80cf2928 r5:00000000
[ +0.000005] r4:00000000 r3:816077c8
[ +0.000011] [<802ed9a8>] (warn_alloc) from [<802eec70>] (__alloc_pages_nodemask+0x1154/0x1240)
[ +0.000005] r3:00000000 r2:80cf2928
[ +0.000007] r7:00000a20 r6:b9cd97e4 r5:00000201 r4:00000200
[ +0.000012] [<802edb1c>] (__alloc_pages_nodemask) from [<80836a58>] (skb_copy_ubufs+0xe0/0x540)
[ +0.000009] r10:b78ab000 r9:00000001 r8:b78ab058 r7:000033b4 r6:b9cd97e4 r5:00000a20
[ +0.000004] r4:00088dca
[ +0.000010] [<80836978>] (skb_copy_ubufs) from [<808505b0>] (__netif_receive_skb_core+0xb98/0xc58)
[ +0.000009] r10:b78ab000 r9:00000001 r8:b78ab058 r7:00000008 r6:b78ab040 r5:8160a938
[ +0.000005] r4:899ed0c0
[ +0.000008] [<8084fa18>] (__netif_receive_skb_core) from [<808506bc>] (__netif_receive_skb_one_core+0x4c/0x90)
[ +0.000009] r10:0000012c r9:00000001 r8:00000000 r7:00000040 r6:be5821c8 r5:00000000
[ +0.000004] r4:b78ab000

The customer is using Zerotier in standard network host mode in a docker container, connected to some network in the Zerotier One, which may or may not be related to the crash.