linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [Query] Decryption and Monitor Mode
@ 2013-11-05 19:52 Krishna Chaitanya
  2013-11-06  7:59 ` Johannes Berg
  0 siblings, 1 reply; 3+ messages in thread
From: Krishna Chaitanya @ 2013-11-05 19:52 UTC (permalink / raw)
  To: radiotap, linux-wireless

Hi,

In our internal tests we make use of monitor mode heavily for all the
debugging, especially with security related issues (as packets are
already decrypted).

But as the decryption is done in HW (most cases), the HW decrypts the
packet but still retains the Security Header and sends to the host (at
least in our solution), we remove that header while giving the packet
to network stack but while giving it to the monitor mode we do not
strip off that and also protection=1.

With this wireshark is not able to decode the packets, even thought
they are decrypted. I propose 2 solutions

Radiotap and Wireshark:

1) Add 2 flags to the radiotap RX Flags (HW Decrypted the packet,
Packet has security Header (for some chipsets which consume the
security header as well..??).)

Based on these the wireshark dissector decodes the packet accordingly.

mac80211:

2) Remove the security header information in the monitor path as well
based on the existing RX_FLAGS.


Solutions 2 looks more elegant and simple, any comments?

-- 
Thanks,
Regards,
Chaitanya T K.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Query] Decryption and Monitor Mode
  2013-11-05 19:52 [Query] Decryption and Monitor Mode Krishna Chaitanya
@ 2013-11-06  7:59 ` Johannes Berg
  2013-11-06 10:15   ` Krishna Chaitanya
  0 siblings, 1 reply; 3+ messages in thread
From: Johannes Berg @ 2013-11-06  7:59 UTC (permalink / raw)
  To: Krishna Chaitanya; +Cc: radiotap, linux-wireless

On Wed, 2013-11-06 at 01:22 +0530, Krishna Chaitanya wrote:

> With this wireshark is not able to decode the packets, even thought
> they are decrypted. I propose 2 solutions

Well, you can say "ignore protected bit (with IV)" in the settings of
wireshark. But I agree that this is cumbersome, and previously floated
the idea of addings bits to radiotap to make this auto-detected.

> Radiotap and Wireshark:
> 
> 1) Add 2 flags to the radiotap RX Flags (HW Decrypted the packet,
> Packet has security Header (for some chipsets which consume the
> security header as well..??).)
> 
> Based on these the wireshark dissector decodes the packet accordingly.
> 
> mac80211:
> 
> 2) Remove the security header information in the monitor path as well
> based on the existing RX_FLAGS.
> 
> 
> Solutions 2 looks more elegant and simple, any comments?

Solution 2 drops information and makes the kernel code more expensive,
so I don't think we want that.

I think the radiotap bits would be better.

johannes



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Query] Decryption and Monitor Mode
  2013-11-06  7:59 ` Johannes Berg
@ 2013-11-06 10:15   ` Krishna Chaitanya
  0 siblings, 0 replies; 3+ messages in thread
From: Krishna Chaitanya @ 2013-11-06 10:15 UTC (permalink / raw)
  To: Johannes Berg; +Cc: radiotap, linux-wireless

On Wed, Nov 6, 2013 at 1:29 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Wed, 2013-11-06 at 01:22 +0530, Krishna Chaitanya wrote:
>
>> With this wireshark is not able to decode the packets, even thought
>> they are decrypted. I propose 2 solutions
>
> Well, you can say "ignore protected bit (with IV)" in the settings of
> wireshark. But I agree that this is cumbersome, and previously floated
> the idea of addings bits to radiotap to make this auto-detected.
>

yeah, that piece of code looks messy.

>> Radiotap and Wireshark:
>>
>> 1) Add 2 flags to the radiotap RX Flags (HW Decrypted the packet,
>> Packet has security Header (for some chipsets which consume the
>> security header as well..??).)
>>
>> Based on these the wireshark dissector decodes the packet accordingly.
>>
>> mac80211:
>>
>> 2) Remove the security header information in the monitor path as well
>> based on the existing RX_FLAGS.
>>
>>
>> Solutions 2 looks more elegant and simple, any comments?
>
> Solution 2 drops information and makes the kernel code more expensive,
> so I don't think we want that.
>
> I think the radiotap bits would be better.
>
Ok, then i will proceed and add those 2 flags to the RX Flags (we have
enough bits to use).

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-11-06 10:16 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-05 19:52 [Query] Decryption and Monitor Mode Krishna Chaitanya
2013-11-06  7:59 ` Johannes Berg
2013-11-06 10:15   ` Krishna Chaitanya

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).