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:
pgpzsK66J1dil.pgp
Description: PGP signature
