On Wed, 22 May 2002, Bill Studenmund wrote: > > >From [EMAIL PROTECTED] Wed May 22 17:41:21 2002 > Date: Wed, 22 May 2002 14:12:20 -0700 > From: Guy Harris <[EMAIL PROTECTED]> > To: Michael Richardson <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: [tcpdump-workers] Bill Studenmund: Re: 802.11 libpcap support > > (Is Bill Studenmund on tcpdump-workers?)
Nope. :-) > On Wed, May 22, 2002 at 03:26:56PM -0400, Michael Richardson wrote: > > >From [EMAIL PROTECTED] Wed May 22 > 14:56:38 2002 > > Date: Wed, 22 May 2002 11:50:39 -0700 (PDT) > > From: Bill Studenmund <[EMAIL PROTECTED]> > > To: Atsushi Onoe <[EMAIL PROTECTED]>, Curt Sampson <[EMAIL PROTECTED]> > > cc: <[EMAIL PROTECTED]> > > Subject: Re: 802.11 libpcap support > > ... > > > Normally, interfaces build mbufs, pass them to bpf, and pass them to the > > rest of the kernel. 802.11 is different in that there are multiple frame > > types (802.3, 802.11, and driver-dependent ones). > > Well, I don't think 802.11 itself has any notion of those types; I think > the fact that 802.3 is involved at all is just a consequence of the > cards providing an option to hide the 802.11-ness of the network from > the driver. > > Is it the case, with any 802.11 cards, that they can supply to the > driver enough information to supply packets with just raw 802.11 headers > *and* packets with just 802.3 headers to different clients of the > driver? >From looking at the code, I think so. The NetBSD wi driver looks like it builds different packet types based on different information in the status information it receives. I'd assume the FreeBSD and OpenBSD ones do the same. So it seems to know if it's gotten a management frame, an RFC 1042 encoded frame, or a bridge-tunnel encoded packet, or not. For "not" it seems to engage 802.3 mode. > > We might also make "frame types" that are subsets. For instance I think it > > would be interesting for tcpdump to show 802.3 frames and 802.11 frames > > that aren't 802.3 encapsulations. The advantage I see over just getting > > 802.11 frames is that we will still have to make an 802.3 frame for the > > kernel, so why take an input 802.11/802.3 frame and make an 802.11 frame > > for bpf and a different 802.3 frame for the kernel? > > The answer to the "why" is "so that we don't have to modify tcpdump and > Ethereal to know about 'mixed mode' captures where some frames are raw > 802.11 frames and some frames are 802.3 frames, and so that if somebody > *cares* about the 802.11 header for LLC frames they can see it". Oh, part of my message got dropped. Yes, if something WANTS 802.11 frames, give it to them. > I'd certainly not be inclined to have Ethereal run the interface in that > mode; I'd run it in "raw 802.11" mode if somebody wants 802.11 traffic > or wants the 802.11 headers and "pretend-Ethernet" (802.3) mode if > somebody just cares about LLC traffic and doesn't care about the 802.11 > headers. Depends on what you want to do. I think most apps would probably be happy with 802.3 mode. Not because they are broken and that's all they can deal with (well, there is that, but programs can be fixed), but because if you're interested in host to host communications, the 802.3 frames give you all you need. Mainly as the 802.3 frames are all that makes it out of the wireless cloud (i.e. past an AP). Also, I should note the app I have in mind to explain some of my ideas. :-) I would like to make a daemon that opens a bpf and sits there, listening for management frames. Mainly to see what base stations are around. I'd like this as I have a laptop that moves around, and needs different WEP keys in different places. When this daemon notices the base station is different, it would start changing system settings. I'd like this to not impact system performance much, and so wanted to take advantage of the fact there are already different code paths in the kernel. For this task, I know that I'm not interested in frames that encapsulate 802.3, so why bother making an 802.11 frame in that case. :-) > > > Those things that refuse to work on non-Ethernet interfaces (rarpd > > > and the like) will have to be modified to use this ioctl after > > > opening the interface (but before checking the media type), but > > > that's not a big or difficult change. > > > > But why? Why make them pick a different packet type? > > I don't particularly care which is the default - I'd have no problem > with the default being pseudo-Ethernet frames. > > However, I'd make libpcap either > > 1) always choose "raw 802.11" > > or > > 2) have an API to select the frame type - preferably an API that > offers an interface that could be used with other network > types with this problem, if they exist, rather than something > 802.11-specific - and offer tcpdump and Ethereal command-line > options and, in Ethereal, GUI options to choose the frame > type. I'd vote for 2). :-) >From the kernel point of view, I envisioned an ioctl that would report the different encoding types available. libpcap or ethereal could turn this into a menu of options, so the user could pick what to capture. > > > > And there are no room to deliver useful information > > > > such as RSSI or encoded rate, though it doesn't belong to actual header. > > > > > > Is this the "extra" stuff that some chipsets return (such as signal > > > quality or whatever)? tcpdump.org just added more types: DLT_PRISM_HEADER > > > and DLT_AIRONET_HEADER. > > > > Not sure, but I don't think so. > > I *do* think so - Ethereal's "packet-prism.c" dissects, in the > chipset-dependent header for Prism II interfaces, fields with names such > as "channel", "rssi", "sq", "signal", "noise", and "rate", and, in the > FreeBSD "if_an.c" driver, the "struct an_rxframe" which includes the > header supplied by the Aironet driver if you're running in > "device-dependent header mode" includes fields with names like > "an_rx_signal_strength", "an_rx_rate", and "an_rx_chan". I think we're on a different page. > > If it's after the 802.11 header, it should > > be covered by the 802.11 spec. As I understand chipset-specific things, > > they are all before the 802.11 header. > > Yes, they are, in both of those cases. That's what I was trying to say, not that the different (driver-specific) header types don't include these factors. All this goop is *before* the 802.11 frame. So even if we didn't do the 802.3/802.11 stuff above, we have 802.11 vs. chip-dependent goop difference. :-) > One possibility would be to have DLT_IEEE802_RADIO_HEADER, or something > such as that, and provide a "standard" header for all drivers to supply; > however, as there are already drivers (the Prism II drivers for Linux > and the Aironet driver for FreeBSD) that supply the raw chip headers, > libpcap, tcpdump, and Ethereal will need to handle those anyway. (They > don't handle all of them now, but in my Copious Free Time(TM) I want to > set up an 802.11 testbench at home, with a multi-booting notebook and a > variety of 802.11 cards, and try to get libpcap, tcpdump, and Ethereal > to cope with that.) I think DLT_IEEE802_RADIO_HEADER would be cool. Take care, Bill - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
