[FYI] hostapd with mac80211 progress

Johannes Berg johannes
Wed Dec 12 18:23:34 PST 2007


Hi,

I thought I'd write another update because I'm much further than last
time, I've been able to remove the management interface.

With my "[RFC] mac80211: clean up frame receive handling" patch and a
few more patches like "[PATCH] mac80211: fix header ops" I've been able
to implement hostapd without the management interface.

That requires a whole bunch of patches which, as always, you can find on
http://johannes.sipsolutions.net/patches/. I will be sending them out as
I feel appropriate. There are, contrary to what some think, reasons I
haven't done so yet. For example, I just found a bug with multicast keys
in my hostapd key patches.

The only ioctls I now still need are:

020-prism2-ioctl-bridge-packets.patch
021-prism2-ioctl-8021x.patch
022-hostapd-ioctl-hw-features.patch

However, a few more things are missing:
 * set_rate_sets <*>
 * set_channel_flag <*>
 * set_regulatory_domain <*>
 * set_tx_queue_params
 * set_cts_protect
 * set_preamble
 * set_short_slot_time
 * sta_clear_stats

hostapd works without these, but obviously not actually correctly (it
advertises WMM without being able to set queue parameters etc). The
items marked with <*> depend on the regulatory stuff we're going to
implement in the kernel.

The big thing with removing the management interface was the receive
frame handling cleanup that also made EAPOL frames show up on the
respective data interface rather than requiring the management
interface. This means that we can now use a monitor interface for
getting the management frames (and TX status callbacks) instead of the
management interface. Michael Wu is working on optimising this by adding
a "cooked" monitor mode that doesn't show data frames that were handled
by other virtual interfaces, but right now that's only an optimisation.
It will matter again when 802.11w is implemented where "cooked" will
give us decrypted frames, but w/o 802.11w management frames are always
sent in clear (and never fragmented in either case) so the regular
monitor interfaces work fine.

Also, using the monitor interfaces here means that we'll again send
deauth/disassoc frames when receiving class three frames from
not-associated stations as soon as the cooked monitor is used instead of
the socket filter. That still needs to be fixed up to work with PS-poll
packets, but that's a SMOP.

Other things to do include:
 * key threshold notifications
 * Michael MIC failure notifications (disable TKIP for now)

Ron, have you started working on traffic flows for hostapd yet? If so, I
guess I should set up a git tree or simply push all my hostapd patches
to Jouni (and send fixes as I find the bugs) because otherwise we're
going to produce many conflicts, most of my changes are quite large.
OTOH, I guess the only thing you need to do in the nl80211 driver stuff
is add support for flows to the station management. Let me know how you
want to proceed.

All, any help with hostapd would be much appreciated. In case I forget
to publish my hostapd patches though, ping me rather than working from
older ones. Any patches older than this mail are too old.

johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20071213/f2c2e4a5/attachment.pgp 



More information about the Hostap mailing list