Question

Any ideas why RUX09 (RUTX_R_00.02.05.1/EG06ELAR04A04M4G on factory defaults) is generating dropped packets on wwan0 when there is traffic flowing over 4G (this cause discards also on snmp monitoring),

wwan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet6 addr: fe80::8d26:4e9a:aca1:690e/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:16382  Metric:1
          RX packets:23242 errors:0 dropped:23242 overruns:0 frame:0
          TX packets:55406 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:189529404 (180.7 MiB)  TX bytes:33325743 (31.7 MiB)

...with tcpdump we see,

09:38:15.577658 IP truncated-ip - 41439 bytes missing! 219.172.74.91 > 206.71.180.69: ip-proto-233
09:38:15.577934 unknown ip 0
09:38:15.577956 IP truncated-ip - 48659 bytes missing! 219.172.74.91 > 255.19.180.69: ip-proto-233
09:38:15.578226 unknown ip 0
09:38:15.578251 IP truncated-ip - 41439 bytes missing! 219.172.74.92 > 20.195.180.69: ip-proto-233
09:38:15.578438 unknown ip 0
09:38:15.578641 unknown ip 0
09:38:15.578636 IP truncated-ip - 41439 bytes missing! 219.172.74.92 > 69.143.180.69: ip-proto-233
09:38:15.578881 unknown ip 0
09:38:15.578901 IP truncated-ip - 48659 bytes missing! 219.172.74.92 > 118.91.180.69: ip-proto-233
09:38:15.579169 unknown ip 0
09:38:15.579282 IP truncated-ip - 41439 bytes missing! 219.172.74.92 > 140.11.180.69: ip-proto-233
09:38:15.579474 unknown ip 0
09:38:15.579632 IP truncated-ip - 41439 bytes missing! 219.172.74.92 > 188.215.180.69: ip-proto-233
09:38:15.579745 unknown ip 0
09:38:15.579949 unknown ip 0
09:38:15.579944 IP truncated-ip - 48659 bytes missing! 219.172.74.92 > 237.163.180.69: ip-proto-233
09:38:15.580208 unknown ip 0
09:38:15.580218 IP truncated-ip - 41439 bytes missing! 219.172.74.93 > 3.83.180.69: ip-proto-233

Mobile info,

Operator
Telia FI
Operator state
Registered (home)
Data connection state
Connected
Connection type
4G (LTE)
Signal strength
-51 dBm
Carrier Aggregation
Dual
Connected band
LTE BAND 3 / LTE BAND 7
RSRP
-62 dBm / -71 dBm
RSRQ
-7 dB / -12 dB
SINR
21.1 dB / 16 dB

Comments

Hi, I have exactly the same situation, I wonder - do you use bridged interface? Because that's what I use and because of that, IPv4 is set on other device so I don't even know if that's an issue or not.

Answer 1

Hello, 

Could you post IPv4 WAN, since the one you posted was for IPv6 and dropped packets are from IPv4

But main suspect in this situation would be MTU if yours Mobile service provider for some reason is lower than default value on RUTX (1500)

So you can try going to Network -> Interfaces -> <mobile_interface> -> Advanced settings, set set MTU to lower value, and check if packets are still dropped.

Best regards,
VidasKac

Comments

IPv6 was disabled and there is no other inet6 addresses except link-local,

qmimux0   Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:100.71.137.222  P-t-P:100.71.137.222  Mask:255.255.255.252
          inet6 addr: fe80::24e1:4fcf:9a40:5f08/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1460  Metric:1
          RX packets:301710 errors:0 dropped:0 overruns:0 frame:0
          TX packets:302034 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:43397573 (41.3 MiB)  TX bytes:66444700 (63.3 MiB)

wwan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet6 addr: fe80::42b1:e60b:df5a:705e/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:16382  Metric:1
          RX packets:298183 errors:0 dropped:298183 overruns:0 frame:0
          TX packets:302042 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:40430014 (38.5 MiB)  TX bytes:67653604 (64.5 MiB)

...we also tested this with multiple operators and I guess this is purely cosmetic problem. With Cisco routers we do not see similar issues and there is no need to lower MTU.

---

Hello, 

Could you launch tcpdump with option -ne and post the output here, that should give more information about the messages. 

Also are you having any issues with connection or only get those messages in tcpdump?

Best regards,
VidasKac

---

Sanitized tcpdump output,

14:21:53.193186 unknown ip 0
...
14:21:53.194543 unknown ip 0
14:21:53.200930 IP6 truncated-ip6 - 53452 bytes missing!89de:... > 7bd:...: ip-proto-100 53534
14:21:53.201359 unknown ip 0
14:21:53.201707 unknown ip 0
14:21:53.201992 unknown ip 0
14:21:53.202069 IP6 truncated-ip6 - 53108 bytes missing!89de:... > 7be:...: ip-proto-100 53534
14:21:53.202714 unknown ip 0
....
14:21:53.207547 unknown ip 0
14:21:53.207740 unknown ip 10
14:21:53.207948 unknown ip 0
...
14:21:53.210540 unknown ip 0
14:21:53.210692 unknown ip 15
14:21:53.210949 unknown ip 0
...
14:21:53.212448 unknown ip 0
14:21:53.212617 unknown ip 1
14:21:53.212853 unknown ip 0
...
14:21:53.215243 unknown ip 0
14:21:53.215551 IP truncated-ip - 49669 bytes missing! 17.148.0.96 > 0.0.202.73: ip-proto-222
14:21:53.215651 unknown ip 0
14:21:53.216063 unknown ip 0
14:21:53.216465 unknown ip 0
14:21:53.216586 unknown ip 2

I guess this is something related to linux qmi / 4G modem driver but we do not see any other errors. Only that discard counter is getting hits when traffic is moving trough 4G (and this causes alarm in our NMS).

---

Hello,

In certain instances you can receive message about truncated IP, it is not harmful, it simply means that received packet is truncated (separated to several parts).

If this hinders yours connection it could mean that there are differences of Maximum Transmission Unit (MTU) between network devices. To get rid of it you would need to make sure, that MTU between devices match and they send same maximum size packets, as other devices can accept.

If it does not hinder connection itself it can be because tcpdump truncates (separates) packages larger than 1472 bytes, that is why you are getting "first" package with bytes missing but with IP and rest of the header, but following packets does not have a header, thus missing ip you can try using tcpdump -s 0 option to make sure, that tcpdump captures whole packet, and see if message goes away.

Best regards,
VidasKac.

---

The problem is that SNMP is reporting discarded/dropped frames. And drop counter on wwan0 interface is getting hits continuously. Problem might be cosmetic, but should be fixed.

I don't know why but if we run tcpdump on wwan0 interface dropped counter isn't getting count anymore. After we stop tcpdump drop counter is starting to increment again.