On Wed, May 22, 2002 at 06:27:04PM -0700, Bill Studenmund wrote:
> 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.
Yes, they probably would; that's fine with me. Those apps can run the
interface in "just show me the 802.3 frames" mode (I think you can
select that now, with at least some Linux drivers and the FreeBSD
Aironet driver, but it might be nice to let an app control that).
> 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. :-)
Presumably, in that mode, the LLC frames wouldn't even be delivered to
the BPF device, so they wouldn't be made into 802.11 frames.
Perhaps there should be, at minimum, modes such as
send only LLC frames to the BPF as 802.3 frames;
send only management frames to the BPF as raw 802.11 frames;
send all frames to the BPF as 802.11 frames;
and possibly also a flag to indicate whether beacons should be sent to
the BPF device.
> I think DLT_IEEE802_RADIO_HEADER would be cool.
Yup. I don't know whether there's any chip-dependent stuff that's
available with some chips but not others, and that's of interest, so
there might still be DLT_ values - and, presumably, corresponding BPF
modes - for the "give me the raw chip stuff" mode, but if we can get
most of the interesting stuff into a common "radio header" (Wireless
Sniffer and Airopeek applications both seem to stuff the data rate,
channel, and signal level/percentage into their captures; I don't know
if that exhausts the set of "radio header" values common to multiple
devices), that might simplify things.
-
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
