Hide Forgot
Created attachment 1319198 [details] Example data for libpcap bug Description of problem: If libpcap1.8 encounters a pcap file with the snaplen specified as larger than the default value of 262144 bytes, it refuses to open it. In earlier versions these files would open without any issue. This should not be a fatal error, as it's for instance a common use case for traffic capture using memory-mapped files. Version-Release number of selected component (if applicable): libpcap-1.8.1-3.fc26.x86_64 How reproducible: Create a pcap file with snaplen > 262144 (example file in the attached tarball). Attempt to tcpreplay or editcap or mergecap the file. Under earlier versions of the library, it will work just fine. Under 1.8 it will fail. Steps to Reproduce: 1. tar xvfj example.tar.bz2 2. tcpreplay -i <interface-name> -x 100.0 bad-pcap-replay.pcap Actual results: Failed: Error opening pcap file: invalid file capture length 33554392, bigger than maximum of 262144 Expected results: Actual: 73337 packets (7790535 bytes) sent in 3.01 seconds. Rated: 2588217.5 bps, 19.75 Mbps, 24364.45 pps Statistics for network device: ens6f1 Attempted packets: 73337 Successful packets: 73337 Failed packets: 0 Retried packets (ENOBUFS): 0 Retried packets (EAGAIN): 0 Additional info: Googling suggests that there was a documentation change in 2015 to change the default value from 64K to 256K.
Hello, thanks for your report. I did a quick check of the libpcap source code and this seems like a work for upstream, because they specify the maximum value directly in the source code: $ grep -B 20 MAXIMUM_SNAPLEN pcap-int.h * Maximum snapshot length. * * Somewhat arbitrary, but chosen to be: * * 1) big enough for maximum-size Linux loopback packets (65549) * and some USB packets captured with USBPcap: * * http://desowin.org/usbpcap/ * * (> 131072, < 262144) * * and * * 2) small enough not to cause attempts to allocate huge amounts of * memory; some applications might use the snapshot length in a * savefile header to control the size of the buffer they allocate, * so a size of, say, 2^31-1 might not work well. * * We don't enforce this in pcap_set_snaplen(), but we use it internally. */ #define MAXIMUM_SNAPLEN 262144 But there is definitely a regression between the old version and the new one. I can reproduce this issue using RHEL(CentOS)6: user @ RHEL 6.8:~ $ rpm -q libpcap libpcap-1.4.0-4.20130826git2dbcaa1.el6.x86_64 user @ RHEL 6.8:~ $ rpm -q tcpdump tcpdump-4.0.0-11.20090921gitdf3cb4.2.el6.x86_64 user @ RHEL 6.8:~ $ tcpdump -r bad-pcap-replay.pcap | tail reading from file bad-pcap-replay.pcap, link-type EN10MB (Ethernet) 17:39:59.883324 IP 10.18.6.3.54513 > 239.194.5.3.21003: UDP, length 20 17:39:59.896614 IP 10.18.6.5.42707 > 239.194.5.4.21004: UDP, length 20 17:39:59.912502 IP 10.128.2.254 > reserved: ip-proto-253 46 17:39:59.931083 IP 10.18.6.7.49860 > 239.194.5.5.21005: UDP, length 20 17:39:59.933315 IP 10.18.6.3.54513 > 239.194.5.3.21003: UDP, length 20 17:39:59.946679 IP 10.18.6.5.42707 > 239.194.5.4.21004: UDP, length 20 17:39:59.962518 IP 10.128.2.254 > reserved: ip-proto-253 46 17:39:59.981088 IP 10.18.6.7.49860 > 239.194.5.5.21005: UDP, length 20 17:39:59.983450 IP 10.18.6.3.54513 > 239.194.5.3.21003: UDP, length 20 17:39:59.996432 IP 10.18.6.5.42707 > 239.194.5.4.21004: UDP, length 20 and Fedora 26: user @ f26 $ rpm -q libpcap libpcap-1.8.1-3.fc26.x86_64 user @ f26 $ rpm -q tcpdump tcpdump-4.9.0-2.fc26.x86_64 user @ f26 $ tcpdump -r bad-pcap-replay.pcap tcpdump: invalid file capture length 33554392, bigger than maximum of 262144 user @ f26 $
It does seem a rather arbitrary / low limit, especially given that for instance the various sysctl net.core & net.ipv4 rmem limits typically max out at 16777216 or so.
This also breaks Bustle (which records logs in pcap format), because the maximum D-Bus message size is 128MiB. libpcap master now supports varying the maximum snaplen based on the link-layer type field, with one special-case for DLT_DBUS (and all other link types using MAXIMUM_SNAPLEN). Sadly these are not in any release yet: https://github.com/the-tcpdump-group/libpcap/commit/1a6b088a88886eac782008f37a7219a32b86da45 https://github.com/the-tcpdump-group/libpcap/commit/42c3865d71a3d3ad3fc61ee382ad3b5113d40552
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Fixed in current release of libpcap(1.9.0).