TOS 3.10
browsing the router’s ifaces I noticed quite (a high - 1.52%) count of rxdrops
RX packets:4221129 errors:0 dropped:64259 overruns:0 frame:0
RX bytes:614985946 (586.4 MiB)
All other ifaces are peachy. Is this perhaps a driver issue? How to troubleshoot/debug/resolve?
Shouldn’t tx-checksum-ipv4 be on as opposed to tx-checksum-ip-generic, if that would make a difference?
To my understanding a drop ratio of < 0.5% could not be unexpected, though 0% is certainly best, however 1.5% is way above that threshold and considered critical.
ethtool -k br-lan
Features for br-lan:
rx-checksumming: off [fixed]
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [requested on]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: on
tx-tcp6-segmentation: on
udp-fragmentation-offload: off [requested on]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [requested on]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: on [fixed]
netns-local: on [fixed]
tx-gso-robust: off [requested on]
tx-fcoe-segmentation: off [requested on]
tx-gre-segmentation: on
tx-ipip-segmentation: on
tx-sit-segmentation: on
tx-udp_tnl-segmentation: on
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: on
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
busy-poll: off [fixed]
Do you have firewall-rules dropping packages?
On the WAN sure but not on the LAN. To my humble understanding rxdrops are hardware (iface) counts and not netfilter counts, being on different layers.
had a look at those explanations and followed the advice of setting the iface into promiscuous mode the iface should not drop packets and instead accepting all the packets which flows through the iface.
However the drop count keeps increasing even in promiscuous mode.
Next thing looked into increasing the rx ring buffer which turned out not being supported on the br-lan iface.
Next on to Support, Support Requests, Training, Documentation, and Knowledge base for Check Point products and services
RX Error counters are incremented by frames received by the NIC that are corrupted in some way:
Possible duplex mismatch on both interfaces of the link.
Faulty NIC, cable, physical media issue.
CRC failures.
Suppose duplex mismatch and faulty media are unlikely, considering that all other ifaces are showing clean. Leaves CRC failure as potential cause, however /sys/devices/virtual/net/br-lan/statistics/rx_crc_errors count is 0…
So, what else then?
enabling/disabling Spanning Tree Protocol does not make a difference
OK, to my lan if I have connected several “smart home”-devices that I don’t allow internet access via drop-rules.
Firewall is turned off for bridging by default anyway ->/etc/sysctl
# disable bridge firewalling by default
net.bridge.bridge-nf-call-arptables=0
net.bridge.bridge-nf-call-ip6tables=0
net.bridge.bridge-nf-call-iptables=0
From an extensive tcpdump it was discovered that
- the majority of the rx frames being dropped appear to be originating from Sonos sound devices (play 1 and play 5) when broadcasting. The protocol type (0x6970) however seems to be
unknown to TO’s br-lan driver and thus getting dropped.
- removing the Sonos devices from the network is drastictly decreasing the
rxdrops count/ratio
- despite the
rxdrops in the router’s br-lan both sound devices are operating well
According to this Sonos patent etherType 0x6970 is proprietary and related to their multicast routing. Unclear what they want to achieve with it when it is getting flagged as unknown by network equipment and thus rendering it useless
The minor remainder of rxdrops counts can probably be attributed to an iPad and two AVM repeaters wanting to establish ipv6 traffic whilst ipv6 being disabled in the router’s kernel and neither even having an ipv6 address assigned from the router, leading to a drop flag in the router’s kernel.
2 Likes