da quale livello dello stack di rete tcpdump ottiene le sue informazioni?

Mentre stavo cercando invano di riparare un controller Ethernet difettoso qui , una cosa che ho provato è stato eseguire tcpdump sulla macchina.

Ho trovato interessante che tcpdump fosse in grado di rilevare che alcuni dei pacchetti ICMP che l'applicazione ping pensava che stesse inviando non stavano effettivamente uscendo sul filo, anche se era in esecuzione sulla stessa macchina. Ho riprodotto i risultati di tcpdump qui:

14:25:01.162331 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 1, length 64
14:25:02.168630 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 2, length 64
14:25:02.228192 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 2, length 64
14:25:07.236359 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 3, length 64
14:25:07.259431 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 3, length 64
14:25:31.307707 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 9, length 64
14:25:32.316628 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 10, length 64
14:25:33.324623 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 11, length 64
14:25:33.349896 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 11, length 64
14:25:43.368625 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 17, length 64
14:25:43.394590 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 17, length 64
14:26:18.518391 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 30, length 64
14:26:18.537866 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 30, length 64
14:26:19.519554 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 31, length 64
14:26:20.518588 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 32, length 64
14:26:21.518559 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 33, length 64
14:26:21.538623 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 33, length 64
14:26:37.573641 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 35, length 64
14:26:38.580648 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 36, length 64
14:26:38.602195 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 36, length 64

Notare come il numero seq salta più volte ... ciò indica che i pacchetti generati dall'applicazione ping non escono effettivamente dalla casella.

Il che mi porta alla mia domanda: in che modo tcpdump è stato in grado di rilevare che i pacchetti ICMP non stavano effettivamente uscendo? È in grado di monitorare in qualche modo direttamente ciò che è sul filo?

Se lo fa, suppongo che sia l'interfacciamento con una parte del kernel, che a sua volta si interfaccia con l'hardware che è una parte standard di un controller di rete.

Anche così, è piuttosto bello! Se in realtà non funziona come funziona tcpdump, qualcuno può spiegarmi come ha rilevato i pacchetti mancanti nel software?

Sì. Mettendo le interfacce di rete in modalità promiscua, tcpdump è in grado di vedere esattamente cosa sta uscendo (e dentro) l'interfaccia di rete.

tcpdump funziona su layer2 +. può essere usato per esaminare Ethernet, FDDI, PPP e SLIP, Token Ring e qualsiasi altro protocollo supportato da libpcap, che fa tutto il lavoro pesante di tcpdump.

Dai un'occhiata alla sezione pcap_datalink () della pagina man di pcap per un elenco completo dei protocolli di livello 2 che tcpdump (tramite libpcap) può analizzare.

Una lettura della pagina man di tcpdump ti darà una buona comprensione di come esattamente tcpdump e libpcap si interfacciano con il kernel e le interfacce di rete per essere in grado di leggere i frame del livello di collegamento dei dati non elaborati.