z jakiego poziomu stosu sieciowego tcpdump pobiera informacje?

Jak starałem się próżny, aby naprawić uszkodzony kontroler ethernet tutaj , jedno próbowałem biegł tcpdump na maszynie.

Interesujące było dla mnie to, że tcpdump był w stanie wykryć, że niektóre pakiety ICMP, które aplikacja ping uznała za wysyłane, tak naprawdę nie wychodzą z sieci, nawet jeśli działały na tej samej maszynie. Tutaj odtworzyłem wyniki tcpdump:

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

Zwróć uwagę, jak liczba seq przeskakuje kilka razy ... co oznacza pakiety generowane przez aplikację ping, które tak naprawdę nie opuszczają pola.

Co prowadzi mnie do mojego pytania: w jaki sposób tcpdump był w stanie wykryć, że pakiety ICMP tak naprawdę nie wychodziły? Czy jest w stanie w jakiś sposób bezpośrednio monitorować, co jest na kablu?

Jeśli tak się stanie, zakładam, że dzieje się to poprzez interfejs do jakiejś części jądra, która z kolei łączy się z jakimś sprzętem, który jest standardową częścią kontrolera sieciowego.

Mimo to to całkiem fajne! Jeśli tak nie jest tak, jak działa tcpdump, czy ktoś może mi wyjaśnić, jak wykrył brakujące pakiety w oprogramowaniu?

Tak. Przełączając interfejsy sieciowe w tryb rozwiązujący, tcpdump jest w stanie zobaczyć dokładnie, co wychodzi (i wchodzi) w interfejs sieciowy.

tcpdump działa na warstwie 2 +. można go używać do przeglądania sieci Ethernet, FDDI, PPP i SLIP, Token Ring i dowolnego innego protokołu obsługiwanego przez libpcap, który wykonuje wszystkie ciężkie działania tcpdump.

Zajrzyj do sekcji pcap_datalink () strony podręcznika pcap, aby uzyskać pełną listę protokołów warstwy 2, które tcpdump (przez libpcap) może analizować.

Przeczytanie strony podręcznika tcpdump pozwoli ci dobrze zrozumieć, w jaki sposób dokładnie tcpdump i interfejs libpcap z jądrem i interfejsami sieciowymi są w stanie odczytać ramki warstwy łącza danych surowych.