Mathieu Lacage said:
> I have been trying recently to use ethereal 0.10.0 on my 2.4.23 linux
> box with a madwifi driver (which suposedly supports the prism header
> data-reporting thing). I have tried to get ethereal to dump and display
> the prism header of each packet but failed to do so.
>
> As far as I can tell by asking a few BSD users and reading the ethereal
> and libpcap code, it looks like I should be able to select the
> link-layer type from the UI when starting a capture in the drop-down
> menu below the interface selection.
The BSD users are probably unfamiliar with Linux. The ability to select a
link-layer type in libpcap (which is what Ethereal uses to implement
link-layer type selection) was originally put in to use a BSD-specific
feature (first appeared in NetBSD-current, now also present in FreeBSD 5.2
and later, not present in other BSDs at this point) that allows a driver
to register *multiple* types of link-layer types it can supply and to let
different BPF devices use different types.
> However, this drop-down menu is
> always greyed out which indicates (by reading the code for this dialog
> in ethereal) that the network interfaces I am trying to dump from
> support only one type of link-layer dump. Further code reading in
> libpcap seems to show that the pcap-linux.c file is the culprit: it sets
> dlt_count to zero which implies no link-layer change capability.
>
> So, I wonder if Linux users can actually use this feature.
Linux doesn't support a mechanism equivalent to the link-layer selection
mechanism in BPF in NetBSD-current and FreeBSD 5.2 and later, so the
link-layer type selection doesn't work. That's why dlt_count is set to 0
in pcap-linux.c
The way that Linux drivers let you see 802.11 or
802.11-plus-radio-information headers depends on the driver. Some drivers
might supply that information only when running in "monitor mode" or
"rfmon mode"; a quick look at the madwifi driver suggests that it's one of
those drivers, so you won't get the radio header information unless you
capture in monitor mode (which would probably mean capturing passively, as
I think most if not all 802.11 cards cannot actively participate on a
network at the same time that they're running in monitor mode).
The madwifi driver supplies, in monitor mode, an ARPHRD_ type of
ARPHRD_IEEE80211_PRISM. That ARPHRD_ value is *NOT* supported by any
libpcap releases prior to 0.7.2. If your Linux distribution comes with a
pre-0.7.2 version of libpcap, then Ethereal will probably be linked with
it, and will therefore be unable to capture in monitor mode on an Atheros
interface; you would have to get a newer version of libpcap.