| Bug ID |
8808
|
| Summary |
64KB packet limit
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
SVN
|
| Hardware |
All
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Normal
|
| Priority |
Low
|
| Component |
Capture file support (libwiretap)
|
| Assignee |
bugzilla-admin@wireshark.org
|
| Reporter |
desowin@gmail.com
|
Created attachment 10996 [details]
Remove orig_len check. This is not the final solution.
Build Information:
wireshark 1.11.0 (SVN Rev 49965 from master)
Copyright 1998-2013 Gerald Combs <gerald@wireshark.org> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with GTK+ 2.24.18, with Cairo 1.12.14, with Pango 1.32.5,
with
GLib 2.36.1, with libpcap, with libz 1.2.8, with POSIX capabilities (Linux),
with libnl 1, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.1, without Python,
with GnuTLS 2.12.23, with Gcrypt 1.5.0, with MIT Kerberos, with GeoIP, without
PortAudio, without AirPcap.
1
Running on Linux 3.8.7, with locale en_US.utf8, with libpcap version 1.4.0,
with
libz 1.2.8, GnuTLS 2.12.23, Gcrypt 1.5.0.
AMD A4-3305M APU with Radeon(tm) HD Graphics
Built using gcc 4.7.3.
--
Wireshark errors out with "The capture file appears to be damaged or corrupt.
(pcap: File has 65563-byte packet, bigger than maximum of 65535)" whilst
analyzing some USBPcap files. USBPcap packets contain complete data from I/O
Request Packet containing the USB Request Block and actually some drivers send
IRPs with such big data buffers.
USBPcap does limit the packets to 64KB by default. You can use commandline
switch (-s) to increase it. The quick solution is to not check the orig_len
field against WTAP_MAX_PACKET_SIZE.
I think the incl_len should get checked against the snaplen from global pcap
header and not the WTAP_MAX_PACKET_SIZE.
You are receiving this mail because:
- You are watching all bug changes.
