Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1486022 - libpcap1.8 fails to open pcap files if the snaplen is above the default value of 262144 bytes
Summary: libpcap1.8 fails to open pcap files if the snaplen is above the default value...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: libpcap
Version: 26
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Michal Ruprich
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1450443
TreeView+ depends on / blocked
 
Reported: 2017-08-28 18:31 UTC by Staffan Tjernstrom
Modified: 2019-01-19 13:03 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-29 12:24:03 UTC
Type: Bug


Attachments (Terms of Use)
Example data for libpcap bug (1.40 MB, application/x-bzip)
2017-08-28 18:31 UTC, Staffan Tjernstrom
no flags Details

Description Staffan Tjernstrom 2017-08-28 18:31:44 UTC
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.

Comment 1 Martin Sehnoutka 2017-09-04 10:39:00 UTC
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 $

Comment 2 Staffan Tjernstrom 2017-09-11 14:03:11 UTC
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.

Comment 3 Will Thompson 2017-11-10 09:01:19 UTC
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

Comment 4 Fedora End Of Life 2018-05-03 08:04:19 UTC
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.

Comment 5 Fedora End Of Life 2018-05-29 12:24:03 UTC
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.

Comment 6 Michal Ruprich 2019-01-19 13:03:55 UTC
Fixed in current release of libpcap(1.9.0).


Note You need to log in before you can comment on or make changes to this bug.