On Thu, 2004-02-19 at 00:08, Guy Harris wrote:
> 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.
ah.
>
> > 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
That is what I thought.
>
> 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).
yes, it is.
>
> 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.
Actually, I took care of this by removing the installed libpcap and
installing a libpcap 0.8 before rebuilding my ethereal (the abuot dialog
indeed shows libpcap 0.8) but this does not seem to change anything to
the output of ethereal in promicuous mode. I believe I need to figure
out how the radio header is supposed to be transfered to userspace to
debug this.
regards,
Mathieu
--
Mathieu Lacage <mathieu.lacage@xxxxxxxxxxxxxxx>