Wireshark mailing list archives
Re: Wireshark-qt : Capture Interfaces
From: Guy Harris <guy () alum mit edu>
Date: Tue, 26 Nov 2013 13:53:22 -0800
On Nov 26, 2013, at 7:58 AM, Christopher Maynard <Christopher.Maynard () gtech com> wrote:
Maybe the snaplen column should display the actual snaplen value instead of “default”? The GTK version does this too, which I’m also not a fan of, as “default” doesn’t actually tell you anything.
In the best of all possible worlds, libpcap - and the pcap file format - would have allowed a value of 0 to mean "unlimited", and we wouldn't have to worry about code reading pcap files allocating buffers based on the snaplen and never changing the buffer size. Unfortunately, "allocating buffers based on the snaplen and never changing the buffer size" is exactly what most versions of libpcap do, and have done going back at least to libpcap 0.7 and probably all the way back to 0.4, at least. This means that a value of 0 in the capture file for "unlimited" would produce files that can't be read by many versions of libpcap, and thus by programs linked with those versions, and a value of 2^32-1 or 2^31-1 would cause libpcap to try to allocate a *huge* chunk of memory, almost certainly failing in 32-bit code. In addition, libpcap has traditionally treated a captured length > 65535 as an indication that the record for the packet was corrupt. So this means we can't *truly* have an "unlimited" snapshot length. Nevertheless, I definitely think the UI should provide a way to easily tell Wireshark "I don't want packets cut short", so they shouldn't have to explicitly type "6" "5" "5" "3" "5" to get that; there should be a check box to request "largest possible snaplen". I might also be tempted to display that as "none" - or as the "has snaplen" checkbox not being checked and the large value used for that purpose displayed but grayed out. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Wireshark-qt : Capture Interfaces Alexis La Goutte (Nov 26)
- Re: Wireshark-qt : Capture Interfaces Graham Bloice (Nov 26)
- Re: Wireshark-qt : Capture Interfaces Anders Broman (Nov 26)
- Re: Wireshark-qt : Capture Interfaces Guy Harris (Nov 26)
- Re: Wireshark-qt : Capture Interfaces Christopher Maynard (Nov 26)
- Re: Wireshark-qt : Capture Interfaces Guy Harris (Nov 26)
- Re: Wireshark-qt : Capture Interfaces Guy Harris (Nov 26)
- Re: Wireshark-qt : Capture Interfaces Guy Harris (Nov 26)
- Re: Wireshark-qt : Capture Interfaces Christopher Maynard (Nov 27)
- Re: Wireshark-qt : Capture Interfaces Guy Harris (Nov 26)
- Re: Wireshark-qt : Capture Interfaces Guy Harris (Nov 26)
- Re: Wireshark-qt : Capture Interfaces Guy Harris (Nov 26)
- Re: Wireshark-qt : Capture Interfaces Graham Bloice (Nov 26)