Re: [WIP] mac80211: kill mgmt interface

[Michael Wu <flamingice@sourmilk.net>]

[-- Attachment #1: Type: text/plain, Size: 3585 bytes --]

On Thursday 21 June 2007 06:35, Jouni Malinen wrote:
> On Thu, Jun 21, 2007 at 11:42:19AM +0200, Johannes Berg wrote:
> > This patch kills the management interface type now that we can
> > see transmitted frames on monitor interfaces.
>
> Has someone tested that this works with programs that use the management
> interface (mainly, hostapd and wpa_supplicant)? Is all the needed
> functionality available with the alternative solution?
>
The management interface shouldn't be killed until hostap and wpa_supplicant 
can work with monitor interfaces.

> > I renamed the req_tx_status to reliable_tx_mntr and the flag
> > constant as well since that's what they now mean. It is always
> > set for injected frames so that hostapd can rely on seeing the
> > frames it sent.
>
> I'm not sure I follow this explanation fully.. How would hostapd learn
> whether the destination address acknowledged a unicast frame?
>
It's the same as the management interface - hostap receives the same frame it 
sent, with a header that says whether or not it was ACKed.

> > The biggest problem, however, and I'm not sure how to solve it, is
> > that hostapd will see either encrypted or unencrypted frames on the
> > monitor interface depending on whether hardware encryption is used
> > or not. However, hostapd really needs to see eapol frames to do
> > whatever it needs to with them. Right now, I don't really have an
> > idea except maybe to send these packets to hostapd via nl80211,
> > or to introduce some sort of "decrypted soft monitor" iface.
>
> If I've understood correctly (please correct me, if not), this patch is
> proposing to remove an interface that works currently and leave the
> stack in state that does not work. I can only strongly recommend this
> patch not to be applied at this point. It is not a good direction to
> start removing working code before there is a good alternative available
> and that alternative has actually been tested to provide the needed
> functionality.
>
Agreed. However, it is marked WIP and has spawned some good discussion. :)

> I don't really see need for getting rid of the management interface, but
> if there is consensus on doing that, we would need to have another way
> of being able to receive and transmit management frames and data frames
> from/to user space in a way that provides at least following
> functionality:
> - transmit management frames at high priority
Should be fine to hardcode this for now since the current mgmt interface 
doesn't allow control over this.

> - control whether transmitted frames will be encrypted or not
IEEE80211_RADIOTAP_F_WEP should be appropriate, I think. (despite its somewhat 
misleading name)

> - get callback to report TX status for unicast frames (whether the
>   receiver sent control::ack for the frame)
This is provided by [PATCH] mac80211: show transmitted frames on monitor 
interfaces.

> - receive management frames
Well, it's a monitor interface, so it's more of a challenge to receive just 
the desired frames. Hopefully packet filter works well enough for this..

> - receive data frames EAPOL/etc. ethertypes in decrypted form
We should be able to receive this on the other interface which is handling all 
the data frames, right?

> - delivery of notifications to user space for Michael MIC errors and
>   other similar events
nl80211 should be appropriate for this. nl80211 is probably the biggest 
blocker before removing the mgmt interface completely.. everything else is 
*almost* there.

-Michael Wu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]