Re: [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
--- Begin Message --- On Apr 1, 2020, at 11:51 AM, Michael Richardson wrote: > Guy Harris via tcpdump-workers wrote: >>> 5) Treat rpcap as "remote procedure call for libpcap" and put it under the the-tcpdump-group team, and put pcap under the pcapng team as per the same reason as 4). >>> >>> Ok. > >> This would require the rules in the pcapng repository Makefile to be in >> the libpcap Makefile.in. > >> Michael, would that be inconvenient to maintain? > > Yes, I think it would be a pain, but it could be done. > I certainly would not use the complex lib/* makefile if we really wanted to > do that. What about cmake side of things? It's complex, too - and I don't know whether anybody's done a CMake version of that. Would it make more sense to put the rpcap I-D into either 1) a separate team and repository or 2) another repository in the pcapng group, so that it has its own Makefile?--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
--- Begin Message --- OK, follow up. I haven't yet been able to test it, which is why I've been delaying writing about this, but these two commits[0][1], which according to these threads[2][3] are the ones fixing the timeout issue, have been applied to CentOS 7 default kernel, 3.10.0-1062.el7. It can also be seen by comparing vanilla 3.10[4] with the CentOS sources[5], diffing the files located at net/packet/af_packet.c. This *should* mean it works without the workaround. I'd like to try it, but I'm currently fighting with VirtualBox guest additions and in a metered connection (I have no home connection and my country is in quarantine), so I'm being rather careful on my data usage. Now, if this is deemed insufficient, I have a test in mind that I may as well have early feedback on, with the following setup: - libpcap with the workaround removed; - vanilla and CentOS' kernels alternated; - a 2MiB packet ring; - a 64kiB block size and snaplen; - timeout of 8ms; - injection to a virtual interface at 1 packet every 20ms; - a simple application that reads and do nothing on its peer. I think that should give as a buffer small enough and a frequency low enough to fill the buffer and result in observable packet loss. Does it make sense? Any suggestions or criticisms to the setup? Is it necessary? [0]: https://github.com/torvalds/linux/commit/da413eec729dae5dcb150e2eb34c5e7e5e4e1b49 [1]: https://github.com/torvalds/linux/commit/41a50d621a321b4c15273cc1b5ed41437f4acdfb [2]: https://www.mail-archive.com/netdev@vger.kernel.org/msg163532.html [3]: https://www.mail-archive.com/search?l=net...@vger.kernel.org&q=subject:%22TPACKET_V3+timeout+bug%5C%3F%22&o=newest&f=1 [4]: https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.10.tar.xz [5]: http://vault.centos.org/7.7.1908/os/Source/SPackages/kernel-3.10.0-1062.el7.src.rpm --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Legacy Linux kernel support
--- Begin Message --- On Apr 1, 2020, at 4:14 PM, Mario Rugiero via tcpdump-workers wrote: > I haven't yet been able to test it, which is why I've been delaying > writing about this, > but these two commits[0][1], which according to these threads[2][3] > are the ones fixing > the timeout issue, have been applied to CentOS 7 default kernel, > 3.10.0-1062.el7. So this is about the mmapped PF_PACKET bug where it delivers an empty buffer when it times out, and does *not* wake up the reader when a buffer is delivered, causing empty buffers to pile up unread, and forcing libpcap to periodically poll the mmapped ring buffer to see if anything was delivered without notification? If so, then this: https://github.com/torvalds/linux/commit/da413eec729dae5dcb150e2eb34c5e7e5e4e1b49 i.e. [0] fixes it, by doing wakeups when a buffer is *delivered* (rather than when a packet is *added* to the buffer, which is pointless) and this: https://github.com/torvalds/linux/commit/41a50d621a321b4c15273cc1b5ed41437f4acdfb i.e. [1] arranges that empty buffers aren't delivered when a timeout occurs. has_broken_tpacket_v3() is checking whether the kernel has that fix or not, based on the kernel version number; to quote the comment in front of 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 having a fixed version; that may really mean * it has *no* version. so it checks for versions prior to 3.19. That routine is used in set_poll_timeout(); if it returns "true" (a non-zero value), meaning TPACKET_V3 has the bug, the poll() done to wait for packets to arrive is given a non-zero timeout, so that the socket is checked for packets even if no wakeup is delivered by the socket, to drain the empty buffers. > It can also be seen by comparing vanilla 3.10[4] with the CentOS > sources[5], diffing > the files located at net/packet/af_packet.c. > This *should* mean it works without the workaround. It should work without the workaround... ...on systems with the fix. *NOT* all versions of the Linux kernel with TPACKET_V3 necessarily have the fix. Version 3.19 and later have the fix; earlier versions have it *only* if whoever built the kernel (e.g., the distribution developer) backported the fix. So we can't assume the workaround is unnecessary, and remove it, unless we either 1) require a 3.19 or later kernel if we're going to use TPACKET_V3 or 2) *somehow* can detect kernels to which the fix was backported. --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
