On Wed, 22 May 2002, Atsushi Onoe wrote:

> 1. How to select raw 802.11 frame or ethernet compatible mode?

I agree that the that the pseudo-interface thing is a bit ugly.

It seems to me that making the default to be raw 802.11 mode, and having
an explicit BIOCSDLT ioctol to let you turn on "Ethernet emulation" for
that particular BPF device is the cleanest way to go.

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.

> 2. The bpf packet format assumed by tcpdump is not so good.
>
> The current implmentation of tcpdump assumes 802.11 header immediately
> followed by SNAP header and data (e.g. IP) packet.  But it confuses
> libpcap to filter ip/tcp/... because 802.11 header is defined as
> variable length.

How does the tcpdump.org libpcap/tcpdump deal with this?

> 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.

Making generic versions of this available for those programs that can't
handle the chipset-specific ones could be done with BIOCSDLT again.

Here's a bit of a thought on how you might deal with this, actually.
(But I've not thought about it much, so it may be rubbish.) You
could start giving out the most generic DLT translation (i.e.,
Ethernet in this case) so that older programs don't break. But you
could add an ioctl to see what DLT the current device is translating
from. Programs in the know can query that and, if they know that
lower-level DLT, use BIOCSDLT to set the translation to that one.
Then they repeat the process until they get down to a DLT they
don't know. So tcpdump might do this:

    1. open wi0;
    2. ioctl: get current DLT; returns DLT_EN10MB
    3. ioctl: get what we're translating from; returns DLT_IEEE802_11
       We know how to interpret DLT_IEEE802_11.
    4. ioctl: set current DLT to DLT_IEEE802_11

       [Now we repeat steps 2-4 until we find something we don't know:]

    5. ioctl: get current DLT; returns DLT_IEEE802_11
    6. ioctl: get what we're translating from; returns DLT_PRISM_HEADER
       We don't know how to interpret DLT_PRISM_HEADER, so we leave
       it at DLT_IEEE802_11.

> 3. How to handle WEP frame?  deliver undecrypted? or decrypted?
> Most of the firmware automatically decrypt if WEP ICV matches.

I'd say just deliver what the card gives you, since it's the card that
does the decryption. If a user wants to (and is able to) put his card in
a non-decrypt mode, presumably he has a userland program that can deal
with it, and is going to be a bit careful about what else is using that
interface at the same time. It would be a specialized enough application
that I don't think that bpf or libpcap should deal with it.

> 4. How to select possible monitor mode?
>
> There can be various receiving mode.
> 	By frame type:
> 		- data frame only
> 		- data frame and management frame
> 		- all frames including control frame (e.g. ACK)

Just return everything that's reasonable for the particular
translation layer, I'd say. For 802.11-translated-to-Ethernet the
management fames make no sense, do they? But if you are doing 802.11
directly, you should know enough to deal with the management frames
(if only by filtering them).

> 	By address:
> 		- destined to the node only (non-promiscuous)

Doesn't the promiscous setting of the interface takes care of this?

> 		- all destination within connected bss
> 		- any packet in specified channel

I would say that if you are joined to a BSS, you should return just
the packets in it, and if you are not, return any packets. Then
the user can configure the interface appropriately with an external
utility, such as wiconfig. (Or knowing programs can do the appropriate
ioctls directly--I get we might want some sort of generic 802.11
manipulation interface for this.)

> Also note some of the firmware (such as aironet) need to stop transmitter
> to enter some of the monitor modes.  So normal TCP/IP communications
> must be disabled to monitor frames.

Again, I'd say let the user configure the interface explicitly to
do this (separate from tcpdump), or let the non-tcpdup program do
whatever it needs to. Again, I reckon anybody using the really
disruptive modes (all-channel scan, or even non-joined-to-BSS mode)
is a) not going to be using that interface for IP communication
anyway, and b) knows what he's doing, and is willing to do tweaking
outside of tcpdump.

Thanks for explaining the problems to me.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC