欠陥のあるイーサネットコントローラを修復しようとする無駄な努力中ここ、私が試したことの1つは、マシンで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 がカーネルやネットワークインタフェースと対話して生のデータリンクレイヤフレームを読み取る方法について良いアイデアを提供します。