Re: [PATCH 1/2] [RFC] cfg80211: configuration of Bluetooth coexistence mode

[Johannes Berg <johannes@sipsolutions.net>]

On Fri, 2013-02-22 at 13:32 +0000, Piotr Haber wrote:

> > Apart from a few minor technical comments that I'll omit for now, I'm
> > not sure what value this really has? EAPOL can already be "protected" by
> > way of knowing when the station is marked authorized, and DHCP is pretty
> > tricky because it could take "forever", might not be there at all, etc.

> By "protect" I meant give Wifi a priority over BT so these time sensitive things 
> can finish quicker/on first try, limiting the possibility of dropping packets because of BT 
> using the medium.

I know :)

> 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.

> > 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.

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.

> 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?

To me this seems not very well thought out.

johannes