On Oct 31, 2003, at 10:14 AM, Brian Fundakowski Feldman wrote:
Since pcap(3) has recently grown the ability to select from multiple
available data link types on some platforms, it's very useful for
Ethereal
to support switching to a non-default capture format. I've tested this
on
FreeBSD, which means that the HAVE_PCAP_DATALINK_VAL_TO_NAME part
remains
untested but present for a system which might have it.
Just get the current CVS version of libpcap, install it, temporarily
move the libpcap library in "/usr/lib" out of the way (I think I've had
to do that to keep it from linking with that version), and try it.
After you select an interface, you can check the "Change _data link
type" box
The check box is extraneous; I've gotten rid of it.
and then pull down to select a data link type
I've made it an option menu, using names from Wiretap (mapping libpcap
DLT_ values to Wiretap encapsulation values and then to names), so it
says "Ethernet" instead of "EN10MB" and "Token Ring" rather than
"IEEE802", etc..
DLT_ values Wiretap doesn't know about aren't supported by Ethereal, so
those are shown as DLT_ names (or numerical values), and marked as
"(not supported)" and grayed out.
The drop-down box isn't available (and the check box unchecks itself)
if
the current value of the interface entry can't be used to look up a
set of
data link types.
I made it gray out the label and option menu if the list of link-layer
types is empty (which would be the case if the interface name
corresponded to an interface that can't be opened, or if, for some
other reason, you can't get the list.
Currently, if you have "pcap_list_datalinks()" but not
"pcap_datalink_val_to_name()", it uses "DLT n" as the name, and accepts
numbers as input to "-y"; any system such as that has a botched libpcap
(I added the mapping APIs to libpcap at the same time that I checked in
the get datalink list/set datalink APIs from David Young/Jason Thorpe;
I don't know why they didn't pick them all up - file a PR on that).
I'll look at doing the same workaround that tcpdump does (supplies its
own versions of them).
I also cleaned up various other things ("aclocal.m4" isn't a source
file, it's generated from "acinclude.m4"; we can do the checks for
those routines with AC_CHECK_FUNCS; "-L" should also be supported; "-y"
wasn't supported in Tethereal; the documentation wasn't updated; etc.).