Experimente /sys/class/net/eth0/statistics/ (por exemplo, eth0 ), não é perfeito, mas divide os erros por transmitir / receber e por tipos de erros de transportadora, janela, fifo, crc, frame, comprimento (e mais alguns).
As gotas não são as mesmas que "ignoradas", netstat mostram estatísticas de nível de interface, um pacote multicast ignorado por um nível mais alto (camada 3, a pilha IP) não será mostrado como uma queda (embora possa aparecer como "filtrado" em algumas estatísticas da NIC). As estatísticas podem ser um pouco complicadas por vários recursos de descarregamento.
Você pode obter mais estatísticas se tiver 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
[...]
Algumas estatísticas dependem do driver da NIC, assim como o significado exato. O acima é de um Intel e1000 . Tendo analisado alguns drivers, alguns coletam muito mais estatísticas do que outros (as estatísticas disponíveis para o ethtool tendem a ser mantidas em arquivo de origem separado, por exemplo, drivers/net/ethernet/intel/e1000/e1000_ethtool.c , se você precisar vasculhar).
ethtool -i eth0 mostrará os detalhes do driver, a saída de lspci -v deve ser mais detalhada, embora com um pouco de confusão também.
Atualizar
Em tg3.c function tg3_rx() há apenas um lugar que parece provável com um tp->rx_dropped++ , mas o código está cheio de goto s, então existem várias outras causas além do óbvio, ie qualquer coisa com goto drop_it ou goto drop_it_no_recycle .
(Note que o drop counter é um dos poucos mantidos pelo driver, o resto é mantido pelo próprio dispositivo.)
A fonte do driver que tenho que entregar é 3.123. Meu melhor palpite é esse código:
if (len > (tp->dev->mtu + ETH_HLEN) &&
skb->protocol != htons(ETH_P_8021Q)) {
dev_kfree_skb(skb);
goto drop_it_no_recycle;
}
Verifique o MTU, possíveis causas são jumbo frames ou frames Ethernet de tamanho muito grande para permitir o encapsulamento. Não consigo explicar por que tcpdump pode alterar o comportamento, não se sabe se muda a interface MTU. Note também que você pode "ver" pacotes maiores que o MTU com tcpdump se TSO / LRO está ativado ( explicação ).