All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benoit PAPILLAULT <benoit.papillault@free.fr>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: "Gábor Stefanik" <netrolller.3d@gmail.com>,
	linux-wireless@vger.kernel.org
Subject: Re: [PATCH 1/2] mac80211: Drop protected data frames that have not been decrypted
Date: Mon, 15 Feb 2010 23:36:27 +0100	[thread overview]
Message-ID: <4B79CC6B.5000905@free.fr> (raw)
In-Reply-To: <1266226483.7084.1.camel@jlt3.sipsolutions.net>

Johannes Berg a écrit :
> On Mon, 2010-02-15 at 08:45 +0100, Benoit PAPILLAULT wrote:
>
>   
>>> I'm not familiar with this part of the code; but have you tested if
>>> this doesn't break monitor-while-operating mode (i.e. doesn't remove
>>> other-STA frames from monitor interfaces)?
>>>
>>>   
>>>       
>> Yes, it has been tested in this case. In fact, this patch changes RX 
>> path only in ieee80211_rx_h_data / ieee80211_rx_h_action and 
>> ieee80211_rx_h_mgmt. In all 3 cases, it returns RX_DROP_MONITOR.
>>     
>
> ???
>
>         if (ieee80211_drop_unencrypted(rx, mgmt->frame_control))
>                 return RX_DROP_UNUSABLE;
>   
This code was not in wireless-testing/master yesterday when I sent the 
patches.
> However. GUYS!!! Read the code! Real monitor mode bypasses _ALL_ the RX
> handlers, frames just short-circuit up right after they are received
> from the driver.
>   
Just for my own understanding. It seems the implementation has 2 
different code path :
- "real" monitor mode which is handled right after ieee80211_rx() so it 
is not affected
- "cook" monitor mode which is handled as part of the RX handlers.

BTW, why do we have 2 different code path? I'm sure I missed something 
obvious here.
> johannes
>   

Regards,
Benoit


  reply	other threads:[~2010-02-15 22:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-14 23:37 [PATCH 1/2] mac80211: Drop protected data frames that have not been decrypted Benoit Papillault
2010-02-14 23:37 ` [PATCH 2/2] mac80211: Add HT IE to IBSS beacons and probe responses Benoit Papillault
2010-02-15  9:35   ` Johannes Berg
2010-02-15 22:32     ` Benoit PAPILLAULT
2010-02-16  7:17       ` Johannes Berg
2010-02-15  0:10 ` [PATCH 1/2] mac80211: Drop protected data frames that have not been decrypted Gábor Stefanik
2010-02-15  7:45   ` Benoit PAPILLAULT
2010-02-15  9:34     ` Johannes Berg
2010-02-15 22:36       ` Benoit PAPILLAULT [this message]
2010-02-16  7:18         ` Johannes Berg
2010-02-15  9:36 ` Johannes Berg
2010-02-16  9:58 ` 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=4B79CC6B.5000905@free.fr \
    --to=benoit.papillault@free.fr \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netrolller.3d@gmail.com \
    /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.