Bug 1486022
| Summary: | libpcap1.8 fails to open pcap files if the snaplen is above the default value of 262144 bytes | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Staffan Tjernstrom <stjernstrom> | ||||
| Component: | libpcap | Assignee: | Michal Ruprich <mruprich> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 26 | CC: | gilwooden, jsynacek, luhliari, mruprich, msehnout, msekleta, thozza, will | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2018-05-29 12:24:03 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1450443 | ||||||
| Attachments: |
|
||||||
|
Description
Staffan Tjernstrom
2017-08-28 18:31:44 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 $ 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). |