From: Jouni Malinen (jkmaline_at_cc.hut.fi)
Date: 2002-04-11 17:36:47 UTC
On Sat, Apr 06, 2002 at 01:35:29PM -0800, Mark Wells wrote:
> On Sat, 6 Apr 2002, Jouni Malinen wrote:
> > Yes, user space programs would send (and receive) raw 802.11
> > frames. This wlan0ap interface with ARPHRD_IEEE80211
> Just to clarify, is the wlan0ap interface suitable for normal traffic?
Not really. Current version sends only management related frames into wlan0ap and all data frames are delivered to wlan0. In addition, Linux kernel does not apparenly know how to make 802.11 headers for TX packets. I have implemented needed build/parse functions for a test version and I can send normal IP packets using wlan0ap, but since it does not receive normal data frames, it is not really usable, nor meant, for normal traffic.
As a side note, it might be interesting to implement full 802.11 layer support to Linux kernel in general (i.e., move the functions I mentioned into a more proper place). That would make it possible to use them (if needed for some special purpose) instead of "masquerading" wireless LAN interfaces using only Ethernet headers. One could also use frame format that would include Prism2 RX header (i.e., including signal levels). That might be useful, e.g., for user space Mobile IP implementations since they would have efficient access to signal levels.
> I don't know if that's necessary. The management frames themselves could
> serve this purpose (though this may be contrary to your goal of not having
> to parse management frames through the driver). Is there any case in
> which the driver should add a station even though the daemon hasn't sent
> an association response for that station, or vice versa?
Yes, they could, but indeed, that is against my goal of removing extra stuff from the driver. I do not see any need for the driver to record any data from a station before that station has associated (with the user space daemon).
-- Jouni Malinen PGP id EFC895FA