RadioTap Archive on lore.kernel.org
 help / color / Atom feed
* [Query] Decryption and Monitor Mode
@ 2013-11-05 19:52 Krishna Chaitanya
       [not found] ` <CABPxzY++gCivs1u8nDtAeB5=p+ZkGHXmOnqud1hkh=TWB5Xprg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
       [not found] ` <1383724794.14307.2.camel@jlt4.sipsolutions.net>
  0 siblings, 2 replies; 3+ messages in thread
From: Krishna Chaitanya @ 2013-11-05 19:52 UTC (permalink / raw)
  To: radiotap-S783fYmB3Ccdnm+yROfE0A, 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
       [not found] ` <CABPxzY++gCivs1u8nDtAeB5=p+ZkGHXmOnqud1hkh=TWB5Xprg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2013-11-06  7:59   ` Johannes Berg
  0 siblings, 0 replies; 3+ messages in thread
From: Johannes Berg @ 2013-11-06  7:59 UTC (permalink / raw)
  To: Krishna Chaitanya; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A, 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
       [not found]   ` <1383724794.14307.2.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org>
@ 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-S783fYmB3Ccdnm+yROfE0A, linux-wireless

On Wed, Nov 6, 2013 at 1:29 PM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> 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, back to index

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
     [not found] ` <CABPxzY++gCivs1u8nDtAeB5=p+ZkGHXmOnqud1hkh=TWB5Xprg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-11-06  7:59   ` Johannes Berg
     [not found] ` <1383724794.14307.2.camel@jlt4.sipsolutions.net>
     [not found]   ` <1383724794.14307.2.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2013-11-06 10:15     ` Krishna Chaitanya

RadioTap Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/radiotap/0 radiotap/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 radiotap radiotap/ https://lore.kernel.org/radiotap \
		radiotap@radiotap.org
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.netbsd.radiotap


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git