> > This is supposed to be temporary and time limited, so if say DHCP finishes in the window > > we give it - great, if not the coexistence goes back to default behavior and Wifi traffic is > > treated as usual. > That's not even documented/implemented, the way I read the patch you'd > have to set it back manually. You are right, we implement it this way in brcmfmac but it is not documented in nl80211 change. I thought of DISABLED as a trigger (for timed boost) and ENABLED as a way to notify that whoever requested it is done. The interface could be made to reflect this "design" > > > What application would actually call this? I don't really see how it > > > could be integrated like that. > > For EAPOL wpa_supplicant might use it. For DHCP it could be used from enter/exit hooks > > via iw or some other utility able to send nl messages. > See that's the thing, I don't really see the point for EAPOL: you could > just as well start protecting when the association is done, and end it > when the station is marked authorized. That will have protected any > EAPOL (or other protocols for that matter) traffic. That is true, this could be totally automatic. > Similarly, you could give it a certain timeout to protect DHCP traffic. > I guess the only thing that would seem necessary would be a notification > of "DHCP done" that would allow you to drop the protection right away. I guess that is the only reason we need this interface. Still if we set the "protection" timeout to be reasonable it can do without it... > > This feature is styled after Android one. > I know, I'm (vaguely) familiar with that. > > There a Wifi state machine tries to "protect" DHCP traffic. > Is there any *reason* for it though? Would it ever call it after the > connection is fully established? As for reason I can't tell, someone found one to implement it in Android :) It is not used after connection is established. Piotr -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
