欠陥のあるイーサネットコントローラ here を修正するために無駄に試みていたので、マシンで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が機能していない場合、ソフトウェアで欠落しているパケットを検出した方法を誰かに説明してもらえますか?
はい。ネットワークインターフェースを無差別モードにすることにより、tcpdumpはネットワークインターフェースの送信(および受信)を正確に確認できます。
tcpdumpはlayer2 +で動作します。イーサネット、FDDI、PPP&SLIP、トークンリング、およびtcpdumpのすべての重い作業を行うlibpcapでサポートされているその他のプロトコルを調べるために使用できます。
pcap man page のpcap_datalink()セクションを見て、tcpdump(libpcap経由)が分析できるレイヤー2プロトコルの完全なリストを確認してください。 。
tcpdumpのmanページ を読むと、tcpdumpとlibpcapがカーネルおよびネットワークインターフェースと正確にどのようにインターフェースできるかをよく理解できます。生データリンク層フレームを読み取ります。