linux下怎么抓包_百度知道
linux下怎么抓包
答题抽奖
首次认真答题后
即可获得3次抽奖机会，100%中奖。
tcpdump，就可以用这个抓包了，具体使用 tcpdump -vvv -nn -port 80 -w /tmp/file，你也可以用man tcpdump 查看此命令的具体使用
采纳率：83%
来自团队：
为您推荐：
其他类似问题
您可能关注的内容
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。当前位置:&&操作系统>
高速的网络抓包库PF_ring介绍及编译安装
&&&&发布时间:&&
&&&&本文导语:&1. PF_RING介绍
PF_RING是Luca Deri发明的提高内核处理数据包效率，并兼顾应用程序的补丁，如Libpcap和TCPDUMP等，以及一些辅助性程序（如ntop查看并分析网络流量等）。PF_RING是一种新型的网络socket，它可以极大的改进包捕获的速...
1. PF_介绍
PF_RING是Luca Deri发明的提高处理数据包，并兼顾应用程序的补丁，如和等，以及一些辅助性程序（如ntop查看并网络流量等）。PF_RING是一种新型的网络，它可以极大的改进包捕获的。并且有如下特征：1） 可以用于 2.6.18以上的内核；2） 4的pf_ring可以直接于内核，不需要给内核打补丁；3） PF_RING可以进行包捕获的加速；4） 支持使用商用网络适配器的10 GB的包过滤5） 设备驱动无关（使用支持NAPI的（网卡）来获得最好的）；6） 基于内核的包捕获和采样；7） Lipcap支持与基于pcap的应用程序的无缝；8） 可以指定上百个头过滤到中；9） 检查，以至于只有符合过滤的包才能通过;10）PF_RING的可以用于增强包和内容过滤；11）可以在混杂（经过网卡的全部可以被捕获到）；2.
编译安装PF_RING之前需要原来的网卡驱动，卸载之前使用命令查看当前网卡的类型和驱动版本。# ethtool -i ethx# lsmod |
e1000e# rmmod e1000e
此处为e1000e驱动注：如果使用卸载驱动会造成不能，务必现场操作。2.1.
解压缩PF_RING安装包，进入到下编译和安装内核补丁。#
-zxf PF_RING.4.7.0.tar.#
PF_RING.4.7.0/kernel# #
内核安装需要 &PF_RINGPATH&/kernel/pf_ring. [_=0|1|2][_num_=x][enable__=1|0][enable__defrag=1|0][quick_mode=1|0]
# sodu insmod pf_ring.ko transparent_mode=1当PF_RING激活时，会创建///pf_ring目录，使用命令查看设置：# cat /proc/net/pf_ring/注1：为了编译PF_RING内核模块，你需要安装Linux内核的（或者内核）。2.2.
编译用户PF_RING库进入到用户空间库/下，编译和安装。# cd ../userland/lib# ./# make# sodu make install如果需要使用libpcap抓包分析，请卸载之前安装的libpcap，然后进入/userland/libpcap-xxx-ring/目录下、编译和安装驱动。#
查看安装的libpcap，如果有libpcap则强制卸载# rpm -e libpcap --nodefs
# cd ../libpcap# ./configure# make# sudo make install注：为了使用pf_ring的优点，请使用pf_ring使能的libpcap重新编译应用。进入到userland/examples目录编译例子。# cd &PF_RING &/userland/examples# make# ./pfcount -i eth0
捕获eth0网口的报文注：使用/intel/ixgbe下的驱动（支持的ixgbe驱动的网卡）+DNA驱动可以达到线速，PF_RING模块必须在DNA驱动之前加载。2.3.
编译网卡的驱动进入到drivers目录下，根据ethtool -i ethx命令查看的网卡类型和驱动进入指定的目录进行编译和安装。# cd ../../ drivers/intel/e1000e/e.10a/# make# sodu make install开始安装驱动，进入/lib//&-&/kernel/net目录，可以看到有pf_ring目录，进入到该目录下进行PF_RING模块的安装。# sodu insmod pf_ring.ko transparent_mode=1安装网卡驱动，进入到目录lib/modules/&redhat-version&/kernel/drivers/net下进行网卡驱动安装。# sodu insmod e1000e.ko# sodu modprobe e1000e
(只能载入/lib/modules/&kernel ver&/中模块)安装完毕，使用命令查看驱动是否安装成功，如果成功的话，可以看到：# dmesg[_RING]…… 。pf_ring会安装一个类型为27的簇，可以使用sock（pf_ring, sock_raw,0）打开一个socket，使用libpcap的朋友不需要程序，需要重新编译，的时候请加上libpfring。启动PF_RING模块，修改/etc/modprobe.#
/etc/modprobe.conf在文件的尾部增加一行 modprobe pf_ring重启后内核会自动加载pf_ring模块，modprobe只能加载/lib/modules下的模块。3. 使用使用用户空间中的PF_RING库来编写代码，并且使用用户空间中的libpfring.a和libpcap.a编译代码就可以使用PF_RING来提高包捕获的性能。4. 在 8.04上的PF_RING编译安装过程1）以 root做以下操作。2）安装mkinitrdrpm安装包 ://ayo.freshrpms//linux/5//rpms./# rpm -ivh --nodeps mkinitrd-5.0.32-1.i386.rpm (注意，这里一定要--nodeps，下同)3）安装Kernel，如果/usr/src下没有的话，运行#
install linux--2.6.24则linux-source-2.6.24.tar.将位于/usr/src下4）下载PF_RINGcd /usr/src
://svn.ntop.org/svn/ntop//PF_RING/5）修改PF_RING下的mkpatch.(1)查看内核版本yu@yu-:~$
–aLinux zp 2.6.24-16- #1
Oct 14 23:05:12
/Linux(2)修改=linux-source #识别.tar.bz2后缀VERSION=${VERSION:-2}PATCHLEVEL=${PATCHLEVEL:-6}SUBLEVEL=${SUBLEVEL:-24}(3)执行 sh ./mkpatch.sh则在/usr//src下好的内核目录6）编译内核(1) 安装必要的包- install kernel- libncurses5-dev
-essential(2) 拷贝当前配置cd /usr/local/src/... //-`uname -r` ./.config(3) 配置make menuconfiga.
(1000Mbit) and enable NAPI-Support by selecting ‘y’ on
(3x ESC) and
and Networking . Make sure that PF_RING
are enabled(4) 编译make-kpkg cleanfakeroot make-kpkg -- --=pfring.1.0 kernel_[注]：本步骤也可以如下执行：#cd /usr/local/src/...#cp /boot/config-`uname -r` ./.config#make#make modules_install#make install7）制作镜像文件制作initrd文件 当我们编译了一个新的内核，也不要忘了为我们的设备做一个新的initrd： ： mkinitrd 文件名 内核的目录名示例： #mkinitrd initrd-2.6.24.3. 2.6.24.3initrd-2.6.24.3.img文件是自己任意取的，但最好对应自己的内核版本号，会生成在/boot目录下。 2.6.24.3是在/lib/modules中的目录名，对应内核的版本8）修改/boot//.文件，增加如下内容： Ubuntu_RING 8.04, kernel 2.6.24.3 ( mode)root (hd0,0)kernel /boot/vmlinuz-2.6.24.3 root==719d2825-29dd-48ab-84fe-1ee7f0891fc6 ro singleinitrd /boot/initrd.img-2.6.24.39）重启系统，启动时选择新内核进入10）进入目录/usr/src/PF_RING/userland/lib，执行make，然后执行如下拷贝：#cp libpfring.a /usr/local/lib#cp pfring.h /usr/local/加载kernel ，取决于内核版本2.4.x insmod ring.o2.6.x insmod ring.ko我的系统操作如下#insmod /lib/modules/2.6.24.3/kernel/net/ring/ring.ko11）回到/usr/src/PF_RING/userland/目录，执行make编译，若出现如下，依次按解决：A、configure错误Configure: : your operating ’s
is insufficient to
libpcap解决办法：# apt-get install B、make错误1:
not found解决办法：# apt-get install C、make错误2
to ‘_’解决办法：# apt-get install libpcap-dev到此为止，工程可以顺利编译！
您可能感兴趣的文章:
本站(WWW.169IT.COM)旨在分享和传播互联网科技相关的资讯和技术，将尽最大努力为读者提供更好的信息聚合和浏览方式。本站(WWW.169IT.COM)站内文章除注明原创外，均为转载,整理或搜集自网络.欢迎任何形式的转载，转载请注明出处.转载请注明：文章转载自:[]本文标题:
相关文章推荐:
特别声明:169IT网站部分信息来自互联网,如果侵犯您的权利,请及时告知,本站将立即删除！
(C)9IT.COM,E-mail:www_169it_com#163.com(请将#改为@)Hi，欢迎来到嵌入式培训高端品牌 - 华清远见教育集团，专注嵌入式工程师培养15年！
全国免费报名电话：400-611-6270
当前位置: >
> Linux下编写网络抓包程序
Linux下编写网络抓包程序
时间：作者：华清远见
某些时候，我们需要在应用程序中捕获网卡收到的所有数据包并进行分析。为了实现这一功能，应用程序需要借助底层系统的支持。当今主流的操作系统都提供了一个很强大的功能：允许应用程序访问数据链路层。
类UNIX操作系统上提供了三种不同的方式访问数据链路层，分别是BSD的BSD分组过滤器(BPF)、SVR4的数据链路提供者接口(DLPI)和Linux的SOCK_PACKET接口。幸运的是，程序员不需要了解这些不同接口的细节，直接使用Libpcap函数库就可以。
Libpcap是一个提供了针对网络数据包捕获系统的高层接口的开源函数库。其作用是提供独立于平台的应用程序接口，以消除程序中针对不同操作系统所包含的数据包捕获代码模块。这样以来，就解决了程序移植性的问题，有利于提高开发的效率。
Libpcap运行于大多数类UNIX操作系统上，完整的文档和源码可以从tcpdump的官方网站上获得: http://www.tcpdump.org 其Windows版本 Winpcap可已从 http://www.winpcap.org获取。下面介绍如何使用Libpcap来捕获数据包
char *pcap_lookupdev(char *errbuf);&
&&&&&&&&功能：查找用于捕获数据包的缺省设备
&&&&&&&&errbuf ：错误时保存出错信息
&&&&&&&&返回值：成功时返回设备名称；出错时返回NULL
pcap_t *pcap_open_live(const char *device, int snaplen, int promisc, int to_ms, char *errbuf);
&&&&&&&&功能：打开用于捕获数据包的网络设备
&&&&&&&&device：设备名称
&&&&&&&&snaplen：要捕获的数据包的大字节数
&&&&&&&&prosmic：网络设备工作模式(0表示非混杂模式，其他值表示混杂模式)
&&&&&&&&to_ms： 从内核空间复制数据前等待的时间
&&&&&&&&err_buf：错误时保存出错信息
&&&&&&&&返回值：成功时返回pcap_t类型的接口描述符(句柄)；出错时返回NULL
const u_char *pcap_next(pcap_t *p, struct pcap_pkthdr *h);&
&&&&&&&&功能：捕获下一个数据包
&&&&&&&&p：接口描述符
&&&&&&&&h：捕获的数据包的信息&
&&&&&&&&返回值：成功时返回指向捕获的数据的指针；出错时返回NULL
typedef void (*pcap_handler)(u_char *user, const struct pcap_pkthdr *h, const u_char *bytes);&
&&&&&&&&const u_char *pcap_loop(pcap_t *p, int cnt, pcap_handler callback, u_char *user);&
&&&&&&&&功能： 捕获下一个数据包
&&&&&&&&cnt ：要捕获的数据包的个数
&&&&&&&&callback ：捕获到数据包时执行的回调函数
&&&&&&&&user：传递给回调函数的参数
&&&&&&&&返回值：成功时返回0；出错时返回-1
int pcap_compile(pcap_t *p, struct bpf_program *fp, char *str, int optimize, bpf_u_int32 netmask);&
&&&&&&&&功能：创建过滤器
&&&&&&&&p ：接口描述符
&&&&&&&&fp：指向保存过滤器的结构体的指针
&&&&&&&&str：要转化的过滤规则
&&&&&&&&optimize： 过滤器是否要优化
&&&&&&&&netmask：网络掩码
&&&&&&&&返回值：成功时返回0；出错时返回-1
int pcap_setfilter(pcap_t *p, struct bpf_program *fp);&
&&&&&&&&功能： 安装过滤器
&&&&&&&&p：接口描述符
&&&&&&&&fp：指向包含过滤器的结构体的指针
&&&&&&&&返回值：成功时返回0；出错时返回-1
以下实例代码实现捕获并显示3个ARP包
&&&&&&&&#include &stdio.h&
&&&&&&&&#include &stdlib.h&
&&&&&&&&#include &string.h&
&&&&&&&&#include &pcap.h&
#define MAXBYTES2CAPTURE 2048
void ProcessPacket(u_char *arg, const struct pcap_pkthdr *pkthdr, const u_char *packet)
&&&&&&&&&&&&&&&&int i = 0, *counter = (int *)
&&&&&&&&printf(&Packet Count : %d\n&, ++(*counter));
&&&&&&&&&&&&&&&&printf(&Received Packet Size: %d\n&, pkthdr-&len);
&&&&&&&&&&&&&&&&printf(&Payload:\n&);
&&&&&&&&&&&&&&&&for (i=0; i&pkthdr-& i++)
&&&&&&&&&&&&&&&&{
&&&&&&&&&&&&&&&&&&&&&&&&printf(&%02x &, (unsigned int)packet[i]);
&&&&&&&&&&&&&&&&if ( (i%16 = = 15 && i != 0) || (i = = pkthdr-&len -1))
&&&&&&&&&&&&&&&&&&&&&&&&{
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&printf(&\n&);
&&&&&&&&&&&&&&&&&&&&&&&&}
&&&&&&&&&&&&&&&&}
&&&&&&&&&&&&&&&&printf(&\n\n************************************************\n&);
&&&&&&&&&&&&&&&&
int main(int argc, char *argv[])
&&&&&&&&&&&&&&&&int i = 0, count = 0;
&&&&&&&&&&&&&&&&pcap_t *descr = NULL;
&&&&&&&&&&&&&&&&char errbuf[PCAP_ERRBUF_SIZE], *device = NULL;
&&&&&&&&&&&&&&&&bpf_u_int32 netaddr = 0, mask = 0;
&&&&&&&&&&&&&&&&struct bpf_
&&&&&&&&memset(errbuf, 0, sizeof(errbuf));
&&&&&&&&if (argc != 2)
&&&&&&&&&&&&&&&&{
&&&&&&&&&&&&&&&&&&&&&&&&device = pcap_lookupdev(errbuf);
&&&&&&&&&&&&&&&&}
&&&&&&&&&&&&&&&&else
&&&&&&&&&&&&&&&&{
&&&&&&&&&&&&&&&&&&&&&&&&device = argv[1];
&&&&&&&&&&&&&&&&}
&&&&&&&&&&&&&&&&printf(&Try to open device %s\n&, device);
&&&&&&&&if((descr = pcap_open_live(device, MAXBYTES2CAPTURE, 1, 0, errbuf)) = =NULL)
&&&&&&&&&&&&&&&&{
&&&&&&&&&&&&&&&&&&&&&&&&printf(&error : %s\n&, errbuf);
&&&&&&&&&&&&&&&&&&&&&&&&exit(-1);
&&&&&&&&&&&&&&&&}
&&&&&&&&&&&&&&&&pcap_lookupnet(device, &netaddr, &mask, errbuf);
&&&&&&&&if (pcap_compile(descr, &filter, &arp and ether host 00:0c:29:b7:f6:33&,0, mask) & 0)
&&&&&&&&&&&&&&&&{
&&&&&&&&&&&&&&&&&&&&&&&&printf(&pcap_compile error\n&);
&&&&&&&&&&&&&&&&&&&&&&&&exit(-1);
&&&&&&&&&&&&&&&&}
&&&&&&&&&&&&&&&&pcap_setfilter(descr, &filter);
&&&&&&&&&&&&&&&&pcap_loop(descr, 3, ProcessPacket, (u_char *)&count);
&&&&&&&&&&&&&&&&return 0;
下一篇：没有了
评论列表（网友评论仅供网友表达个人看法，并不表明本站同意其观点或证实其描述）
学院新动态热门搜索：
& & 查看压缩包源码
软件大小：
下载次数：
上传用户：
下载地址：
"pcap_stats: %s", pcap_strerror(errno));
return -1;
* On systems where the PACKET_STATISTICS "getsockopt()" argument
* is not supported on PF_PACKET sockets:
* "ps_recv" counts only packets that *passed* the filter,
* not packets that didn't pass the filter.
It does not
* count packets dropped because we ran out of buffer
* "ps_drop" is not supported.
* "ps_recv" doesn't include packets not yet read from
* the kernel by libpcap.
* We maintain the count of packets processed by libpcap in
* "md.packets_read", for reasons described in the comment
* at the end of pcap_read_packet().
We have no idea how many
* packets were dropped.
stats->ps_recv = handle->md.packets_
stats->ps_drop = 0;
* Description string for the "any" device.
static const char any_descr[] = "Pseudo-device that captures on all interfaces";
pcap_platform_finddevs(pcap_if_t **alldevsp, char *errbuf)
if (pcap_add_if(alldevsp, "any", 0, any_descr, errbuf) < 0)
return (-1);
#ifdef HAVE_DAG_API
if (dag_platform_finddevs(alldevsp, errbuf) < 0)
return (-1);
#endif /* HAVE_DAG_API */
#ifdef HAVE_SEPTEL_API
if (septel_platform_finddevs(alldevsp, errbuf) errbuf, "setfilter: No filter specified",
sizeof(handle->errbuf));
return -1;
/* Make our private copy of the filter */
if (install_bpf_program(handle, filter) md.use_bpf = 0;
/* Install kernel level filter if possible */
#ifdef SO_ATTACH_FILTER
#ifdef USHRT_MAX
if (handle->fcode.bf_len > USHRT_MAX) {
* fcode.len is an unsigned short for current kernel.
* I have yet to see BPF-Code with that much
* instructions but still it is possible. So for the
* sake of correctness I added this check.
fprintf(stderr, "Warning: Filter too complex for kernel\n");
fcode.filter = NULL;
can_filter_in_kernel = 0;
#endif /* USHRT_MAX */
* Oh joy, the Linux kernel uses struct sock_fprog instead
* of struct bpf_program and of course the length field is
* of different size. Pointed out by Sebastian
* Oh, and we also need to fix it up so that all "ret"
* instructions with non-zero operands have 65535 as the
* operand, and so that, if we're in cooked mode, all
* memory-reference instructions use special magic offsets
* in references to the link-layer header and assume that
* the link-layer payload begins at 0; "fix_program()"
* will do that.
switch (fix_program(handle, &fcode)) {
* F just quit.
* (The "default" case shouldn' we
* return -1 for that reason.)
return -1;
* The program performed checks that we can't make
* work in the kernel.
can_filter_in_kernel = 0;
* We have a filter that'll work in the kernel.
can_filter_in_kernel = 1;
if (can_filter_in_kernel) {
if ((err = set_kernel_filter(handle, &fcode)) == 0)
/* Installation succeded - using kernel filter. */
handle->md.use_bpf = 1;
else if (err == -1) /* Non-fatal error */
* Print a warning if we weren't able to install
* the filter for a reason other than "this kernel
* isn't configured to support socket filters.
if (errno != ENOPROTOOPT && errno != EOPNOTSUPP) {
fprintf(stderr,
"Warning: Kernel filter failed: %s\n",
pcap_strerror(errno));
* If we're not using the kernel filter, get rid of any kernel
* filter that might've been there before, e.g. because the
* previous filter could work in the kernel, or because some other
* code attached a filter to the socket by some means other than
* calling "pcap_setfilter()".
Otherwise, the kernel filter may
* filter out packets that would pass the new userland filter.
if (!handle->md.use_bpf)
reset_kernel_filter(handle);
* Free up the copy of the filter that was made by "fix_program()".
if (fcode.filter != NULL)
free(fcode.filter);
if (err == -2)
/* Fatal error */
return -1;
#endif /* SO_ATTACH_FILTER */
* Set direction flag: Which packets do we accept on a forwarding
* single device? IN, OUT or both?
static int
pcap_setdirection_linux(pcap_t *handle, pcap_direction_t d)
#ifdef HAVE_PF_PACKET_SOCKETS
if (!handle->md.sock_packet) {
handle->direction =
* We're not using PF_PACKET sockets, so we can't determine
* the direction of the packet.
snprintf(handle->errbuf, sizeof(handle->errbuf),
"Setting direction is not supported on SOCK_PACKET sockets");
return -1;
Linux uses the ARP hardware type to identify the type of an
interface. pcap uses the DLT_xxx constants for this. This
function takes a pointer to a "pcap_t", and an ARPHRD_xxx
constant, as arguments, and sets "handle->linktype" to the
appropriate DLT_XXX constant and sets "handle->offset" to
the appropriate value (to make "handle->offset" plus link-layer
header length be a multiple of 4, so that the link-layer payload
will be aligned on a 4-byte boundary when capturing packets).
(If the offset isn't set here, it'll be 0; add code as appropriate
for cases where it shouldn't be 0.)
If "cooked_ok" is non-zero, we can use DLT_LINUX_SLL and capture
* otherwise, we can't use cooked mode, so we have
to pick some type that works in raw mode, or fail.
Sets the link type to -1 if unable to map the type.
static void map_arphrd_to_dlt(pcap_t *handle, int arptype, int cooked_ok)
switch (arptype) {
case ARPHRD_ETHER:
* This is (presumably) a real E give it a
* link-layer-type list with DLT_EN10MB and DLT_DOCSIS, so
* that an application can let you choose it, in case you're
* capturing DOCSIS traffic that a Cisco Cable Modem
* Termination System is putting out onto an Ethernet (it
* doesn't put an Ethernet header onto the wire, it puts raw
* DOCSIS frames out on the wire inside the low-level
* Ethernet framing).
* XXX - are there any sorts of "fake Ethernet" that have
* ARPHRD_ETHER but that *shouldn't offer DLT_DOCSIS as
* a Cisco CMTS won't put traffic onto it or get traffic
* bridged onto it?
ISDN is handled in "live_open_new()",
* as we fall back
are there any
handle->dlt_list = (u_int *) malloc(sizeof(u_int) * 2);
* If that fails, just leave the list empty.
if (handle->dlt_list != NULL) {
handle->dlt_list[0] = DLT_EN10MB;
handle->dlt_list[1] = DLT_DOCSIS;
handle->dlt_count = 2;
/* FALLTHROUGH */
case ARPHRD_METRICOM:
case ARPHRD_LOOPBACK:
handle->linktype = DLT_EN10MB;
handle->offset = 2;
case ARPHRD_EETHER:
handle->linktype = DLT_EN3MB;
case ARPHRD_AX25:
handle->linktype = DLT_AX25;
case ARPHRD_PRONET:
handle->linktype = DLT_PRONET;
case ARPHRD_CHAOS:
handle->linktype = DLT_CHAOS;
#ifndef ARPHRD_IEEE802_TR
#define ARPHRD_IEEE802_TR 800 /* From Linux 2.4 */
case ARPHRD_IEEE802_TR:
case ARPHRD_IEEE802:
handle->linktype = DLT_IEEE802;
handle->offset = 2;
case ARPHRD_ARCNET:
handle->linktype = DLT_ARCNET_LINUX;
#ifndef ARPHRD_FDDI /* From Linux 2.2.13 */
#define ARPHRD_FDDI 774
case ARPHRD_FDDI:
handle->linktype = DLT_FDDI;
handle->offset = 3;
#ifndef ARPHRD_ATM
/* FIXME: How to #include this? */
#define ARPHRD_ATM 19
case ARPHRD_ATM:
* The Classical IP implementation in ATM for Linux
* supports both what RFC 1483 calls "LLC Encapsulation",
* in which each packet has an LLC header, possibly
* with a SNAP header as well, prepended to it, and
* what RFC 1483 calls "VC Based Multiplexing", in which
* different virtual circuits carry different network
* layer protocols, and no header is prepended to packets.
* They both have an ARPHRD_ type of ARPHRD_ATM, so
* you can't use the ARPHRD_ type to find out whether
* captured packets will have an LLC header, and,
* while there's a socket ioctl to *set* the encapsulation
* type, there's no ioctl to *get* the encapsulation type.
* This means that
* programs that dissect Linux Classical IP frames
* would have to check for an LLC header and,
* depending on whether they see one or not, dissect
* the frame as LLC-encapsulated or as raw IP (I
* don't know whether there's any traffic other than
* IP that would show up on the socket, or whether
* there's any support for IPv6 in the Linux
* Classical IP code);
* filter expressions would have to compile into
* code that checks for an LLC header and does
* the right thing.
* Both of those are a nuisance - and, at least on systems
* that support PF_PACKET sockets, we don't have to put
instead, we can just capture
* in cooked mode.
That's what we'll do, if we can.
* Otherwise, we'll just fail.
if (cooked_ok)
handle->linktype = DLT_LINUX_SLL;
handle->linktype = -1;
#ifndef ARPHRD_IEEE80211
/* From Linux 2.4.6 */
#define ARPHRD_IEEE
case ARPHRD_IEEE80211:
handle->linktype = DLT_IEEE802_11;
#ifndef ARPHRD_IEEE80211_PRISM
/* From Linux 2.4.18 */
#define ARPHRD_IEEE80211_PRISM 802
case ARPHRD_IEEE80211_PRISM:
handle->linktype = DLT_PRISM_HEADER;
#ifndef ARPHRD_IEEE80211_RADIOTAP /* new */
#define ARPHRD_IEEE80211_RADIOTAP 803
case ARPHRD_IEEE80211_RADIOTAP:
handle->linktype = DLT_IEEE802_11_RADIO;
case ARPHRD_PPP:
* Some PPP code in the kernel supplies no link-layer
* header whatsoever to PF_PACKET other PPP
* code supplies PPP link-layer headers ("syncppp.c");
* some PPP code might supply random link-layer
* headers (PPP over ISDN - there's code in Ethereal,
* for example, to cope with PPP-over-ISDN captures
* with which the Ethereal developers have had to cope,
* heuristically trying to determine which of the
* oddball link-layer headers particular packets have).
* As such, we just punt, and run all PPP interfaces
* in cooked mode, otherwise, we just treat
* it as DLT_RAW, for now - if somebody needs to capture,
* on a 2.0[.x] kernel, on PPP devices that supply a
* link-layer header, they'll have to add code here to
* map to the appropriate DLT_ type (possibly adding a
* new DLT_ type, if necessary).
if (cooked_ok)
handle->linktype = DLT_LINUX_SLL;
* XXX - handle ISDN types here?
We can't fall
* back on cooked sockets, so we'd have to
* figure out from the device name what type of
* link-layer encapsulation it's using, and map
* that to an appropriate DLT_ value, meaning
* we'd map "isdnN" devices to DLT_RAW (they
* supply raw IP packets with no link-layer
* header) and "isdY" devices to a new DLT_I4L_IP
* type that has only an Ethernet packet type as
* a link-layer header.
* But sometimes we seem to get random crap
* in the link-layer header when capturing on
* ISDN devices....
handle->linktype = DLT_RAW;
#ifndef ARPHRD_CISCO
#define ARPHRD_CISCO 513 /* previously ARPHRD_HDLC */
case ARPHRD_CISCO:
handle->linktype = DLT_C_HDLC;
/* Not sure if this is correct for all tunnels, but it
* works for CIPE */
case ARPHRD_TUNNEL:
#ifndef ARPHRD_SIT
#define ARPHRD_SIT 776 /* From Linux 2.2.13 */
case ARPHRD_SIT:
case ARPHRD_CSLIP:
case ARPHRD_SLIP6:
case ARPHRD_CSLIP6:
case ARPHRD_ADAPT:
case ARPHRD_SLIP:
#ifndef ARPHRD_RAWHDLC
#define ARPHRD_RAWHDLC 518
case ARPHRD_RAWHDLC:
#ifndef ARPHRD_DLCI
#define ARPHRD_DLCI 15
case ARPHRD_DLCI:
* XXX - should some of those be mapped to DLT_LINUX_SLL
* instead?
Should we just map all of them to DLT_LINUX_SLL?
handle->linktype = DLT_RAW;
#ifndef ARPHRD_FRAD
#define ARPHRD_FRAD 770