Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1491325

Re: [PATCH] brcmfmac: implement more accurate skb tracking

Show all headers | View raw

On Mon, 2016-09-26 at 14:13 +0200, Rafał Miłecki wrote:
> On 26 September 2016 at 13:46, Arend Van Spriel
> <arend.vanspriel@broadcom.com> wrote:
> > 
> > On 26-9-2016 12:23, Rafał Miłecki wrote:
> > > 
> > > From: Rafał Miłecki <rafal@milecki.pl>
> > > 
> > > We need to track 802.1x packets to know if there are any pending
> > > ones
> > > for transmission. This is required for performing key update in
> > > the
> > > firmware.
> > 
> > The problem we are trying to solve is a pretty old one. The problem
> > is
> > that wpa_supplicant uses two separate code paths: EAPOL messaging
> > through data path and key configuration though nl80211.
> 
> Can I find it described/reported somewhere?

If I understand the issue correctly, you can find all this in the
supplicant code.  Once the supplicant has done whatever it wants to do
with the data frames that just happen to be EAPOL it then sends the
keys down to the driver with nl80211.

But it sounds like, instead of sniffing EAPOL frames in the driver skb
tracking and sniffing ETH_P_PAE, you should probably implement support
for NL80211_CMD_CRIT_PROTOCOL_START/NL80211_CMD_CRIT_PROTOCOL_STOP and
key off the passed-in NL80211_CRIT_PROTO_EAPOL.  At least at the
beginning of connection setup only EAPOL packets will be allowed
anyway.

It doesn't seem like the supplicant uses NL80211_CRIT_PROTO_EAPOL yet,
but that should also be fixed in the supplicant itself.  You should
probably get some comments from Jouni on how he'd like to see all this
work.  But generally the less specific sniffing of frames in drivers,
likely the better.

Dan

> 
> > 
> > > 
> > > Unfortunately our old tracking code wasn't very accurate. It was
> > > treating skb as pending as soon as it was passed by the netif.
> > > Actual
> > > handling packet to the firmware was happening later as brcmfmac
> > > internally queues them and uses its own worker(s).
> > 
> > That does not seem right. As soon as we get a 1x packet we need to
> > wait
> > with key configuration regardless whether it is still in the driver
> > or
> > handed over to firmware already.
> 
> OK, thanks.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH] brcmfmac: implement more accurate skb tracking Rafał Miłecki <zajec5@gmail.com> - 2016-09-26 12:30 +0200
  Re: [PATCH] brcmfmac: implement more accurate skb tracking Arend Van Spriel <arend.vanspriel@broadcom.com> - 2016-09-26 13:50 +0200
    Re: [PATCH] brcmfmac: implement more accurate skb tracking Rafał Miłecki <zajec5@gmail.com> - 2016-09-26 14:20 +0200
      Re: [PATCH] brcmfmac: implement more accurate skb tracking Arend Van Spriel <arend.vanspriel@broadcom.com> - 2016-09-26 14:30 +0200
      Re: [PATCH] brcmfmac: implement more accurate skb tracking Rafał Miłecki <zajec5@gmail.com> - 2016-09-26 14:40 +0200
        Re: [PATCH] brcmfmac: implement more accurate skb tracking Arend Van Spriel <arend.vanspriel@broadcom.com> - 2016-09-27 11:30 +0200
          Re: [PATCH] brcmfmac: implement more accurate skb tracking Rafał Miłecki <zajec5@gmail.com> - 2016-09-30 00:00 +0200
            Re: [PATCH] brcmfmac: implement more accurate skb tracking Arend Van Spriel <arend.vanspriel@broadcom.com> - 2016-09-30 10:40 +0200
      Re: [PATCH] brcmfmac: implement more accurate skb tracking Dan Williams <dcbw@redhat.com> - 2016-09-26 17:00 +0200
        Re: [PATCH] brcmfmac: implement more accurate skb tracking Arend Van Spriel <arend.vanspriel@broadcom.com> - 2016-09-27 11:10 +0200

csiph-web