From: Will Hawkins <hawkinsw@opentechinstitute.org>
To: Nicolas Cavallari <Nicolas.Cavallari@lri.fr>
Cc: Johannes Berg <johannes@sipsolutions.net>,
linux-wireless@vger.kernel.org
Subject: Re: [PATCH] mac80211: add support for userspace to handle auth frames on adhoc ifaces
Date: Thu, 14 Jun 2012 12:48:14 -0400 [thread overview]
Message-ID: <4FDA15CE.9050408@opentechinstitute.org> (raw)
In-Reply-To: <4FD9DD35.4070709@lri.fr>
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
next prev parent reply other threads:[~2012-06-14 16:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-13 15:46 [PATCH] mac80211: add support for userspace to handle auth frames on adhoc ifaces Will Hawkins
2012-06-14 7:13 ` Johannes Berg
2012-06-14 16:45 ` Will Hawkins
2012-06-14 8:00 ` Nicolas Cavallari
2012-06-14 11:24 ` Johannes Berg
2012-06-14 12:46 ` Nicolas Cavallari
2012-06-14 16:48 ` Will Hawkins [this message]
2012-06-14 16:53 ` Johannes Berg
2012-06-14 16:55 ` Will Hawkins
2012-06-14 17:08 ` Johannes Berg
2012-06-14 18:26 ` Will Hawkins
2012-06-14 18:51 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FDA15CE.9050408@opentechinstitute.org \
--to=hawkinsw@opentechinstitute.org \
--cc=Nicolas.Cavallari@lri.fr \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.