linux抓udp包

Ⅰ linux 抓的包怎麼看具體內容數據

linux上有兩種比較好的抓包工具：ethereal和tcpmp

對於ethereal，有圖形界面和字元界面兩種方式。
到linux系統上執行rpm -qa | grep ethereal-gnome可查看是否安裝了圖形版本
但是如果伺服器上沒有xwin圖形環境，那麼就只能用字元界面了

命令：tethereal
可選參數：-V、-f

如果只執行tethereal，那麼將只抓取數據包的包頭，不顯示里邊的內容。加上-V參數後，即可顯示內容。
-f 參數用於過濾，默認情況下將抓取tcp和udp所有協議。

如果想抓取UDP數據包並顯示內容，則執行tethereal -V -f udp 即可
另外還可以配合grep命令提取需要的關鍵內容

tcump命令是另外一個有用的工具，只能在字元下使用，

tcpmp -n -nn -vv -XX -tttt -c 10 -e
參數：
-n：數字埠
-nn：數字地址
-vv：輸出詳細信息
-c：抓取包的數量
-e：列印乙太網報頭信息
-i：選擇適配器

Ⅱ linux c語言實現，udp協議

UDP協議全稱是用戶數據報協議，在網路中它與TCP協議一樣用於處理數據包，是一種無連接的協議。在OSI模型中，在第四層--傳輸層，處於IP協議的上一層。UDP有不提供數據包分組、組裝和不能對數據包進行排序的缺點，也就是說，當報文發送之後，是無法得知其是否安全完整到達的。UDP用來支持那些需要在計算機之間傳輸數據的網路應用。包括網路視頻會議系統在內的眾多的客戶/伺服器模式的網路應用都需要使用UDP協議。UDP協議從問世至今已經被使用了很多年，雖然其最初的光彩已經被一些類似協議所掩蓋，但是即使是在今天UDP仍然不失為一項非常實用和可行的網路傳輸層協議。

Ⅲ 請教linux大牛，無法收到小於12位元組的UDP包

你確認你的廣播包在eth0和wlan0上都發出了嗎？我估計只在eth0上發了。 教你一個辦法確認,在linux上使用tcpmp 抓包： tcpmp -i eth0 tcpmp -i wlan0

Ⅳ Linux下如何抓指定IP的包

用tcpm命令可以抓指定IP的包，具體命令為：

tcpmp tcp -i eth1 -t -s 0 -c 100 and dst port 22 and src net 192.168.1.1 -w ./target.cap

參數解析：

tcp: ip icmp arp rarp 和 tcp、udp、icmp這些選項等都要放到第一個參數的位置，用來過濾數據報的類型。

-i eth1 : 只抓經過介面eth1的包

-t : 不顯示時間戳

-s 0 : 抓取數據包時默認抓取長度為68位元組。加上-S 0 後可以抓到完整的數據包

-c 100 : 只抓取100個數據包

dst port 22 : 抓取目標埠是22的數據包

src net 192.168.1.0/24 : 數據包的源網路地址為192.168.1.1

-w ./target.cap : 保存成cap文件，方便用ethereal(即wireshark)分析

(4)linux抓udp包擴展閱讀

tcpmp語法格式：

tcpmp [-adeflnNOpqStvx][-c<數據包數目>][-dd][-ddd][-F<表達文件>][-i<網路界面>][-r<數據包文件>][-s<數據包大小>][-tt][-T<數據包類型>][-vv][-w<數據包文件>][輸出數據欄位]

tcpmp主要參數說明：

1、-a 嘗試將網路和廣播地址轉換成名稱。

2、-c<數據包數目> 收到指定的數據包數目後，就停止進行傾倒操作。

3、-d 把編譯過的數據包編碼轉換成可閱讀的格式，並傾倒到標准輸出。

4、-dd 把編譯過的數據包編碼轉換成C語言的格式，並傾倒到標准輸出。

5、-ddd 把編譯過的數據包編碼轉換成十進制數字的格式，並傾倒到標准輸出。

6、-e 在每列傾倒資料上顯示連接層級的文件頭。

7、-f 用數字顯示網際網路地址。

8、-F<表達文件> 指定內含表達方式的文件。

9、-i<網路界面> 使用指定的網路截面送出數據包。

10、-l 使用標准輸出列的緩沖區。

11、-n 不把主機的網路地址轉換成名字。

12、-N 不列出域名。

Ⅳ linux系統下如何查看數據包

可以用 tcpmp 命令來抓包，比如

tcpmp-ieth0

其中，eth0就是你要抓包的網口。或者你可以用

tcpmp-ieth0-ne

其中 -ne 表示顯示不要省略MAC地址。

也可以抓包到文件，例如

tcpmp-ieth0-wtest.pcap

把抓下來的包保存到test.pcap文件中，可以用Wireshark打開來查看，慢慢分析包中的數據。

Ⅵ linux查看本地一個udp埠有沒有接收到數據包

使用如下命令： tcpmp udp port 200
查看一下《linux就該這么學》

Ⅶ 在Linux 上，編寫一個每秒接收 100萬UDP數據包的程序究竟有多難

首先，我們假設：
測量每秒的數據包(pps)比測量每秒位元組數(Bps)更有意思。您可以通過更好的管道輸送以及發送更長數據包來獲取更高的Bps。而相比之下，提高pps要困難得多。
因為我們對pps感興趣，我們的實驗將使用較短的 UDP 消息。准確來說是 32 位元組的 UDP 負載，這相當於乙太網層的 74 位元組。
在實驗中，我們將使用兩個物理伺服器：「接收器」和「發送器」。
它們都有兩個六核2 GHz的 Xeon處理器。每個伺服器都啟用了 24 個處理器的超線程(HT)，有 Solarflare 的 10G 多隊列網卡，有 11 個接收隊列配置。稍後將詳細介紹。
測試程序的源代碼分別是：udpsender、udpreceiver。
預備知識
我們使用4321作為UDP數據包的埠，在開始之前，我們必須確保傳輸不會被iptables干擾：

Shell

receiver$ iptables -I INPUT 1 -p udp --dport 4321 -j ACCEPT

receiver$ iptables -t raw -I PREROUTING 1 -p udp --dport 4321 -j NOTRACK

為了後面測試方便，我們顯式地定義IP地址：

Shell

receiver$ for i in `seq 1 20`; do

ip addr add 192.168.254.$i/24 dev eth2;

done

sender$ ip addr add 192.168.254.30/24 dev eth3

1. 簡單的方法
開始我們做一些最簡單的試驗。通過簡單地發送和接收，有多少包將會被傳送？
模擬發送者的偽代碼：

Python

fd = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

fd.bind(("0.0.0.0", 65400)) # select source port to rece nondeterminism

fd.connect(("192.168.254.1", 4321))

while True:

fd.sendmmsg(["x00" * 32] * 1024)

因為我們使用了常見的系統調用的send，所以效率不會很高。上下文切換到內核代價很高所以最好避免它。幸運地是，最近Linux加入了一個方便的系統調用叫sendmmsg。它允許我們在一次調用時，發送很多的數據包。那我們就一次發1024個數據包。
模擬接受者的偽代碼：

Python

fd = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
fd.bind(("0.0.0.0", 4321))
while True:
packets = [None] * 1024
fd.recvmmsg(packets, MSG_WAITFORONE)

同樣地，recvmmsg 也是相對於常見的 recv 更有效的一版系統調用。
讓我們試試吧：

Shell

sender$ ./udpsender 192.168.254.1:4321
receiver$ ./udpreceiver1 0.0.0.0:4321
0.352M pps 10.730MiB / 90.010Mb
0.284M pps 8.655MiB / 72.603Mb
0.262M pps 7.991MiB / 67.033Mb
0.199M pps 6.081MiB / 51.013Mb
0.195M pps 5.956MiB / 49.966Mb
0.199M pps 6.060MiB / 50.836Mb
0.200M pps 6.097MiB / 51.147Mb
0.197M pps 6.021MiB / 50.509Mb

測試發現，運用最簡單的方式可以實現 197k – 350k pps。看起來還不錯嘛，但不幸的是，很不穩定啊，這是因為內核在核之間交換我們的程序，那我們把進程附在 CPU 上將會有所幫助

Shell

sender$ taskset -c 1 ./udpsender 192.168.254.1:4321
receiver$ taskset -c 1 ./udpreceiver1 0.0.0.0:4321
0.362M pps 11.058MiB / 92.760Mb
0.374M pps 11.411MiB / 95.723Mb
0.369M pps 11.252MiB / 94.389Mb
0.370M pps 11.289MiB / 94.696Mb
0.365M pps 11.152MiB / 93.552Mb
0.360M pps 10.971MiB / 92.033Mb

現在內核調度器將進程運行在特定的CPU上，這提高了處理器緩存，使數據更加一致，這就是我們想要的啊！
2. 發送更多的數據包
雖然 370k pps 對於簡單的程序來說已經很不錯了，但是離我們 1Mpps 的目標還有些距離。為了接收更多，首先我們必須發送更多的包。那我們用獨立的兩個線程發送，如何呢：

Shell

sender$ taskset -c 1,2 ./udpsender
192.168.254.1:4321 192.168.254.1:4321
receiver$ taskset -c 1 ./udpreceiver1 0.0.0.0:4321
0.349M pps 10.651MiB / 89.343Mb
0.354M pps 10.815MiB / 90.724Mb
0.354M pps 10.806MiB / 90.646Mb
0.354M pps 10.811MiB / 90.690Mb

接收一端的數據沒有增加，ethtool –S 命令將顯示數據包實際上都去哪兒了：

Shell

receiver$ watch 'sudo ethtool -S eth2 |grep rx'
rx_nodesc_drop_cnt: 451.3k/s
rx-0.rx_packets: 8.0/s
rx-1.rx_packets: 0.0/s
rx-2.rx_packets: 0.0/s
rx-3.rx_packets: 0.5/s
rx-4.rx_packets: 355.2k/s
rx-5.rx_packets: 0.0/s
rx-6.rx_packets: 0.0/s
rx-7.rx_packets: 0.5/s
rx-8.rx_packets: 0.0/s
rx-9.rx_packets: 0.0/s
rx-10.rx_packets: 0.0/s

通過這些統計，NIC 顯示 4 號 RX 隊列已經成功地傳輸大約 350Kpps。rx_nodesc_drop_cnt 是 Solarflare 特有的計數器，表明NIC發送到內核未能實現發送 450kpps。
有時候，這些數據包沒有被發送的原因不是很清晰，然而在我們這種情境下卻很清楚：4號RX隊列發送數據包到4號CPU，然而4號CPU已經忙不過來了，因為它最忙也只能讀350kpps。在htop中顯示為：

多隊列 NIC 速成課程
從歷史上看，網卡擁有單個RX隊列，用於硬體和內核之間傳遞數據包。這樣的設計有一個明顯的限制，就是不可能比單個CPU處理更多的數據包。
為了利用多核系統，NIC開始支持多個RX隊列。這種設計很簡單：每個RX隊列被附到分開的CPU上，因此，把包送到所有的RX隊列網卡可以利用所有的CPU。但是又產生了另一個問題：對於一個數據包，NIC怎麼決定把它發送到哪一個RX隊列？

用 Round-robin 的方式來平衡是不能接受的，因為這有可能導致單個連接中數據包的重排序。另一種方法是使用數據包的hash值來決定RX號碼。Hash值通常由一個元組（源IP，目標IP，源port，目標port）計算而來。這確保了從一個流產生的包將最終在完全相同的RX隊列，並且不可能在一個流中重排包。
在我們的例子中，hash值可能是這樣的：

Shell

1

RX_queue_number = hash('192.168.254.30', '192.168.254.1', 65400, 4321) % number_of_queues

多隊列 hash 演算法
Hash演算法通過ethtool配置，設置如下：

Shell

receiver$ ethtool -n eth2 rx-flow-hash udp4
UDP over IPV4 flows use these fields for computing Hash flow key:
IP SA
IP DA

對於IPv4 UDP數據包，NIC將hash(源 IP,目標 IP)地址。即

Shell

1

RX_queue_number = hash('192.168.254.30', '192.168.254.1') % number_of_queues

這是相當有限的，因為它忽略了埠號。很多NIC允許自定義hash。再一次，使用ethtool我們可以選擇元組(源 IP、目標 IP、源port、目標port)生成hash值。

Shell

receiver$ ethtool -N eth2 rx-flow-hash udp4 sdfn
Cannot change RX network flow hashing options: Operation not supported

不幸地是，我們的NIC不支持自定義，我們只能選用(源 IP、目的 IP) 生成hash。
NUMA性能報告
到目前為止，我們所有的數據包都流向一個RX隊列，並且一個CPU。我們可以借這個機會為基準來衡量不同CPU的性能。在我們設置為接收方的主機上有兩個單獨的處理器，每一個都是一個不同的NUMA節點。
在我們設置中，可以將單線程接收者依附到四個CPU中的一個，四個選項如下：
另一個CPU上運行接收器，但將相同的NUMA節點作為RX隊列。性能如上面我們看到的，大約是360 kpps。
將運行接收器的同一 CPU 作為RX隊列，我們可以得到大約430 kpps。但這樣也會有很高的不穩定性，如果NIC被數據包所淹沒，性能將下降到零。
當接收器運行在HT對應的處理RX隊列的CPU之上，性能是通常的一半，大約在200kpps左右。
接收器在一個不同的NUMA節點而不是RX隊列的CPU上，性能大約是330 kpps。但是數字會不太一致。
雖然運行在一個不同的NUMA節點上有10%的代價，聽起來可能不算太壞，但隨著規模的變大，問題只會變得更糟。在一些測試中，每個核只能發出250 kpps，在所有跨NUMA測試中，這種不穩定是很糟糕。跨NUMA節點的性能損失，在更高的吞吐量上更明顯。在一次測試時，發現在一個壞掉的NUMA節點上運行接收器，性能下降有4倍。
3.多接收IP
因為我們NIC上hash演算法的限制，通過RX隊列分配數據包的唯一方法是利用多個IP地址。下面是如何將數據包發到不同的目的IP：

1

sender$ taskset -c 1,2 ./udpsender 192.168.254.1:4321 192.168.254.2:4321

ethtool 證實了數據包流向了不同的 RX 隊列：

Shell

receiver$ watch 'sudo ethtool -S eth2 |grep rx'
rx-0.rx_packets: 8.0/s
rx-1.rx_packets: 0.0/s
rx-2.rx_packets: 0.0/s
rx-3.rx_packets: 355.2k/s
rx-4.rx_packets: 0.5/s
rx-5.rx_packets: 297.0k/s
rx-6.rx_packets: 0.0/s
rx-7.rx_packets: 0.5/s
rx-8.rx_packets: 0.0/s
rx-9.rx_packets: 0.0/s
rx-10.rx_packets: 0.0/s

接收部分：

Shell

receiver$ taskset -c 1 ./udpreceiver1 0.0.0.0:4321
0.609M pps 18.599MiB / 156.019Mb
0.657M pps 20.039MiB / 168.102Mb
0.649M pps 19.803MiB / 166.120Mb

萬歲！有兩個核忙於處理RX隊列，第三運行應用程序時，可以達到大約650 kpps !
我們可以通過發送數據到三或四個RX隊列來增加這個數值，但是很快這個應用就會有另一個瓶頸。這一次rx_nodesc_drop_cnt沒有增加，但是netstat接收到了如下錯誤：

Shell

receiver$ watch 'netstat -s --udp'
Udp:
437.0k/s packets received
0.0/s packets to unknown port received.
386.9k/s packet receive errors
0.0/s packets sent
RcvbufErrors: 123.8k/s
SndbufErrors: 0
InCsumErrors: 0

這意味著雖然NIC能夠將數據包發送到內核，但是內核不能將數據包發給應用程序。在我們的case中，只能提供440 kpps，其餘的390 kpps + 123 kpps的下降是由於應用程序接收它們不夠快。
4.多線程接收
我們需要擴展接收者應用程序。最簡單的方式是利用多線程接收，但是不管用：

Shell

sender$ taskset -c 1,2 ./udpsender 192.168.254.1:4321 192.168.254.2:4321
receiver$ taskset -c 1,2 ./udpreceiver1 0.0.0.0:4321 2
0.495M pps 15.108MiB / 126.733Mb
0.480M pps 14.636MiB / 122.775Mb
0.461M pps 14.071MiB / 118.038Mb
0.486M pps 14.820MiB / 124.322Mb

接收性能較於單個線程下降了，這是由UDP接收緩沖區那邊的鎖競爭導致的。由於兩個線程使用相同的套接字描述符，它們花費過多的時間在UDP接收緩沖區的鎖競爭。這篇論文詳細描述了這一問題。
看來使用多線程從一個描述符接收，並不是最優方案。
5. SO_REUSEPORT
幸運地是，最近有一個解決方案添加到 Linux 了 —— SO_REUSEPORT 標志位（flag）。當這個標志位設置在一個套接字描述符上時，Linux將允許許多進程綁定到相同的埠，事實上，任何數量的進程將允許綁定上去，負載也會均衡分布。
有了SO_REUSEPORT，每一個進程都有一個獨立的socket描述符。因此每一個都會擁有一個專用的UDP接收緩沖區。這樣就避免了以前遇到的競爭問題：

Shell

1
2
3
4

receiver$ taskset -c 1,2,3,4 ./udpreceiver1 0.0.0.0:4321 4 1
1.114M pps 34.007MiB / 285.271Mb
1.147M pps 34.990MiB / 293.518Mb
1.126M pps 34.374MiB / 288.354Mb

現在更加喜歡了，吞吐量很不錯嘛！
更多的調查顯示還有進一步改進的空間。即使我們開始4個接收線程，負載也會不均勻地分布：

兩個進程接收了所有的工作，而另外兩個根本沒有數據包。這是因為hash沖突，但是這次是在SO_REUSEPORT層。
結束語
我做了一些進一步的測試，完全一致的RX隊列，接收線程在單個NUMA節點可以達到1.4Mpps。在不同的NUMA節點上運行接收者會導致這個數字做多下降到1Mpps。
總之，如果你想要一個完美的性能，你需要做下面這些：
確保流量均勻分布在許多RX隊列和SO_REUSEPORT進程上。在實踐中，只要有大量的連接(或流動)，負載通常是分布式的。
需要有足夠的CPU容量去從內核上獲取數據包。
To make the things harder, both RX queues and receiver processes should be on a single NUMA node.
為了使事情更加穩定，RX隊列和接收進程都應該在單個NUMA節點上。
雖然我們已經表明，在一台Linux機器上接收1Mpps在技術上是可行的，但是應用程序將不會對收到的數據包做任何實際處理——甚至連看都不看內容的流量。別太指望這樣的性能，因為對於任何實際應用並沒有太大用處。

Ⅷ 關於linux下udp廣播包

你確認你的廣播包在eth0和wlan0上都發出了嗎？我估計只在eth0上發了。
教你一個辦法確認,在linux上使用tcpmp 抓包：
tcpmp -i eth0
tcpmp -i wlan0

Ⅸ Linux系統如何阻擋UDP攻擊

UDP Server程序
1、編寫UDP Server程序的步驟
(1)使用socket()來建立一個UDP socket，第二個參數為SOCK_DGRAM。
(2)初始化sockaddr_in結構的變數，並賦值。sockaddr_in結構定義：
struct sockaddr_in {
uint8_t sin_len;
sa_family_t sin_family;
in_port_t sin_port;
struct in_addr sin_addr;
char sin_zero[8];
};
這里使用「08」作為服務程序的埠，使用「INADDR_ANY」作為綁定的IP地址即任何主機上的地址。
(3)使用bind()把上面的socket和定義的IP地址和埠綁定。這里檢查bind()是否執行成功，如果有錯誤就退出。這樣可以防止服務程序重復運行的問題。
(4)進入無限循環程序，使用recvfrom()進入等待狀態，直到接收到客戶程序發送的數據，就處理收到的數據，並向客戶程序發送反饋。這里是直接把收到的數據發回給客戶程序。

2、udpserv.c程序內容：
#include <sys/types.h>
#include <sys/socket.h>
#include <string.h>
#include <netinet/in.h>
#include <stdio.h>
#include <stdlib.h>

#define MAXLINE 80
#define SERV_PORT 8888

void do_echo(int sockfd, struct sockaddr *pcliaddr, socklen_t clilen)
{
int n;
socklen_t len;
char mesg[MAXLINE];

for(;;)
{
len = clilen;
/* waiting for receive data */
n = recvfrom(sockfd, mesg, MAXLINE, 0, pcliaddr, &len);
/* sent data back to client */
sendto(sockfd, mesg, n, 0, pcliaddr, len);
}
}

int main(void)
{
int sockfd;
struct sockaddr_in servaddr, cliaddr;

sockfd = socket(AF_INET, SOCK_DGRAM, 0); /* create a socket */

/* init servaddr */
bzero(&servaddr, sizeof(servaddr));
servaddr.sin_family = AF_INET;
servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
servaddr.sin_port = htons(SERV_PORT);

/* bind address and port to socket */
if(bind(sockfd, (struct sockaddr *)&servaddr, sizeof(servaddr)) == -1)
{
perror("bind error");
exit(1);
}

do_echo(sockfd, (struct sockaddr *)&cliaddr, sizeof(cliaddr));

return 0;
}

UDP Client程序
1、編寫UDP Client程序的步驟
(1)初始化sockaddr_in結構的變數，並賦值。這里使用「8888」作為連接的服務程序的埠，從命令行參數讀取IP地址，並且判斷IP地址是否符合要求。
(2)使用socket()來建立一個UDP socket，第二個參數為SOCK_DGRAM。
(3)使用connect()來建立與服務程序的連接。與TCP協議不同，UDP的connect()並沒有與服務程序三次握手。上面我們說了UDP是非連接的，實際上也可以是連接的。使用連接的UDP，kernel可以直接返回錯誤信息給用戶程序，從而避免由於沒有接收到數據而導致調用recvfrom()一直等待下去，看上去好像客戶程序沒有反應一樣。
(4)向服務程序發送數據，因為使用連接的UDP，所以使用write()來替代sendto()。這里的數據直接從標准輸入讀取用戶輸入。
(5)接收服務程序發回的數據，同樣使用read()來替代recvfrom()。
(6)處理接收到的數據，這里是直接輸出到標准輸出上。

2、udpclient.c程序內容：
#include <sys/types.h>
#include <sys/socket.h>
#include <string.h>
#include <netinet/in.h>
#include <stdio.h>
#include <stdlib.h>
#include <arpa/inet.h>
#include <unistd.h>

#define MAXLINE 80
#define SERV_PORT 8888

void do_cli(FILE *fp, int sockfd, struct sockaddr *pservaddr, socklen_t servlen)
{
int n;
char sendline[MAXLINE], recvline[MAXLINE + 1];

/* connect to server */
if(connect(sockfd, (struct sockaddr *)pservaddr, servlen) == -1)
{
perror("connect error");
exit(1);
}

while(fgets(sendline, MAXLINE, fp) != NULL)
{
/* read a line and send to server */
write(sockfd, sendline, strlen(sendline));
/* receive data from server */
n = read(sockfd, recvline, MAXLINE);
if(n == -1)
{
perror("read error");
exit(1);
}
recvline[n] = 0; /* terminate string */
fputs(recvline, stdout);
}
}

int main(int argc, char **argv)
{
int sockfd;
struct sockaddr_in srvaddr;

/* check args */
if(argc != 2)
{
printf("usage: udpclient <IPaddress>\n");
exit(1);
}

/* init servaddr */
bzero(&servaddr, sizeof(servaddr));
servaddr.sin_family = AF_INET;
servaddr.sin_port = htons(SERV_PORT);
if(inet_pton(AF_INET, argv[1], &servaddr.sin_addr) <= 0)
{
printf("[%s] is not a valid IPaddress\n", argv[1]);
exit(1);
}

sockfd = socket(AF_INET, SOCK_DGRAM, 0);

do_cli(stdin, sockfd, (struct sockaddr *)&servaddr, sizeof(servaddr));

return 0;
}

運行例子程序
1、編譯例子程序
使用如下命令來編譯例子程序：
gcc -Wall -o udpserv udpserv.c
gcc -Wall -o udpclient udpclient.c
編譯完成生成了udpserv和udpclient兩個可執行程序。

2、運行UDP Server程序
執行./udpserv &命令來啟動服務程序。我們可以使用netstat -ln命令來觀察服務程序綁定的IP地址和埠，部分輸出信息如下：
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:32768 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
udp 0 0 0.0.0.0:32768 0.0.0.0:*
udp 0 0 0.0.0.0:8888 0.0.0.0:*
udp 0 0 0.0.0.0:111 0.0.0.0:*
udp 0 0 0.0.0.0:882 0.0.0.0:*
可以看到udp處有「0.0.0.0:8888」的內容，說明服務程序已經正常運行，可以接收主機上任何IP地址且埠為8888的數據。
如果這時再執行./udpserv &命令，就會看到如下信息：
bind error: Address already in use
說明已經有一個服務程序在運行了。

3、運行UDP Client程序
執行./udpclient 127.0.0.1命令來啟動客戶程序，使用127.0.0.1來連接服務程序，執行效果如下：
Hello, World!
Hello, World!
this is a test
this is a test
^d
輸入的數據都正確從服務程序返回了，按ctrl+d可以結束輸入，退出程序。
如果服務程序沒有啟動，而執行客戶程序，就會看到如下信息：
$ ./udpclient 127.0.0.1
test
read error: Connection refused
說明指定的IP地址和埠沒有服務程序綁定，客戶程序就退出了。這就是使用connect()的好處，注意，這里錯誤信息是在向服務程序發送數據後收到的，而不是在調用connect()時。如果你使用tcpmp程序來抓包，會發現收到的是ICMP的錯誤信息。
參考資料：http://www.cnpaf.net/Class/UDP/0532918532729212.html

Ⅹ linux下，tcpmp -i eth0.1006 -s 0 udp -vv 抓不到包

tcpmp -i eth0.1006 -s 0 udp -vv 抓包時,可有針對IP12.13.1.111的通訊?

例如dig@ 12.13.1.111之類的.