Von welcher Ebene des Netzwerkstapels erhält tcpdump seine Informationen?

Wie ich vergeblich versuche , einen fehlerhaften Ethernet - Controller zu beheben hier , ich eine Sache probierte , war an der Maschine tcpdump laufen.

Ich fand es interessant, dass tcpdump in der Lage war, zu erkennen, dass einige der ICMP-Pakete, die die Ping-Anwendung für gesendet hielt, nicht über das Kabel gingen, obwohl sie auf demselben Computer ausgeführt wurden. Ich habe diese tcpdump-Ergebnisse hier reproduziert:

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

Beachten Sie, wie die fortlaufende Nummer mehrmals springt. Dies zeigt an, dass die Ping-Anwendung Pakete generiert, die die Box nicht tatsächlich verlassen.

Das bringt mich zu meiner Frage: Wie konnte tcpdump feststellen, dass die ICMP-Pakete nicht wirklich ausgehen? Kann es irgendwie direkt überwachen, was sich auf dem Draht befindet?

Wenn dies erreicht wird, gehe ich davon aus, dass eine Schnittstelle zu einem Teil des Kernels besteht, der wiederum mit einer Hardware verbunden ist, die ein Standardteil eines Netzwerkcontrollers ist.

Trotzdem ist das ziemlich cool! Wenn das eigentlich nicht so ist, wie tcpdump funktioniert, kann mir jemand erklären, wie es die fehlenden Pakete in der Software erkannt hat?

Ja. Durch Versetzen von Netzwerkschnittstellen in den Promiscuous-Modus kann tcpdump genau sehen, was von der Netzwerkschnittstelle ausgeht (und in die Netzwerkschnittstelle eintritt).

tcpdump wird auf Layer2 + ausgeführt. Es kann verwendet werden, um Ethernet, FDDI, PPP & SLIP, Token Ring und jedes andere von libpcap unterstützte Protokoll zu betrachten, das alle Aufgaben von tcpdump übernimmt.

Im Abschnitt pcap_datalink () der pcap-Manpage finden Sie eine vollständige Liste der Layer-2-Protokolle, die tcpdump (über libpcap) analysieren kann.

Wenn Sie die tcpdump-Manpage lesen , erhalten Sie ein gutes Verständnis dafür, wie genau die tcpdump- und libpcap-Schnittstelle mit dem Kernel und den Netzwerkschnittstellen funktioniert, um die Rohdaten-Link-Layer-Frames lesen zu können.