Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Patch for Bug771, link layer header type selection

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Wed, 27 Dec 2006 12:06:58 -0800
Florent.Drouin@xxxxxxxxxxxxxxxxx wrote:

Here is a patch for Bug 771 (repost).
It solves the problem of datalink header selection, when the interface has
more than one.
And now, when we reopen the dialog window, the datalink submenu is restored
to the last used value.

It appears that the last used value is global; should it be global, or should it be per-adapter?

In addition, should it be saved in the "recent" file, so that it persists across Wireshark sessions?

Or, at least if it's per-adapter, should it be saved in, for example, a per-host "recent" file, so that if you have a home directory on a file server, which you use with multiple machines, the last used value for "en0" or "eth0" or... on one machine is used on that machine but not on other machines?

During the writting of the patch, I discovered that dumpcap can be launched
with the interface name only, if no action is performed to select the
link-layer type.
Example:
lt-dumpcap -i eth0 -Z
instead of
lt-dumpcap -i eth0 -y EN10MB -Z

tcpdump can be run without a "-y" flag, either; it uses the default link-layer type. The same is true of tshark, and the only difference in Wireshark is that, with your change, the default link-layer type is the one that was last used within the session if you've already done one capture.

I.e., dumpcap's behavior isn't a bug, it's a feature.

Speaking of defaults, for 802.11 adapters, the default should probably be the 802.11 header, if available - or, if 802.11 and 802.11+radio is available, the radio header should perhaps be selected, if libpcap can handle it (not all versions of libpcap work with radio headers).