Help tracing NL80211_CMD_AUTHENTICATE as event in IBSS mode

Help tracing NL80211_CMD_AUTHENTICATE as event in IBSS mode

[Will Hawkins]

Hello everyone!

I've been banging my head against a particular problem for a few days without any success. I thought I'd turn to those much smarter for some help and hopefully a breakthrough.

The documentation for nl80211 says the following about the NL80211_CMD_AUTHENTICATE command:
"When used as an event, this reports reception of an Authentication frame in station and IBSS modes when the local MLME processed the frame, i.e., it was for the local STA and was received in correct state."

I very much want this to be true for IBSS modes. However, I cannot seem to trace through the source code to confirm that this actually happens. I can easily follow the code for the case when the interface is in station mode but lose the trail for IBSS. 

As far as I can tell, the only path to nl80211_send_rx_auth (the only place a NL80211_CMD_AUTHENTICATE command is sent to userspace) looks like this:
ieee80211_iface_work invokes ieee80211_sta_rx_queued_mgmt to handle queued management packets received on a station interface. ieee80211_sta_rx_queued_mgmt (eventually) invokes cfg80211_send_rx_auth, after the proper handling. Finally, cfg80211_send_rx_auth invokes nl80211_send_rx_auth.

If anyone can provide any help, I would sincerely appreciate it. I am not looking for hand-holding -- I know everyone is very busy doing their own work. But, I am at my wits' end here so I thought I'd ask for help!

Thanks everyone,
Will

Re: Help tracing NL80211_CMD_AUTHENTICATE as event in IBSS mode

[Johannes Berg]

Hi,

> The documentation for nl80211 says the following about the
> NL80211_CMD_AUTHENTICATE command:
> "When used as an event, this reports reception of an Authentication
> frame in station and IBSS modes when the local MLME processed the
> frame, i.e., it was for the local STA and was received in correct
> state."
> 
> I very much want this to be true for IBSS modes. However, I cannot
> seem to trace through the source code to confirm that this actually
> happens. I can easily follow the code for the case when the interface
> is in station mode but lose the trail for IBSS. 

I'm afraid that isn't actually true for IBSS. The event you get there
will be NL80211_CMD_NEW_STATION.

> As far as I can tell, the only path to nl80211_send_rx_auth (the only
> place a NL80211_CMD_AUTHENTICATE command is sent to userspace) looks
> like this:
> ieee80211_iface_work invokes ieee80211_sta_rx_queued_mgmt to handle
> queued management packets received on a station interface.
> ieee80211_sta_rx_queued_mgmt (eventually) invokes
> cfg80211_send_rx_auth, after the proper handling. Finally,
> cfg80211_send_rx_auth invokes nl80211_send_rx_auth.

Yes.


I think in your case though, what you really want is a NL80211_CMD_FRAME
event? You register for auth frames, also to prevent mac80211 from
handling them itself, and then they get diverted to cfg80211_rx_mgmt()
and on to nl80211_send_mgmt().

johannes

Re: Help tracing NL80211_CMD_AUTHENTICATE as event in IBSS mode

[Will Hawkins]

On 06/26/2012 02:53 AM, Johannes Berg wrote:
> Hi,
> 
>> The documentation for nl80211 says the following about the
>> NL80211_CMD_AUTHENTICATE command:
>> "When used as an event, this reports reception of an Authentication
>> frame in station and IBSS modes when the local MLME processed the
>> frame, i.e., it was for the local STA and was received in correct
>> state."
>>
>> I very much want this to be true for IBSS modes. However, I cannot
>> seem to trace through the source code to confirm that this actually
>> happens. I can easily follow the code for the case when the interface
>> is in station mode but lose the trail for IBSS. 
> 
> I'm afraid that isn't actually true for IBSS. The event you get there
> will be NL80211_CMD_NEW_STATION.

Thank you for the sanity check! Do you think it's worthwhile to patch
the nl80211.h file to address this?

> 
>> As far as I can tell, the only path to nl80211_send_rx_auth (the only
>> place a NL80211_CMD_AUTHENTICATE command is sent to userspace) looks
>> like this:
>> ieee80211_iface_work invokes ieee80211_sta_rx_queued_mgmt to handle
>> queued management packets received on a station interface.
>> ieee80211_sta_rx_queued_mgmt (eventually) invokes
>> cfg80211_send_rx_auth, after the proper handling. Finally,
>> cfg80211_send_rx_auth invokes nl80211_send_rx_auth.
> 
> Yes.
> 
> 
> I think in your case though, what you really want is a NL80211_CMD_FRAME
> event? You register for auth frames, also to prevent mac80211 from
> handling them itself, and then they get diverted to cfg80211_rx_mgmt()
> and on to nl80211_send_mgmt().

Thanks for this, as well. As far as the patch that I submitted, you are
exactly correct. I was only investigating this other method since it
appears that's how wpa_supplicant claims to support IBSS RSN.
wpa_supplicant never actually registers for AUTH frames (through
NL80211_CMD_REGISTER) and relies solely on the NL80211_CMD_AUTHENTICATE
to actually receive copies of those frames.

Thanks again. My forehead was getting sore from all the banging!
Will

> 
> johannes
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Help tracing NL80211_CMD_AUTHENTICATE as event in IBSS mode

[Johannes Berg]

On Tue, 2012-06-26 at 12:23 -0400, Will Hawkins wrote:

> >> "When used as an event, this reports reception of an Authentication
> >> frame in station and IBSS modes when the local MLME processed the
> >> frame, i.e., it was for the local STA and was received in correct
> >> state."
> >>
> >> I very much want this to be true for IBSS modes. However, I cannot
> >> seem to trace through the source code to confirm that this actually
> >> happens. I can easily follow the code for the case when the interface
> >> is in station mode but lose the trail for IBSS. 
> > 
> > I'm afraid that isn't actually true for IBSS. The event you get there
> > will be NL80211_CMD_NEW_STATION.
> 
> Thank you for the sanity check! Do you think it's worthwhile to patch
> the nl80211.h file to address this?

Yes, we should remove the IBSS text here :-)

> > I think in your case though, what you really want is a NL80211_CMD_FRAME
> > event? You register for auth frames, also to prevent mac80211 from
> > handling them itself, and then they get diverted to cfg80211_rx_mgmt()
> > and on to nl80211_send_mgmt().
> 
> Thanks for this, as well. As far as the patch that I submitted, you are
> exactly correct. I was only investigating this other method since it
> appears that's how wpa_supplicant claims to support IBSS RSN.
> wpa_supplicant never actually registers for AUTH frames (through
> NL80211_CMD_REGISTER) and relies solely on the NL80211_CMD_AUTHENTICATE
> to actually receive copies of those frames.

Huh, now I'm confused, why would it need the authenticate frames for
IBSS? As far as I can tell, it looks at CMD_NEW_STA, which calls
nl80211_new_station_event(), which in IBSS sends EVENT_IBSS_RSN_START to
the supplicant core -- that will trigger the 4-way-handshake. No? Hence
it doesn't need to register for auth frames, it never needs them, since
RSN uses open auth, if any is even used in IBSS at all.

johannes

Re: Help tracing NL80211_CMD_AUTHENTICATE as event in IBSS mode

[Will Hawkins]

On 06/26/2012 12:41 PM, Johannes Berg wrote:
> On Tue, 2012-06-26 at 12:23 -0400, Will Hawkins wrote:
> 
>>>> "When used as an event, this reports reception of an Authentication
>>>> frame in station and IBSS modes when the local MLME processed the
>>>> frame, i.e., it was for the local STA and was received in correct
>>>> state."
>>>>
>>>> I very much want this to be true for IBSS modes. However, I cannot
>>>> seem to trace through the source code to confirm that this actually
>>>> happens. I can easily follow the code for the case when the interface
>>>> is in station mode but lose the trail for IBSS. 
>>>
>>> I'm afraid that isn't actually true for IBSS. The event you get there
>>> will be NL80211_CMD_NEW_STATION.
>>
>> Thank you for the sanity check! Do you think it's worthwhile to patch
>> the nl80211.h file to address this?
> 
> Yes, we should remove the IBSS text here :-)
> 
>>> I think in your case though, what you really want is a NL80211_CMD_FRAME
>>> event? You register for auth frames, also to prevent mac80211 from
>>> handling them itself, and then they get diverted to cfg80211_rx_mgmt()
>>> and on to nl80211_send_mgmt().
>>
>> Thanks for this, as well. As far as the patch that I submitted, you are
>> exactly correct. I was only investigating this other method since it
>> appears that's how wpa_supplicant claims to support IBSS RSN.
>> wpa_supplicant never actually registers for AUTH frames (through
>> NL80211_CMD_REGISTER) and relies solely on the NL80211_CMD_AUTHENTICATE
>> to actually receive copies of those frames.
> 
> Huh, now I'm confused, why would it need the authenticate frames for
> IBSS? As far as I can tell, it looks at CMD_NEW_STA, which calls
> nl80211_new_station_event(), 

This is what I understand as well.

which in IBSS sends EVENT_IBSS_RSN_START to
> the supplicant core -- that will trigger the 4-way-handshake. No? Hence
> it doesn't need to register for auth frames, it never needs them, since
> RSN uses open auth, if any is even used in IBSS at all.

This is where I am still trying to figure out exactly how it works.

No false modesty, but I'm sure you are correct and I was wrong. I've
only started to really dive into the wpa_supplicant stuff. Either way, I
will submit a patch for that documentation and continue my work :-)

Thanks again!
Will

> 
> johannes
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Help tracing NL80211_CMD_AUTHENTICATE as event in IBSS mode

[Johannes Berg]

On Tue, 2012-06-26 at 12:44 -0400, Will Hawkins wrote:

> > Huh, now I'm confused, why would it need the authenticate frames for
> > IBSS? As far as I can tell, it looks at CMD_NEW_STA, which calls
> > nl80211_new_station_event(), 
> 
> This is what I understand as well.
> 
> which in IBSS sends EVENT_IBSS_RSN_START to
> > the supplicant core -- that will trigger the 4-way-handshake. No? Hence
> > it doesn't need to register for auth frames, it never needs them, since
> > RSN uses open auth, if any is even used in IBSS at all.
> 
> This is where I am still trying to figure out exactly how it works.

I believe that when the new station is added (NEW_STA event), it will
simply send out a 1/4 EAPOL frame. Since both do that, I guess it does
some kind of de-duplication? Whoever sends it first wins or something,
but I don't really know. Maybe we should take the discussion to the
hostap list at this point :-)

johannes

Re: Help tracing NL80211_CMD_AUTHENTICATE as event in IBSS mode

[Antonio Quartulli]

[-- Attachment #1: Type: text/plain, Size: 1750 bytes --]

On Tue, Jun 26, 2012 at 07:03:30PM +0200, Johannes Berg wrote:
> On Tue, 2012-06-26 at 12:44 -0400, Will Hawkins wrote:
> 
> > > Huh, now I'm confused, why would it need the authenticate frames for
> > > IBSS? As far as I can tell, it looks at CMD_NEW_STA, which calls
> > > nl80211_new_station_event(), 
> > 
> > This is what I understand as well.
> > 
> > which in IBSS sends EVENT_IBSS_RSN_START to
> > > the supplicant core -- that will trigger the 4-way-handshake. No? Hence
> > > it doesn't need to register for auth frames, it never needs them, since
> > > RSN uses open auth, if any is even used in IBSS at all.
> > 
> > This is where I am still trying to figure out exactly how it works.
> 
> I believe that when the new station is added (NEW_STA event), it will
> simply send out a 1/4 EAPOL frame. Since both do that, I guess it does
> some kind of de-duplication? Whoever sends it first wins or something,
> but I don't really know. Maybe we should take the discussion to the
> hostap list at this point :-)

Yeah, Johannes is right when saying that NEW_STA simply makes wpa_s trigger a
EVENT_IBSS_RSN_START that will start a 4-way handshake.

Auth frames are not used at all in wpa_s for IBSS/RSN. Auth frames are only used
in the kernel to remove and then add again a station from the neighbour list. In
this way wpa_s will first purge that station and then will add it again thanks
to another NEW_STA event.

@johannes: de-duplication? IBSS/RSN assumes that each node runs an authenticator
and a supplicant. Does this mean that we need exactly two 4-way handshakes? Why
should we have a "winner"?

Cheers,



-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: Help tracing NL80211_CMD_AUTHENTICATE as event in IBSS mode

[Johannes Berg]

On Tue, 2012-06-26 at 20:55 +0200, Antonio Quartulli wrote:

> @johannes: de-duplication? IBSS/RSN assumes that each node runs an authenticator
> and a supplicant. Does this mean that we need exactly two 4-way handshakes? Why
> should we have a "winner"?

I may misremember, I thought we didn't need two handshakes. But maybe we
do, and just throw away one of the PTKs?

johannes

Re: Help tracing NL80211_CMD_AUTHENTICATE as event in IBSS mode

[Antonio Quartulli]

[-- Attachment #1: Type: text/plain, Size: 830 bytes --]

On Tue, Jun 26, 2012 at 08:56:28PM +0200, Johannes Berg wrote:
> On Tue, 2012-06-26 at 20:55 +0200, Antonio Quartulli wrote:
> 
> > @johannes: de-duplication? IBSS/RSN assumes that each node runs an authenticator
> > and a supplicant. Does this mean that we need exactly two 4-way handshakes? Why
> > should we have a "winner"?
> 
> I may misremember, I thought we didn't need two handshakes. But maybe we
> do, and just throw away one of the PTKs?

You are the expert here eheh.. but after having conducted 2 different 4-way
handshakes, the pairwise key of the STA with the greater MAC address is used.

Ok we are going OT :-) but you can check wpa_supplicant/ibss_rsn.c:282 and
section 11.5.13 of 802.11-2012.

Cheers,


-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: Help tracing NL80211_CMD_AUTHENTICATE as event in IBSS mode

[Johannes Berg]

On Tue, 2012-06-26 at 21:35 +0200, Antonio Quartulli wrote:
> On Tue, Jun 26, 2012 at 08:56:28PM +0200, Johannes Berg wrote:
> > On Tue, 2012-06-26 at 20:55 +0200, Antonio Quartulli wrote:
> > 
> > > @johannes: de-duplication? IBSS/RSN assumes that each node runs an authenticator
> > > and a supplicant. Does this mean that we need exactly two 4-way handshakes? Why
> > > should we have a "winner"?
> > 
> > I may misremember, I thought we didn't need two handshakes. But maybe we
> > do, and just throw away one of the PTKs?
> 
> You are the expert here eheh..

Clearly I'm not :-)
Thanks for the explanation.

johannes

Re: Help tracing NL80211_CMD_AUTHENTICATE as event in IBSS mode

[Nicolas Cavallari]

On 26/06/2012 20:56, Johannes Berg wrote:
> On Tue, 2012-06-26 at 20:55 +0200, Antonio Quartulli wrote:
>
>> @johannes: de-duplication? IBSS/RSN assumes that each node runs an authenticator
>> and a supplicant. Does this mean that we need exactly two 4-way handshakes? Why
>> should we have a "winner"?
> I may misremember, I thought we didn't need two handshakes. But maybe we
> do, and just throw away one of the PTKs?
You need two handshake because you need two GTK. And if multicast
doesn't work, then ARP/ND fails, and no unicast traffic will take place.

The PTK from the authenticator with the highest MAC address wins, but
the other handshake is still needed so the highest MAC address STA can
get the lowest MAC's GTK.