View Issue Details

IDProjectCategoryView StatusLast Update
0016139CentOS-7libpcappublic2019-10-14 07:22
Status newResolutionopen 
PlatformallOScentosOS Version
Product Version7.6.1810 
Target VersionFixed in Version 
Summary0016139: pcap_next got packets slowly by TPACKET_V3 in libpcap-1.9.0
DescriptionI was trying to forward packets using libpcap,while the sending part had not been implemented .
        But I encountered the problem that pcap_next got packets too slowly.
        I wrote a simple pcap_next demo that printed the time when a packet arrived the driver layer ( or the card ). Please referring the Attach.
        Some **strace** log showed me that the pcap_next executed slowly.
        Here : the time when a packet arrives the driver is called T1
               the time when poll calledd by pcap_next return is called T2
               T [= T2 - T1] is 100ms level that is bigger than time of packet handing(should less than 1ms I think).
        Strace Log :
        08:38:16.206208 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) <1.023316>
        08:38:17.229644 ||||T2||||| stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3545, ...}) = 0 <0.000011>
        08:38:17.229748 write(1, "08:38:17,037555 ||||T1|||| len:98\n", 2308:38:17,037555 len:98
        ) = 23 <0.000012>
        08:38:17.229797 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3545, ...}) = 0 <0.000008>
        08:38:17.229843 write(1, "08:38:17,037581 len:98\n", 2308:38:17,037581 len:98
        ) = 23 <0.000011>
        08:38:17.229885 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) <1.023611>
        08:38:18.253626 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3545, ...}) = 0 <0.000011>
        08:38:18.253729 write(1, "08:38:18,061540 len:98\n", 2308:38:18,061540 len:98
        ) = 23 <0.000013>

        After the libpcap source code reveiwed , I got some conclusion.
        - now libpcap is using TPACKET_V3 as the default linux_read protocol
            which keeps the poll blocking forever (timeout is -1) and let kernel returns the packets to userland by kernel selected timeout or the fulling of the kernel buffer.
        - while TPACKET_V1 or TPACKET_V2 leaves the timeout to user app by pcap_open_live and pcap_set_timeout.
            So the poll will return qucikly even there are some buffer coming from kernel.
            I used TPACKET_V2 as my test base ,T is 1ms level.
        Emmm.. I still has some questions
        1. why TPACKET_V2 or TPACKET_V1 is too quickly ?
        2. why TPACKET_V3 is too slowly ? this is crucial !!
        3. If I want to figure out the 2 questions above, what should I read [code document ...] , or You can explain it to me
        ps : pcap_next means some common pcap capture funcion ,like pcap_next_ex or pcap_loop.
        Looking for your reply.


Steps To Reproduce1. run pcap demo
2. strace -tt -T -f -s 1024 -p [pid]
3. check the times
TagsNo tags attached.




2019-06-03 13:45


sniffex_next.c (20,142 bytes)


2019-10-14 07:22

reporter   ~0035458

Not a bug. The TPACKET_V3 is unsupported by libpcap until Linux kernel 3.19.

Libpcap does *not* support TPACKET_V3 in kernel 3.10 because there is a bug in Linux TPACKET_V3 before kernel version 3.19.
All CentOS 7 kernels are 3.10. E.g. CentOS 7.6.1810 kernel is 3.10.0-957, and CentOS 7.7.1908 kernel is 3.10.0-1062.

Comments from linux-pcap.c explain it
* Some versions of TPACKET_V3 have annoying bugs/misfeatures
* around which we have to work. Determine if we have those
* problems or not.
* 3.19 is the first release with a fixed version of
* TPACKET_V3. We treat anything before that as
* not haveing a fixed version; that may really mean
* it has *no* version.

Issue History

Date Modified Username Field Change
2019-06-03 13:45 songshuaishuai New Issue
2019-06-03 13:45 songshuaishuai File Added: sniffex_next.c
2019-10-14 07:22 harri Note Added: 0035458