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

[Johannes Berg <johannes@sipsolutions.net>]

On Fri, 2013-02-22 at 16:59 +0000, Arend Van Spriel wrote:

> > 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.
> 
> We discussed this and we could start protecting when we see a BOOTP
> message, but indeed the end is not that straightforward and would need
> a "DHCP done" notification. However, if we have that there is little
> overhead in having a "DHCP start" notification and I would prefer to
> avoid looking into the sk_buff to check the protocol. The knowledge of
> DHCP start and done is not a responsibility of the driver.

Yes, I agree that sniffing the traffic for this is not a good idea.

> > Is there any *reason* for it though? Would it ever call it after the
> > connection is fully established?
> 
> That obviously depends on the DHCP lease time or a renewal request. So
> it could be called afterwards as well.

But is it? You'd usually expect the DHCP renewal to happen before the
lease expires so then it wouldn't be quite that latency sensitive.

> > To me this seems not very well thought out.
> 
> Have to admit that it is a bit uninspired to reuse. In Android bcmdhd
> it is actually done by driver private ioctl, which did seem like a
> worse idea. Considered doing it entirely in the driver, but decided
> that it could be beneficial for dhcp clients to use such an interface
> and (arguably) for supplicant as well.

Yes, although actually even for DHCP you could probably go on things
like "do I have an address configured", maybe. Not really sure. Having
some sort of "DHCP bracketing" would seem quite a bit saner though than
what was proposed now.

johannes