Re: Implement management messages in userspace

From: Mark Wells (
Date: 2002-04-05 23:20:20 UTC

On Fri, 5 Apr 2002, Jouni Malinen wrote:

> On Fri, Apr 05, 2002 at 02:42:29PM +0400, Nil Alexandrov wrote:
> > What kind of socket are you going to use to communicate between the kernel
> > driver and a user space daemon ? Does the user space daemon have to use
> > packet inject to send a raw 802.11 frame as a reply ?
> I don't know yet (well described and justified ideas are welcome
> ;-). There may be need for sending a lot of messages (e.g., all
> received beacon frames and possibly buffered data frames for stations
> using power saving) so netlink sockets used in monitor mode 1 might
> not be the best solution. Anyway, there will be wrapper functions for
> sending and receiving this messages in kernel driver and user space
> daemon, so changing the used method should be easy. Yes, the daemon
> would use something similar for packet inject code for the replies.

If all else fails, you could set it up like the Sangoma WANPIPE T1 adapters, and have the driver generate UDP packets on some reserved port. The authentication daemon listens on that port and responds with more UDP packets--no netlink or ioctls required. It's ugly, but it works, and you can implement just about whatever functions you want. The packet payload could be a complete frame with Prism2 tx/rxdesc, if you want.

> One idea would be to use additional netdevice (e.g., wlan0ap) that
> would be set to ARPHRD_IEEE80211. This would have the bonus of
> allowing, e.g., Ethereal to be used to sniff all management frames
> without any changes to the code.. However, I would like to include

Would it also allow userspace programs to send raw frames without the driver trying to re-encapsulate them? This might require separating 802.11 encapsulation into a traditional hard_header function (and possibly splitting it off from the Prism2 driver), but then the authentication daemon, or whatever other management-frame-sending programs anyone cares to write, could send through a normal packet socket.

This archive was generated by hypermail 2.1.4.