결함이 있는 이더넷 컨트롤러를 고치려고 헛되이 노력하는 동안여기, 제가 시도한 것 중 하나는 머신에서 tcpdump를 실행하는 것이었습니다.
tcpdump가 ping 응용 프로그램이 전송한다고 생각한 일부 ICMP 패킷이 동일한 컴퓨터에서 실행되고 있음에도 불구하고 실제로 네트워크로 전송되지 않는다는 사실을 감지할 수 있다는 점이 흥미로웠습니다. 이 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
시퀀스 번호가 어떻게 몇 번 바뀌는지 확인하세요. 이는 ping 응용 프로그램에서 생성된 패킷이 실제로 상자를 떠나지 않음을 나타냅니다.
이것은 내 질문으로 이어집니다: tcpdump는 ICMP 패킷이 실제로 전송되지 않았음을 어떻게 감지합니까? 어떤 방식으로든 라인에 있는 내용을 직접 모니터링할 수 있습니까?
이것이 구현된다면 커널의 일부에 연결하여 네트워크 컨트롤러의 표준 부분인 일부 하드웨어에 연결된다고 가정합니다.
그래도 이건 꽤 멋지네요! 이것이 실제로 tcpdump가 수행하는 작업이 아닌 경우 누군가 소프트웨어에서 손실된 패킷을 감지하는 방법을 설명해 줄 수 있습니까?
답변1
예. 네트워크 인터페이스를 무차별 모드로 전환함으로써 tcpdump는 네트워크 인터페이스에서 나가고 들어오는 것이 무엇인지 정확하게 볼 수 있습니다.
tcpdump는 Layer2+에서 실행됩니다. 이더넷, FDDI, PPP 및 SLIP, 토큰 링 및 tcpdump에 대한 모든 무거운 작업을 수행하는 libpcap에서 지원하는 기타 프로토콜을 보는 데 사용할 수 있습니다.
pcap_datalink() 부분을 살펴보세요pcap 매뉴얼 페이지tcpdump(libpcap을 통해)가 분석할 수 있는 계층 2 프로토콜의 전체 목록입니다.
읽다tcpdump 매뉴얼 페이지이는 tcpdump 및 libpcap이 커널 및 네트워크 인터페이스와 상호 작용하여 원시 데이터 링크 계층 프레임을 읽는 방법에 대한 좋은 아이디어를 제공합니다.