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.
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
On Wed, Nov 6, 2013 at 1:29 PM, Johannes Berg <[email protected]> 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).