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 <[EMAIL PROTECTED]> _______________________________________________ Ethereal-users mailing list [EMAIL PROTECTED] http://www.ethereal.com/mailman/listinfo/ethereal-users
