High count of ethernet dropped RX packets on the WAN interface

I'm seeing a lot of dropped RX Ethernet packages on the WAN interface (see dropped:321787 below).

It is not an Ethernet cable problem before anyone asks (yes, I tested it and I know the cable is fine).

Also, I'm observing this in two completely different installs/ISPs (one at home and one in another house):

  1. OpenWrt 22.03.4 on a Redmi AX6S (WAN is DHCP, double-NAT since the ISP OLT does not allow to use bridged connection, IPv6 enabled)
  2. OpenWrt 22.03.5 on a NanoPI R4S (WAN is DHCP, VLAN filtered on the OLT configured in bridge mode, ISP uses IPoE, IPv6 enabled)

I've read this Suse article saying that dropped ethernet packages are not necessarily an error.

However with OpenWrt these values in the WAN interface are really high.

I'm wondering how I could identify the reason I'm observing such high numbers for dropped ethernet packages on the WAN interface.

wan       Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: 2804:XX::2/128 Scope:Global
          inet6 addr: 2804:XX:e614/64 Scope:Global
          inet6 addr: fe80::XX:e614/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:36703349 errors:0 dropped:321787 overruns:0 frame:0
          TX packets:14931865 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:44808973519 (41.7 GiB)  TX bytes:4644336027 (4.3 GiB)
1 Like

probably this

Thank you, but the link you posted points to the same Suse article I had already read and mentioned in the original post...

freely taken from the link I sent you:

if the rx_dropped counter stops incrementing while tcpdump is running; then it is more than likely showing drops because of the reasons listed earlier.

1 Like

Thank you. I forgot to mention in the original post I've already done that, my fault. I've haven't found anything unusual while inspecting the data I've captured using WireShark that could cause increase of Ethernet Dropped RX.

Actually, while capturing during a speedtest, I've noticed however some bursts of:

  • [TCP Dup Ack] packets
  • [TCP Out-of-Order] packets
  • [TCP Fast Retransmission] packets

Since they are TCP packets, I was under the impression that dropped packets by the TCP/IP stack do not count as dropped RX (Suse article says that "Unknown Protocol" would be logged as dropped RX, but these packets are TCP).

BTW, I don't intend to be rude and I do appreciate your help. But I've done my homework already, so other than sending me links to the internet, do you have any actual insight about the usual causes that could cause RX dropped packets to increase with OpenWrt?

1 Like

I'm not so good ...

I thought you didn't check with tcpdump ...

If I were you I would wait for information from someone more competent than me ...

and sorry for the inconvenience

1 Like

No problem. I do appreciate your help, thank you!

1 Like

MTU ?

if multi-wan

only wan

or wan and wanb

or only wanb

Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

cat /etc/config/network

from any devices involved

Upon further inspection of the captured frames using Wireshark, I did find the culprit: it is my ONT (VSOL V2802RH) to where the WAN port of my NanoPI R4S running OpenWrt is connected to.

Every 5 seconds it broadcasts 4 ethernet packages that are "Unknown Protocol" (0xfffa):

It means it is sending 69,120 invalid packets/day, which in the long run explains the high number of droopped RX packets in the WAN interface I'm observing.

I'm not sure if it is an ONT bug or something I should worry about.

Anyway marking this post as the solution.

2 Likes

Update: I checked this on my second network (HGU Fiberhome HG6143D to where the WAN port of my Redmi AX6S running OpenWrt is connected to) and the root cause it the same.

So this behavior does not seem exclusive of the VSOL ONT...

1 Like

Another update: after inspecting the payload of the WAN ethernet frames protocol "0xfffa" which are being dropped by OpenWrt, I've identified that these are packets sent by the ethernet switches of the ONT/ONU devices for loop detection. See the contents of each of these packages:

  • VSOL V2802RH: "realtek_loopback_detect_packet"
  • Fiberhome HG6143D: "This is loop detect frame send from 00:00:00:00:00:00 port 01"

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.