注:默认情况下,tcpdump临听它遇见的第一个网络接口,如果它选择了错误的接口,可以-i标志强行指定接口,如果DNS不能用,或者只是不希望tcpdump进行名字查找,请使用-n选项,这个选项(-n)很重要,因为较慢的DNS服务会导致过滤器在tcpdump仍可以处理包之前就开始丢包,-v标志加您看到的有关包的信息,-vv则提供更为详细的数据,-w (test.cap) 则存入一个文件(-r标志可以再把它们读回来)
tcpdump默认抓包大小为96个BYTE,如果用-s 0修改,则忽略包的大小写限制,按包的实际大小抓取.
(example: tcpdump -X -s 0 w test.cap port 23)
tcpdump src net 192.168.1.0/24 and dst port 80
tcpdump -i eth1 -s 0 -w test.cap host 192.168.2.1 and host 23.33.123.125
tcpdump [-nn] [-i 介面] [-w 儲存檔名] [-c 次數] [-Ae]
[-qX] [-r 檔案] [所欲擷取的資料內容]參數：
-nn：直接以 IP 及 port number 顯示，而非主機名與服務名稱
-i ：後面接要『監聽』的網路介面，例如 eth0, lo, ppp0 等等的介面；
-w ：如果你要將監聽所得的封包資料儲存下來，用這個參數就對了！後面接檔名
-c ：監聽的封包數，如果沒有這個參數， tcpdump 會持續不斷的監聽，
直到使用者輸入 [ctrl]-c 為止。
-A ：封包的內容以 ASCII 顯示，通常用來捉取 WWW 的網頁封包資料。
-e ：使用資料連接層 (OSI 第二層) 的 MAC 封包資料來顯示；
-q ：僅列出較為簡短的封包資訊，每一行的內容比較精簡
-X ：可以列出十六進位 (hex) 以及 ASCII 的封包內容，對於監聽封包內容很有用
-r ：從後面接的檔案將封包資料讀出來。那個『檔案』是已經存在的檔案，
並且這個『檔案』是由 -w 所製作出來的。
所欲擷取的資料內容：我們可以專門針對某些通訊協定或者是 IP 來源進行封包擷取，
那就可以簡化輸出的結果，並取得最有用的資訊。常見的表示方法有：
'host foo', 'host 127.0.0.1' ：針對單部主機來進行封包擷取
'net 192.168' ：針對某個網域來進行封包的擷取；
'src host 127.0.0.1' 'dst net 192.168'：同時加上來源(src)或目標(dst)限制
'tcp port 21'：還可以針對通訊協定偵測，如 tcp, udp, arp, ether 等
還可以利用 and 與 or 來進行封包資料的整合顯示呢！範例一：以 IP 與 port number 捉下 eth0 這個網路卡上的封包，持續 3 秒[root@linux ~]# tcpdump -i eth0 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
01:33:40.41 IP 192.168.1.100.22 > 192.168.1.11.1190: P 116:232(116) ack 1 win 964801:33:40.41 IP 192.168.1.100.22 > 192.168.1.11.1190: P 232:364(132) ack 1 win 9648
<==按下 [ctrl]-c 之後結束6680 packets captured
<==捉下來的封包數量14250 packets received by filter
<==由過濾所得的總封包數量7512 packets dropped by kernel
<==被核心所丟棄的封包如果你是第一次看 tcpdump 的 man page 時，肯定一個頭兩個大，因為 tcpdump 幾乎都是分析封包的表頭資料，使用者如果沒有簡易的網路封包基礎，要看懂粉難吶！ 所以，至少您得要回到裡面去將 TCP 封包的表頭資料理解理解才好啊！ ^_^！至於那個範例一所產生的輸出範例中，我們可以約略區分為數個欄位， 我們以範例一當中那個特殊字體行來說明一下：
- 01:33:40.41：這個是此封包被擷取的時間，『時:分:秒』的單位；
- IP：透過的通訊協定是 IP ；
- 192.168.1.100.22 > ：傳送端是 192.168.1.100 這個 IP，而傳送的 port number 為 22，您必須要瞭解的是，那個大於 (>) 的符號指的是封包的傳輸方向喔！
- 192.168.1.11.1190：接收端的 IP 是 192.168.1.11， 且該主機開啟 port 1190 來接收；
- P 116:232(116)：這個封包帶有 PUSH 的資料傳輸標誌， 且傳輸的資料為整體資料的 116~232 byte，所以這個封包帶有 116 bytes 的資料量；
- ack 1 win 9648：ACK與 Window size 的相關資料。
最簡單的說法，就是該封包是由 192.168.1.100 傳到 192.168.1.11，透過的 port 是由 22 到 1190 ， 且帶有 116 bytes 的資料量，使用的是 PUSH 的旗標，而不是 SYN 之類的主動連線標誌。 呵呵！不容易看的懂吧！所以說，上頭才講請務必到 的部分去瞧一瞧的啊！
再來，一個網路狀態很忙的主機上面，你想要取得某部主機對你連線的封包資料而已時， 使用 tcpdump 配合管線命令與正規表示法也可以，不過，畢竟不好捉取！ 我們可以透過 tcpdump 的表示法功能，就能夠輕易的將所需要的資料獨立的取出來。 在上面的範例一當中，我們僅針對 eth0 做監聽，所以整個 eth0 介面上面的資料都會被顯示到螢幕上， 不好分析啊！那麼我們可以簡化嗎？例如只取出 port 21 的連線封包，可以這樣做：
[root@linux ~]# tcpdump -i eth0 -nn port 21
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
01:54:37.96 IP 192.168.1.11.1240 > 192.168.1.100.21: . ack 1 win 65535
01:54:37.96 IP 192.168.1.100.21 > 192.168.1.11.1240: P 1:21(20) ack 1 win 5840
01:54:38.12 IP 192.168.1.11.1240 > 192.168.1.100.21: . ack 21 win 65515
01:54:42.79 IP 192.168.1.11.1240 > 192.168.1.100.21: P 1:17(16) ack 21 win 65515
01:54:42.79 IP 192.168.1.100.21 > 192.168.1.11.1240: . ack 17 win 5840
01:54:42.79 IP 192.168.1.100.21 > 192.168.1.11.1240: P 21:55(34) ack 17 win 5840
|
瞧！這樣就僅提出 port 21 的資訊而已，且仔細看的話，你會發現封包的傳遞都是雙向的， client 端發出『要求』而 server 端則予以『回應』，所以，當然是有去有回啊！ 而我們也就可以經過這個封包的流向來瞭解到封包運作的過程。 舉例來說：
- 我們先在一個終端機視窗輸入『 tcpdump -i lo -nn 』 的監聽，
- 再另開一個終端機視窗來對本機 (127.0.0.1) 登入『ssh localhost』
那麼輸出的結果會是如何？
[root@linux ~]# tcpdump -i lo -nn
1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
2 listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes
3 11:02:54.253777 IP 127.0.0.1.32936 > 127.0.0.1.22: S 933696132:933696132(0)
win 32767
4 11:02:54.253831 IP 127.0.0.1.22 > 127.0.0.1.32936: S 920046702:920046702(0)
ack 933696133 win 32767
5 11:02:54.253871 IP 127.0.0.1.32936 > 127.0.0.1.22: . ack 1 win 8192
6 11:02:54.272124 IP 127.0.0.1.22 > 127.0.0.1.32936: P 1:23(22) ack 1 win 8192
7 11:02:54.272375 IP 127.0.0.1.32936 > 127.0.0.1.22: . ack 23 win 8192
|
上表顯示的頭兩行是 tcpdump 的基本說明，然後：
- 第 3 行顯示的是『來自 client 端，帶有 SYN 主動連線的封包』，
- 第 4 行顯示的是『來自 server 端，除了回應 client 端之外(ACK)，還帶有 SYN 主動連線的標誌；
- 第 5 行則顯示 client 端回應 server 確定連線建立 (ACK)
- 第 6 行以後則開始進入資料傳輸的步驟。
從第 3-5 行的流程來看，熟不熟悉啊？沒錯！那就是 的基礎流程啦！夠有趣吧！ 不過 tcpdump 之所以被稱為駭客軟體之一可不止上頭介紹的功能吶！ 上面介紹的功能可以用來作為我們主機的封包連線與傳輸的流程分析， 這將有助於我們瞭解到封包的運作，同時瞭解到主機的防火牆設定規則是否有需要修訂的地方。
更神奇的使用要來啦！如果我們使用 tcpdump 在 router 上面監聽『明碼』的傳輸資料時， 例如 FTP 傳輸協定，你覺得會發生什麼問題呢？ 我們先在主機端下達『 tcpdump -i lo port 21 -nn -X 』然後再以 ftp 登入本機，並輸入帳號與密碼， 結果你就可以發現如下的狀況：
[root@linux ~]# tcpdump -i lo -nn -X 'port 21'
0x0000: 4500 0048 2a28 4000 4006 1286 7f00 0001 E..H*(@.@.......
0x0010: 7f00 0001 0015 80ab 8355 2149 835c d825 .........U!I.\.%
0x0020: 8018 2000 fe3c 0000 0101 080a 0e2e 0b67 .....<.........g
0x0030: 0e2e 0b61 3232 3020 2876 7346 5450 6420 ...a220.(vsFTPd.
0x0040: 322e 302e 3129 0d0a 2.0.1)..
0x0000: 4510 0041 d34b 4000 4006 6959 7f00 0001 E..A.K@.@.iY....
0x0010: 7f00 0001 80ab 0015 835c d825 8355 215d .........\.%.U!]
0x0020: 8018 2000 fe35 0000 0101 080a 0e2e 1b37 .....5.........7
0x0030: 0e2e 0b67 5553 4552 2064 6d74 7361 690d ...gUSER.dmtsai.
0x0040: 0a .
0x0000: 4510 004a d34f 4000 4006 694c 7f00 0001 E..J.O@.@.iL....
0x0010: 7f00 0001 80ab 0015 835c d832 8355 217f .........\.2.U!.
0x0020: 8018 2000 fe3e 0000 0101 080a 0e2e 3227 .....>........2'
0x0030: 0e2e 1b38 5041 5353 206d 7970 6173 7377 ...8PASS.mypassw
0x0040: 6f72 6469 7379 6f75 0d0a ordisyou..
|
上面的輸出結果已經被簡化過了，你必須要自行在你的輸出結果當中搜尋相關的字串才行。 從上面輸出結果的特殊字體中，我們可以發現『該 FTP 軟體使用的是 vsftpd ，並且使用者輸入 dmtsai 這個帳號名稱，且密碼是 mypasswordisyou』 嘿嘿！你說可不可怕啊！如果使用的是明碼的方式來傳輸你的網路資料？ 所以我們才常常在講啊，網路是很不安全低！
另外你得瞭解，為了讓網路介面可以讓 tcpdump 監聽，所以執行 tcpdump 時網路介面會啟動在 『錯亂模式 (promiscuous)』，所以你會在 /var/log/messages 裡面看到很多的警告訊息， 通知你說你的網路卡被設定成為錯亂模式！別擔心，那是正常的。 至於更多的應用，請參考 man tcpdump 囉！
例題：如何使用 tcpdump 監聽 (1)來自 eth0 介面卡且 (2)通訊協定為 port 22 ，(3)目標來源為 192.168.1.100 的封包資料？
答：
tcpdump -i eth0 -nn 'port 22 and src host 192.168.1.100' |
故障现象：局域网新安装了后台为qmail的邮件服务器server，邮件服务器收发邮件等基本功能正常，但在使用中发现一个普遍的怪现象
：pc机器上发邮件时连接邮件服务器后要等待很久的时间才能开始实际的发送工作。
排查：网络连接没有问题，邮件服务器server和下面的pc性能都没有问题，问题可能出在哪里呢？为了进行准确的定位，我们在pc机
client上发送邮件，同时在邮件服务器server上使用tcpdump对这个client的数据包进行捕获分析，如下：
server#tcpdump host client
tcpdump: listening on hme0
19:04:30.040578 client.1065 > server.smtp: S 1087965815:1087965815(0) win 64240
0,nop,nop,timestamp[|tcp]> (DF)
19:04:30.040613 server.smtp > client.1065: S 99285900:99285900(0) ack 1087965816 win 10136
0,nop,[|tcp]> (DF)
19:04:30.040960 client.1065 > server.smtp: . ack 1 win 64240 (DF)
顺利的完成三次握手，目前为止正常，往下看
19:04:30.048862 server.33152 > client.113: S 99370916:99370916(0) win 8760 (DF)
19:04:33.411006 server.33152 > client.113: S 99370916:99370916(0) win 8760 (DF)
19:04:40.161052 server.33152 > client.113: S 99370916:99370916(0) win 8760 (DF)
19:04:56.061130 server.33152 > client.113: R 99370917:99370917(0) win 8760 (DF)
19:04:56.070108 server.smtp > client.1065: P 1:109(10 ack 1 win 10136 (DF)
这里有问题了，我们看到server端试图连接client的113 identd端口，要求认证，然而没有收到client端的回应，server端重复尝试了3
次，费时26秒后，才放弃认证请求，主动发送了reset标志的数据包，开始push后面的数据，而正是在这个过程中所花费的26秒时间，造
成了发送邮件时漫长的等待情况。
问题找到了，就可以对症下药了，通过修改服务器端的qmail配置，使它不再进行113端口的认证，再次抓包，看到邮件server不再进行
113端口的认证尝试，而是在三次握手后直接push数据，问题解决！
总结：上面我们通过实际的例子演示了包分析软件在故障解决中起到的作用，通过这些例子，我们不难发现，用好包分析软件，对系统
管理员快速准确定位网络故障，分析网络问题有不可替代的作用
