On Fri, 2013-02-22 at 13:32 +0000, Johannes Berg wrote:
> 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.
Actually, the timeout is in brcmfmac so it currently relies on common sense of the driver developers (they tend to use it from time to time though).
> > > 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.
Ah, did we miss some cfg80211 API call that can tell us a station is authorized.
> 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.
> > 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?
That obviously depends on the DHCP lease time or a renewal request. So it could be called afterwards as well.
> 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.
We'll do some more thinking and see whether there will be a RFC v2 ;-)
Gr. AvS
... why not tag such traffic with a higher QOS priority and then have
the BT coex module snoop thaT?
Adrian
>>
>
> In the driver we could inspect each sk_buff and boost priority of any BOOTP packets so that it will end up in the AC_VO fifo and have hardware coexistence handle it further. I consider that more a pragmatic fix, which is not always the worst thing to go for. However, I would prefer a solution is which user-space, ie. dhcp client can control the priority and/or BT coexistence.
>
I don't think that the "session solution" as proposed in the RFC is
the right one. Because the DHCP could take forever and also because
there might be quite a few non-critical packets right after
connections. There might be a bunch of services that may wake up and
begin to send a whole bunch of things. OTOH, EAPOL and friends *need*
priority, so I guess that the per-packet solution is the right one.
Note that we could think about a flag in the tx_control in which cfg /
mac80211 would let the driver know that this packet is a "high
priority packet" or even better "a connection gating packet". This
list would include managements / EAPOL / DHCP / any other kind of
stuff that look like these. I remember I saw once in the code
something that looked like this but can't find it right now.
FWIW: here is the code that classifies the packets in iwlwifi:
/* High prio packet (wrt. BT coex) if it is EAPOL, MCAST or MGMT */
if (info->band == IEEE80211_BAND_2GHZ &&
(skb->protocol == cpu_to_be16(ETH_P_PAE) ||
is_multicast_ether_addr(hdr->addr1) ||
ieee80211_is_back_req(fc) ||
ieee80211_is_mgmt(fc)))
tx_flags |= TX_CMD_FLG_BT_DIS;
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
On Saturday, February 23, 2013 1:30 AM Adrian Chadd wrote:
>
> ... why not tag such traffic with a higher QOS priority and then have
> the BT coex module snoop thaT?
>
In the driver we could inspect each sk_buff and boost priority of any BOOTP packets so that it will end up in the AC_VO fifo and have hardware coexistence handle it further. I consider that more a pragmatic fix, which is not always the worst thing to go for. However, I would prefer a solution is which user-space, ie. dhcp client can control the priority and/or BT coexistence.
Gr. AvS