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