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
> This is a bit more complicated then that
> In HT aggregation we have more then 4 queues. In theory you have TID
> X receiving address queues. Number of TIDs is 16 yet for the
> aggregation on 8 are relevant.Let say your AP supports 32 connected
> stations so you need 256 queues for to keep packets in order. Of
> course in HW you keep smaller number..etc.
Hmm. I'm not too familiar with the 802.11e stuff that is really getting
used now in 802.11n
> Ron will send RX AMSDU aggregation patches at the beginning of the
> next week, then he will work on TX side. I suggest that in that
> context we can open the discussion how to solve the QoS queues and
> Qdisc cleanly.
Sounds good.
johannes
> We have mostly configuration patches - (enhanced hostap_ioctls.h) and
> some minor changes in hostapd flows that we would like to rebase over
> your changes to nl80211/mac80211 and hostap respectively. We can start
> with 11n Association flows patches.
Sounds good.
> It would be great if you can setup git repository. Unfortunately it's
> rather complicated to export one from Intel.
Not sure if I really want to, maybe we can convince Jouni to take
patches early if they don't break anything else?
johannes
> 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.
>
I take this question instead of Ron.
We have mostly configuration patches - (enhanced hostap_ioctls.h) and
some minor changes in hostapd flows that we would like to rebase over
your changes to nl80211/mac80211 and hostap respectively. We can start
with 11n Association flows patches.
It would be great if you can setup git repository. Unfortunately it's
rather complicated to export one from Intel.
Thanks
Tomas
> 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
>
> _______________________________________________
> HostAP mailing list
> [email protected]
> http://lists.shmoo.com/mailman/listinfo/hostap
>
>
> * set_tx_queue_params
Actually, I wonder if any of that should be implemented in the wireless
classifier. Well, what I'm thinking is that we should make mac80211
provide multiqueue netdevs with four queues and then write a new 802.11
classifier that is attached in the sch_fifo qdisc. Then, the queue
parameters could be configured with the 802.11 qdisc.
Tomas, you said you might look into the QoS stuff, any ideas?
johannes
> We have mostly configuration patches - (enhanced hostap_ioctls.h) and
> some minor changes in hostapd flows that we would like to rebase over
> your changes to nl80211/mac80211 and hostap respectively. We can start
> with 11n Association flows patches.
Oh btw, will you be publishing driver updates to support AP mode in
iwlwifi? You must have them anyway if you're working on this and I'd
love have a second driver capable of AP mode in the kernel.
johannes
On Dec 14, 2007 1:17 PM, Johannes Berg <[email protected]> wrote:
> > * set_tx_queue_params
>
> Actually, I wonder if any of that should be implemented in the wireless
> classifier. Well, what I'm thinking is that we should make mac80211
> provide multiqueue netdevs with four queues and then write a new 802.11
> classifier that is attached in the sch_fifo qdisc. Then, the queue
> parameters could be configured with the 802.11 qdisc.
>
> Tomas, you said you might look into the QoS stuff, any ideas?
>
This is a bit more complicated then that
In HT aggregation we have more then 4 queues. In theory you have TID
X receiving address queues. Number of TIDs is 16 yet for the
aggregation on 8 are relevant.Let say your AP supports 32 connected
stations so you need 256 queues for to keep packets in order. Of
course in HW you keep smaller number..etc.
Ron will send RX AMSDU aggregation patches at the beginning of the
next week, then he will work on TX side. I suggest that in that
context we can open the discussion how to solve the QoS queues and
Qdisc cleanly.
Tomas
> johannes
>
> I'm fine with patches that are either specific to driver_devicescape.c
> or are clearly not breaking other driver wrappers (or core hostapd
> functionality) as long as they are somehow in sync with a commonly used
> Linux kernel tree. At some point, I would like to limit this to proper
> kernel releases, but for the time being, any development tree should be
> fine taken into account the current state of the AP support.
Great. I think all the remaining patches I have are specific to
driver_nl80211.c (I think I sent you the rename patch, didn't I?) I'll
send them to you as appropriate, I think the beaconing/station and eapol
stuff is pretty well fleshed out right now.
johannes
On Dec 13, 2007 7:36 PM, Johannes Berg <[email protected]> wrote:
>Not sure if I really want to, maybe we can convince Jouni to take
>patches early if they don't break anything else?
That's probably the best option as more people are looking there so
we've might receive more exposure and get fast response.
> Oh btw, will you be publishing driver updates to support AP mode in
> iwlwifi? You must have them anyway if you're working on this and I'd
> love have a second driver capable of AP mode in the kernel.
We have frozen the AP stack before you've removed management interface
so first we have to rebase it to the current code, but it's being done
it will all go through this mailing list
Thanks
Tomas
>
On Thu, Dec 13, 2007 at 06:36:03PM +0100, Johannes Berg wrote:
> Not sure if I really want to, maybe we can convince Jouni to take
> patches early if they don't break anything else?
I'm fine with patches that are either specific to driver_devicescape.c
or are clearly not breaking other driver wrappers (or core hostapd
functionality) as long as they are somehow in sync with a commonly used
Linux kernel tree. At some point, I would like to limit this to proper
kernel releases, but for the time being, any development tree should be
fine taken into account the current state of the AP support.
--
Jouni Malinen PGP id EFC895FA
> > Oh btw, will you be publishing driver updates to support AP mode in
> > iwlwifi? You must have them anyway if you're working on this and I'd
> > love have a second driver capable of AP mode in the kernel.
>
> We have frozen the AP stack before you've removed management interface
How's that relevant to the driver?
johannes