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之类的.