Wireshark mailing list archives
Re: Wireshark-qt : Capture Interfaces
From: Christopher Maynard <Christopher.Maynard () gtech com>
Date: Wed, 27 Nov 2013 16:49:33 +0000 (UTC)
Guy Harris <guy@...> writes:
On Nov 26, 2013, at 7:58 AM, Christopher Maynard <Christopher.Maynard <at>
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.
There seems to be some confusion, although maybe it's just my own. I can't quite tell if the patch is being rejected or not. The patch I provided doesn't force the user to explicitly type "6" "5" "5" "3" "5". Rather, it merely displays the default value (currently 65535) in the Capture Options dialog rather than the text, "default", so that the user is made aware of the actual default snaplength value; otherwise the user is not explicitly shown what that default value is. I simply think it's better to show the actual value. The "Limit each packet to" is still insensitive until the user manually checks it and is then allowed to change the snaplength (or leave it at the default value). Anyway, the intent of the patch was simply to display the default value, rather than "default", to make the user explicitly aware of it. If the patch somehow introduces some other side-affects, then that was not my intent. - Chris ___________________________________________________________________________ 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)