[PATCH] mac80211: add support for userspace to handle auth frames on adhoc ifaces

[PATCH] mac80211: add support for userspace to handle auth frames on adhoc ifaces

[Will Hawkins]

Hello all!

This patch allows userspace applications to use nl80211 to register for
AUTH frames received on adhoc interfaces.

Thanks,
Will

Signed-off-by: Will Hawkins <hawkinsw@opentechinstitute.org>
---
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index d81c178..4467162 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -455,7 +455,9 @@ static const struct ieee80211_txrx_stypes
 ieee80211_default_mgmt_stypes[NUM_NL80211_IFTYPES] = {
        [NL80211_IFTYPE_ADHOC] = {
                .tx = 0xffff,
-               .rx = BIT(IEEE80211_STYPE_ACTION >> 4),
+               .rx = BIT(IEEE80211_STYPE_ACTION >> 4) |
+                       BIT(IEEE80211_STYPE_AUTH >> 4) |
+                       BIT(IEEE80211_STYPE_DEAUTH >> 4),
        },
        [NL80211_IFTYPE_STATION] = {
                .tx = 0xffff,

Re: [PATCH] mac80211: add support for userspace to handle auth frames on adhoc ifaces

[Johannes Berg]

On Wed, 2012-06-13 at 11:46 -0400, Will Hawkins wrote:
> Hello all!
> 
> This patch allows userspace applications to use nl80211 to register for
> AUTH frames received on adhoc interfaces.
> 
> Thanks,
> Will
> 
> Signed-off-by: Will Hawkins <hawkinsw@opentechinstitute.org>

Thanks for the patch. Can I get you to write a better commit log? :-)

You should remove the "Hello" and "Thanks" portions, they shouldn't go
into the kernel's commit log after all. And then, even if I already
know, please explain in the commit log why you're making this change so
the reason gets recorded in the kernel's commit log.

Thanks,
johannes

Re: [PATCH] mac80211: add support for userspace to handle auth frames on adhoc ifaces

[Nicolas Cavallari]

On 13/06/2012 17:46, Will Hawkins wrote:
> Hello all!
> 
> This patch allows userspace applications to use nl80211 to register for
> AUTH frames received on adhoc interfaces.

Hi,

I just have a question here : when auth frames are not delivered to
userspace, mac80211 will respond to them, and also uses them to detect
node reboot. If you register for auth frames, mac80211 will still send
auth frames as soon as a new station is seen, which might be confusing
for user space. Is that ok to do this ? Or should userspace have more
control over how mac80211 sends auth frames ?

There is also another thing to consider if you want to send auth frames
from userspace, as CMD_FRAME requires a frequency, which in IBSS mode,
can change anytime without userspace being notified. If you only have to
answer to received auth frames, this is easier as you can reuse the
frequency given by nl80211 when receiving the auth frame. But if you
want to send a auth frame independently, how do you get the frequency to
use ?

I ask because i was currently trying to move the node reboot detection
from the kernel to userspace, and i currently only fixed these problems
by ugly hacks.

Re: [PATCH] mac80211: add support for userspace to handle auth frames on adhoc ifaces

[Johannes Berg]

On Thu, 2012-06-14 at 10:00 +0200, Nicolas Cavallari wrote:

> I just have a question here : when auth frames are not delivered to
> userspace, mac80211 will respond to them, and also uses them to detect
> node reboot. If you register for auth frames, mac80211 will still send
> auth frames as soon as a new station is seen, which might be confusing
> for user space. Is that ok to do this ? Or should userspace have more
> control over how mac80211 sends auth frames ?

Please read the code. If userspace registers for them, mac80211 will
never do anything with the frame.

> There is also another thing to consider if you want to send auth frames
> from userspace, as CMD_FRAME requires a frequency, which in IBSS mode,
> can change anytime without userspace being notified. If you only have to
> answer to received auth frames, this is easier as you can reuse the
> frequency given by nl80211 when receiving the auth frame. But if you
> want to send a auth frame independently, how do you get the frequency to
> use ?

You check the BSS info, that's trivial.

johannes

Re: [PATCH] mac80211: add support for userspace to handle auth frames on adhoc ifaces

[Nicolas Cavallari]

On 14/06/2012 13:24, Johannes Berg wrote:
> On Thu, 2012-06-14 at 10:00 +0200, Nicolas Cavallari wrote:
> 
>> I just have a question here : when auth frames are not delivered to
>> userspace, mac80211 will respond to them, and also uses them to detect
>> node reboot. If you register for auth frames, mac80211 will still send
>> auth frames as soon as a new station is seen, which might be confusing
>> for user space. Is that ok to do this ? Or should userspace have more
>> control over how mac80211 sends auth frames ?
> 
> Please read the code. If userspace registers for them, mac80211 will
> never do anything with the frame.

I didn't say the contrary. But if you read ieee80211_ibss_finish_sta(),
you see that mac80211 sends auth frames to each discovered station, even
if userspace want to handle auth frames. This seems strange to be able
to receive and handle auth frames from userspace while mac80211 sends
them behind userspace's back.

> 
>> There is also another thing to consider if you want to send auth frames
>> from userspace, as CMD_FRAME requires a frequency, which in IBSS mode,
>> can change anytime without userspace being notified. If you only have to
>> answer to received auth frames, this is easier as you can reuse the
>> frequency given by nl80211 when receiving the auth frame. But if you
>> want to send a auth frame independently, how do you get the frequency to
>> use ?
> 
> You check the BSS info, that's trivial.

There is no GET_BSS from userspace. when merging IBSS, only the new
BSSID is notified. The only way to get this info from userspace would be
to dump the scan result and check the "we joined that ibss" flag, and
this isn't race-free. That, or using fixed_freq.

Re: [PATCH] mac80211: add support for userspace to handle auth frames on adhoc ifaces

[Will Hawkins]

On 06/14/2012 03:13 AM, Johannes Berg wrote:
> On Wed, 2012-06-13 at 11:46 -0400, Will Hawkins wrote:
>> Hello all!
>>
>> This patch allows userspace applications to use nl80211 to register for
>> AUTH frames received on adhoc interfaces.
>>
>> Thanks,
>> Will
>>
>> Signed-off-by: Will Hawkins <hawkinsw@opentechinstitute.org>
> 
> Thanks for the patch. Can I get you to write a better commit log? :-)
> 
> You should remove the "Hello" and "Thanks" portions, they shouldn't go
> into the kernel's commit log after all. And then, even if I already
> know, please explain in the commit log why you're making this change so
> the reason gets recorded in the kernel's commit log.

I submitted a v2 of this patch with a better commit log. Thanks for the
handholding. I'm obviously still new at this!

Will

> 
> Thanks,
> 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: [PATCH] mac80211: add support for userspace to handle auth frames on adhoc ifaces

[Will Hawkins]

On 06/14/2012 08:46 AM, Nicolas Cavallari wrote:
> On 14/06/2012 13:24, Johannes Berg wrote:
>> On Thu, 2012-06-14 at 10:00 +0200, Nicolas Cavallari wrote:
>>
>>> I just have a question here : when auth frames are not delivered to
>>> userspace, mac80211 will respond to them, and also uses them to detect
>>> node reboot. If you register for auth frames, mac80211 will still send
>>> auth frames as soon as a new station is seen, which might be confusing
>>> for user space. Is that ok to do this ? Or should userspace have more
>>> control over how mac80211 sends auth frames ?
>>
>> Please read the code. If userspace registers for them, mac80211 will
>> never do anything with the frame.
> 
> I didn't say the contrary. But if you read ieee80211_ibss_finish_sta(),
> you see that mac80211 sends auth frames to each discovered station, even
> if userspace want to handle auth frames. This seems strange to be able
> to receive and handle auth frames from userspace while mac80211 sends
> them behind userspace's back.
> 
>>
>>> There is also another thing to consider if you want to send auth frames
>>> from userspace, as CMD_FRAME requires a frequency, which in IBSS mode,
>>> can change anytime without userspace being notified. If you only have to
>>> answer to received auth frames, this is easier as you can reuse the
>>> frequency given by nl80211 when receiving the auth frame. But if you
>>> want to send a auth frame independently, how do you get the frequency to
>>> use ?
>>
>> You check the BSS info, that's trivial.
> 
> There is no GET_BSS from userspace. when merging IBSS, only the new
> BSSID is notified. The only way to get this info from userspace would be
> to dump the scan result and check the "we joined that ibss" flag, and
> this isn't race-free. That, or using fixed_freq.
> 

I've only coded for situations where I am joined to an ibss with a
fixed_freq so I've never encountered this problem.

Will

Re: [PATCH] mac80211: add support for userspace to handle auth frames on adhoc ifaces

[Johannes Berg]

On Thu, 2012-06-14 at 14:46 +0200, Nicolas Cavallari wrote:
> On 14/06/2012 13:24, Johannes Berg wrote:
> > On Thu, 2012-06-14 at 10:00 +0200, Nicolas Cavallari wrote:
> > 
> >> I just have a question here : when auth frames are not delivered to
> >> userspace, mac80211 will respond to them, and also uses them to detect
> >> node reboot. If you register for auth frames, mac80211 will still send
> >> auth frames as soon as a new station is seen, which might be confusing
> >> for user space. Is that ok to do this ? Or should userspace have more
> >> control over how mac80211 sends auth frames ?
> > 
> > Please read the code. If userspace registers for them, mac80211 will
> > never do anything with the frame.
> 
> I didn't say the contrary. But if you read ieee80211_ibss_finish_sta(),
> you see that mac80211 sends auth frames to each discovered station, even
> if userspace want to handle auth frames. This seems strange to be able
> to receive and handle auth frames from userspace while mac80211 sends
> them behind userspace's back.

Oops, sorry, yes. I forgot all about that code!

I suppose we'd have to check whether userspace is handling
authentication?

> >> There is also another thing to consider if you want to send auth frames
> >> from userspace, as CMD_FRAME requires a frequency, which in IBSS mode,
> >> can change anytime without userspace being notified. If you only have to
> >> answer to received auth frames, this is easier as you can reuse the
> >> frequency given by nl80211 when receiving the auth frame. But if you
> >> want to send a auth frame independently, how do you get the frequency to
> >> use ?
> > 
> > You check the BSS info, that's trivial.
> 
> There is no GET_BSS from userspace. when merging IBSS, only the new
> BSSID is notified. The only way to get this info from userspace would be
> to dump the scan result and check the "we joined that ibss" flag, and
> this isn't race-free. That, or using fixed_freq.

Yeah, I guess that's true -- we should probably just allow not giving a
frequency attribute at all and then it only works if you're
connected/... but uses the right frequency.

johannes

Re: [PATCH] mac80211: add support for userspace to handle auth frames on adhoc ifaces

[Will Hawkins]

On 06/14/2012 12:53 PM, Johannes Berg wrote:
> On Thu, 2012-06-14 at 14:46 +0200, Nicolas Cavallari wrote:
>> On 14/06/2012 13:24, Johannes Berg wrote:
>>> On Thu, 2012-06-14 at 10:00 +0200, Nicolas Cavallari wrote:
>>>
>>>> I just have a question here : when auth frames are not delivered to
>>>> userspace, mac80211 will respond to them, and also uses them to detect
>>>> node reboot. If you register for auth frames, mac80211 will still send
>>>> auth frames as soon as a new station is seen, which might be confusing
>>>> for user space. Is that ok to do this ? Or should userspace have more
>>>> control over how mac80211 sends auth frames ?
>>>
>>> Please read the code. If userspace registers for them, mac80211 will
>>> never do anything with the frame.
>>
>> I didn't say the contrary. But if you read ieee80211_ibss_finish_sta(),
>> you see that mac80211 sends auth frames to each discovered station, even
>> if userspace want to handle auth frames. This seems strange to be able
>> to receive and handle auth frames from userspace while mac80211 sends
>> them behind userspace's back.
> 
> Oops, sorry, yes. I forgot all about that code!
> 
> I suppose we'd have to check whether userspace is handling
> authentication?

Could use the control_port flag to check for that condition?

> 
>>>> There is also another thing to consider if you want to send auth frames
>>>> from userspace, as CMD_FRAME requires a frequency, which in IBSS mode,
>>>> can change anytime without userspace being notified. If you only have to
>>>> answer to received auth frames, this is easier as you can reuse the
>>>> frequency given by nl80211 when receiving the auth frame. But if you
>>>> want to send a auth frame independently, how do you get the frequency to
>>>> use ?
>>>
>>> You check the BSS info, that's trivial.
>>
>> There is no GET_BSS from userspace. when merging IBSS, only the new
>> BSSID is notified. The only way to get this info from userspace would be
>> to dump the scan result and check the "we joined that ibss" flag, and
>> this isn't race-free. That, or using fixed_freq.
> 
> Yeah, I guess that's true -- we should probably just allow not giving a
> frequency attribute at all and then it only works if you're
> connected/... but uses the right frequency.
> 
> johannes
> 
> 

Re: [PATCH] mac80211: add support for userspace to handle auth frames on adhoc ifaces

[Johannes Berg]

On Thu, 2012-06-14 at 12:55 -0400, Will Hawkins wrote:
> 
> On 06/14/2012 12:53 PM, Johannes Berg wrote:
> > On Thu, 2012-06-14 at 14:46 +0200, Nicolas Cavallari wrote:
> >> On 14/06/2012 13:24, Johannes Berg wrote:
> >>> On Thu, 2012-06-14 at 10:00 +0200, Nicolas Cavallari wrote:
> >>>
> >>>> I just have a question here : when auth frames are not delivered to
> >>>> userspace, mac80211 will respond to them, and also uses them to detect
> >>>> node reboot. If you register for auth frames, mac80211 will still send
> >>>> auth frames as soon as a new station is seen, which might be confusing
> >>>> for user space. Is that ok to do this ? Or should userspace have more
> >>>> control over how mac80211 sends auth frames ?
> >>>
> >>> Please read the code. If userspace registers for them, mac80211 will
> >>> never do anything with the frame.
> >>
> >> I didn't say the contrary. But if you read ieee80211_ibss_finish_sta(),
> >> you see that mac80211 sends auth frames to each discovered station, even
> >> if userspace want to handle auth frames. This seems strange to be able
> >> to receive and handle auth frames from userspace while mac80211 sends
> >> them behind userspace's back.
> > 
> > Oops, sorry, yes. I forgot all about that code!
> > 
> > I suppose we'd have to check whether userspace is handling
> > authentication?
> 
> Could use the control_port flag to check for that condition?

Not really, that's not necessarily the same thing -- I think we might
want to also allow to offload open auth to userspace.

I think it wouldn't be difficult to notify mac80211 about frame
registrations so it can keep track for this purpose?

johannes

Re: [PATCH] mac80211: add support for userspace to handle auth frames on adhoc ifaces

[Will Hawkins]

On 06/14/2012 01:08 PM, Johannes Berg wrote:
> On Thu, 2012-06-14 at 12:55 -0400, Will Hawkins wrote:
>>
>> On 06/14/2012 12:53 PM, Johannes Berg wrote:
>>> On Thu, 2012-06-14 at 14:46 +0200, Nicolas Cavallari wrote:
>>>> On 14/06/2012 13:24, Johannes Berg wrote:
>>>>> On Thu, 2012-06-14 at 10:00 +0200, Nicolas Cavallari wrote:
>>>>>
>>>>>> I just have a question here : when auth frames are not delivered to
>>>>>> userspace, mac80211 will respond to them, and also uses them to detect
>>>>>> node reboot. If you register for auth frames, mac80211 will still send
>>>>>> auth frames as soon as a new station is seen, which might be confusing
>>>>>> for user space. Is that ok to do this ? Or should userspace have more
>>>>>> control over how mac80211 sends auth frames ?
>>>>>
>>>>> Please read the code. If userspace registers for them, mac80211 will
>>>>> never do anything with the frame.
>>>>
>>>> I didn't say the contrary. But if you read ieee80211_ibss_finish_sta(),
>>>> you see that mac80211 sends auth frames to each discovered station, even
>>>> if userspace want to handle auth frames. This seems strange to be able
>>>> to receive and handle auth frames from userspace while mac80211 sends
>>>> them behind userspace's back.
>>>
>>> Oops, sorry, yes. I forgot all about that code!
>>>
>>> I suppose we'd have to check whether userspace is handling
>>> authentication?
>>
>> Could use the control_port flag to check for that condition?
> 
> Not really, that's not necessarily the same thing -- I think we might
> want to also allow to offload open auth to userspace.
> 
> I think it wouldn't be difficult to notify mac80211 about frame
> registrations so it can keep track for this purpose?
> 
> johannes

I am happy to code something like this up. I've already taken a look at
it and don't think it will be too big of a problem. I am going to be AFK
until Monday so I won't get to it until then. I hope that's not a problem.

Will

> 
> --
> 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: [PATCH] mac80211: add support for userspace to handle auth frames on adhoc ifaces

[Johannes Berg]

> >>> Oops, sorry, yes. I forgot all about that code!
> >>>
> >>> I suppose we'd have to check whether userspace is handling
> >>> authentication?
> >>
> >> Could use the control_port flag to check for that condition?
> > 
> > Not really, that's not necessarily the same thing -- I think we might
> > want to also allow to offload open auth to userspace.
> > 
> > I think it wouldn't be difficult to notify mac80211 about frame
> > registrations so it can keep track for this purpose?
> > 
> > johannes
> 
> I am happy to code something like this up. I've already taken a look at
> it and don't think it will be too big of a problem. I am going to be AFK
> until Monday so I won't get to it until then. I hope that's not a problem.

No problem, take your time! I'm not in any hurry with this feature :-)

johannes