Linux network interface broadcast statistics

The ethtool command is used to query the driver for statistics that the NIC is reporting. ethtool -S ethX will show you the stats for a particular card, and you can see where the drops are.

Most commonly you'll be losing packets in the ring buffer (reported as a stat like "discard" "fifo" "bufs", it varies from card to card) and you resolve this by increasing the ring buffer with ethtool -g. See man ethtool for more.

The netstat command is used to query the kernel's networking stack. netstat -s will show you statistics and you can see if you're losing traffic in the backlog (after NIC but before socket buffer) or in socket buffers (too-small buffers or slow application) or elsewhere.

Try /sys/class/net/eth0/statistics/ (i.e. for eth0), it's not perfect but it breaks down errors by transmit/receive and by carrier, window, fifo, crc, frame, length (and a few more) types of errors.

Drops are not the same as "ignored", netstat show interface level statistics, a multicast packet ignored by a higher level (layer 3, the IP stack) won't show as a drop (though it might show up as "filtered" on some NIC stats). Statistics may be complicated somewhat by various offload features.

You can get more stats if you have ethtool:

# ethtool -S eth0
 rx_packets: 60666755
 tx_packets: 2206194
 rx_bytes: 6630349870
 tx_bytes: 815877983
 rx_broadcast: 58230114
 tx_broadcast: 9307
 rx_multicast: 8406
 tx_multicast: 17
 rx_errors: 0
 tx_errors: 0
 tx_dropped: 0
 multicast: 8406
 collisions: 0
 rx_length_errors: 0
 rx_over_errors: 0
 rx_crc_errors: 0
 rx_frame_errors: 0
 rx_no_buffer_count: 0
 rx_missed_errors: 0
 tx_aborted_errors: 0
 tx_carrier_errors: 0
 tx_fifo_errors: 0
 tx_heartbeat_errors: 0
 [...]

Some statistics depend on the NIC driver, as will the exact meaning. The above is from an Intel e1000. Having looked at handful of drivers, some collect many more statistics than others (the stats available to ethtool tend to be kept in separate source file, e.g. drivers/net/ethernet/intel/e1000/e1000_ethtool.c, if you need to rummage).

ethtool -i eth0 will show the driver details, the output of lspci -v should be more detailed, though with a bit of clutter too.

Update In tg3.c function tg3_rx() there's only one place that looks likely with a tp->rx_dropped++, but the code is littered with gotos, so there are several other causes than the obvious, i.e. anything with goto drop_it or goto drop_it_no_recycle. (Note that the drop counter is one of the few maintained by the driver, the rest are maintained by the device itself.)

The driver source I have to hand is 3.123. My best guess is this code:

           if (len > (tp->dev->mtu + ETH_HLEN) &&
                skb->protocol != htons(ETH_P_8021Q)) {
                    dev_kfree_skb(skb);
                    goto drop_it_no_recycle;
            }

Check the MTU, possible causes are jumbo frames, or slightly oversized ethernet frames to allow for encapsulation. I cannot explain why tcpdump might change the behaviour, it's not known to change the interface MTU. Note also that you may "see" packets larger then the MTU with tcpdump if TSO/LRO is enabled (explanation).