[ath9k-devel] Packet Injection in Monitor Mode Sending Packets Twice

[ath9k-devel] Packet Injection in Monitor Mode Sending Packets Twice

[Mark Gannon]

I'm currently troubleshooting a problem using the ath9k driver where by 
packets injected via libpcap are sent twice with slightly different radiotap 
headers.  The issue happens with different software injecting the packets.

The system is an up to date Gentoo box where uname -a shows:
Linux scooby 3.18.5-gentoo #1 SMP PREEMPT Wed Feb 4 16:54:06 EST 2015 x86_64 
AMD A6-3650 APU with Radeon(tm) HD Graphics AuthenticAMD GNU/Linux

lspci shows the card as:
02:00.0 Network controller: Qualcomm Atheros AR93xx Wireless Network Adapter 
(rev 01)

In order to create the problem: 

1.  Load the driver:  modprobe ath9k debug=0x00000282
Note: The problem happens with or without the debug parameters 
2.  Create the monitor interface using: 
iw dev wlan0 interface add fish0 type monitor flags none
iw reg set US 
ifconfig fish0 up

3.  Download and build the packetspammer application from: 
https://wireless.wiki.kernel.org/en/users/Documentation/packetspammer
Note:  I edited Makefile to remove the -werror that was causing the make to 
fail.
4.  Start Wireshark listening to the fish0 interface.  
5.  Run packetspammer: ./packetspammer -d 1000000000000000000000000000 fish0
Note:  The long delay is to make the issue easier to see in the trace.

Result:
Wireshark shows two packets with slightly different lengths due to differences 
in the radiotap header.  The second packet has a much smaller radiotap header 
only setting the speed.  

In examining the driver code in the kernel tree, there appears to be a 
difference between main.c and htc_drv_main.c with regard to packet injection.  
The latter includes a section with the comment: "Associate a station with the 
interface for packet injection."  After the comment, is code to associate a 
station with the interface.  As near as I can tell, this process doesn't occur 
in main.c, which is the code being executed for my NIC.  Could this be the 
reason for the duplicate packets?

Any help addressing this issue is greatly appreciated.

Regards,

Mark Gannon

-- 
You have to accept whatever comes, and the only important thing is that you 
meet it with the best you have to give. 

	? Eleanor Roosevelt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20150324/10262918/attachment.pgp 

[ath9k-devel] Packet Injection in Monitor Mode Sending Packets Twice

[Thomas V]

There is a possibility that the 1st frame is retried. Can you check for the
"retry bit"  in the sniffer capture.


Regards,
Thomas.

On Wed, Mar 25, 2015 at 1:05 AM, Mark Gannon <mark@truenorth.nu> wrote:

> I'm currently troubleshooting a problem using the ath9k driver where by
> packets injected via libpcap are sent twice with slightly different
> radiotap
> headers.  The issue happens with different software injecting the packets.
>
> The system is an up to date Gentoo box where uname -a shows:
> Linux scooby 3.18.5-gentoo #1 SMP PREEMPT Wed Feb 4 16:54:06 EST 2015
> x86_64
> AMD A6-3650 APU with Radeon(tm) HD Graphics AuthenticAMD GNU/Linux
>
> lspci shows the card as:
> 02:00.0 Network controller: Qualcomm Atheros AR93xx Wireless Network
> Adapter
> (rev 01)
>
> In order to create the problem:
>
> 1.  Load the driver:  modprobe ath9k debug=0x00000282
> Note: The problem happens with or without the debug parameters
> 2.  Create the monitor interface using:
> iw dev wlan0 interface add fish0 type monitor flags none
> iw reg set US
> ifconfig fish0 up
>
> 3.  Download and build the packetspammer application from:
> https://wireless.wiki.kernel.org/en/users/Documentation/packetspammer
> Note:  I edited Makefile to remove the -werror that was causing the make to
> fail.
> 4.  Start Wireshark listening to the fish0 interface.
> 5.  Run packetspammer: ./packetspammer -d 1000000000000000000000000000
> fish0
> Note:  The long delay is to make the issue easier to see in the trace.
>
> Result:
> Wireshark shows two packets with slightly different lengths due to
> differences
> in the radiotap header.  The second packet has a much smaller radiotap
> header
> only setting the speed.
>
> In examining the driver code in the kernel tree, there appears to be a
> difference between main.c and htc_drv_main.c with regard to packet
> injection.
> The latter includes a section with the comment: "Associate a station with
> the
> interface for packet injection."  After the comment, is code to associate a
> station with the interface.  As near as I can tell, this process doesn't
> occur
> in main.c, which is the code being executed for my NIC.  Could this be the
> reason for the duplicate packets?
>
> Any help addressing this issue is greatly appreciated.
>
> Regards,
>
> Mark Gannon
>
> --
> You have to accept whatever comes, and the only important thing is that you
> meet it with the best you have to give.
>
>         ? Eleanor Roosevelt
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20150325/e181d2ad/attachment.htm 

[ath9k-devel] Packet Injection in Monitor Mode Sending Packets Twice

[Mark Gannon]

On Wednesday, March 25, 2015 10:49:43 AM Thomas V wrote:
> There is a possibility that the 1st frame is retried. Can you check for the
> "retry bit"  in the sniffer capture.

The retry flag in the IEEE 802.11 section is set to zero for both the first and 
second packet.  Here is a text version of Wireshark's exported packet 
dissection for the second packet:

 IEEE 802.11 Data, Flags: .......T
    Type/Subtype: Data (0x0020)
    Frame Control Field: 0x0801
        .... ..00 = Version: 0
        .... 10.. = Type: Data frame (2)
        0000 .... = Subtype: 0
        Flags: 0x01
            .... ..01 = DS status: Frame from STA to DS via an AP (To DS: 1 
From DS: 0) (0x01)
            .... .0.. = More Fragments: This is the last fragment
            .... 0... = Retry: Frame is not being retransmitted
            ...0 .... = PWR MGT: STA will stay up
            ..0. .... = More Data: No data buffered
            .0.. .... = Protected flag: Data is not protected
            0... .... = Order flag: Not strictly ordered
    .000 0000 0000 0000 = Duration: 0 microseconds
    Receiver address: Broadcast (ff:ff:ff:ff:ff:ff)
    BSS Id: Broadcast (ff:ff:ff:ff:ff:ff)
    Transmitter address: 13:22:33:44:55:66 (13:22:33:44:55:66)
    Source address: 13:22:33:44:55:66 (13:22:33:44:55:66)
    Destination address: 13:22:33:44:55:66 (13:22:33:44:55:66)
    Fragment number: 0
    Sequence number: 2145

Thanks for your help!

Regards,

Mark Gannon

-- 
You have to accept whatever comes, and the only important thing is that you 
meet it with the best you have to give. 

	? Eleanor Roosevelt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20150325/3cd0faba/attachment.pgp 

[ath9k-devel] Packet Injection in Monitor Mode Sending Packets Twice

[Federico Tramarin]

In our experiments, with a very similar PCI card, we saw exactly the same behavior?.

However, are you using wireshark on the same PC your are using for transmission?

Since in this case you will see the duplicate packets, while on an external monitoring (passive) PC you will see 
your single packet, as expected.

Let me know

Cheers,

Federico


> Il giorno 25/mar/2015, alle ore 15:26, Mark Gannon <mark@truenorth.nu> ha scritto:
> 
> On Wednesday, March 25, 2015 10:49:43 AM Thomas V wrote:
>> There is a possibility that the 1st frame is retried. Can you check for the
>> "retry bit"  in the sniffer capture.
> 
> The retry flag in the IEEE 802.11 section is set to zero for both the first and 
> second packet.  Here is a text version of Wireshark's exported packet 
> dissection for the second packet:
> 
> IEEE 802.11 Data, Flags: .......T
>    Type/Subtype: Data (0x0020)
>    Frame Control Field: 0x0801
>        .... ..00 = Version: 0
>        .... 10.. = Type: Data frame (2)
>        0000 .... = Subtype: 0
>        Flags: 0x01
>            .... ..01 = DS status: Frame from STA to DS via an AP (To DS: 1 
> From DS: 0) (0x01)
>            .... .0.. = More Fragments: This is the last fragment
>            .... 0... = Retry: Frame is not being retransmitted
>            ...0 .... = PWR MGT: STA will stay up
>            ..0. .... = More Data: No data buffered
>            .0.. .... = Protected flag: Data is not protected
>            0... .... = Order flag: Not strictly ordered
>    .000 0000 0000 0000 = Duration: 0 microseconds
>    Receiver address: Broadcast (ff:ff:ff:ff:ff:ff)
>    BSS Id: Broadcast (ff:ff:ff:ff:ff:ff)
>    Transmitter address: 13:22:33:44:55:66 (13:22:33:44:55:66)
>    Source address: 13:22:33:44:55:66 (13:22:33:44:55:66)
>    Destination address: 13:22:33:44:55:66 (13:22:33:44:55:66)
>    Fragment number: 0
>    Sequence number: 2145
> 
> Thanks for your help!
> 
> Regards,
> 
> Mark Gannon
> 
> -- 
> You have to accept whatever comes, and the only important thing is that you 
> meet it with the best you have to give. 
> 
> 	? Eleanor Roosevelt_______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] Packet Injection in Monitor Mode Sending Packets Twice

[Michael Stahn]

The reason is because you're in monitor mode: Your card receives
anything in the air, even it's from its own source. Because you're in
monitor mode, you receive the packet you've just sent out as the card
sees it's own signals, too. Your radiotap header should slightly differ
for both packets in most cases.

-mike

On 25.03.2015 15:42, Federico Tramarin wrote:
> In our experiments, with a very similar PCI card, we saw exactly the same behavior?.
> 
> However, are you using wireshark on the same PC your are using for transmission?
> 
> Since in this case you will see the duplicate packets, while on an external monitoring (passive) PC you will see 
> your single packet, as expected.
> 
> Let me know
> 
> Cheers,
> 
> Federico
> 
> 
>> Il giorno 25/mar/2015, alle ore 15:26, Mark Gannon <mark@truenorth.nu> ha scritto:
>>
>> On Wednesday, March 25, 2015 10:49:43 AM Thomas V wrote:
>>> There is a possibility that the 1st frame is retried. Can you check for the
>>> "retry bit"  in the sniffer capture.
>>
>> The retry flag in the IEEE 802.11 section is set to zero for both the first and 
>> second packet.  Here is a text version of Wireshark's exported packet 
>> dissection for the second packet:
>>
>> IEEE 802.11 Data, Flags: .......T
>>    Type/Subtype: Data (0x0020)
>>    Frame Control Field: 0x0801
>>        .... ..00 = Version: 0
>>        .... 10.. = Type: Data frame (2)
>>        0000 .... = Subtype: 0
>>        Flags: 0x01
>>            .... ..01 = DS status: Frame from STA to DS via an AP (To DS: 1 
>> From DS: 0) (0x01)
>>            .... .0.. = More Fragments: This is the last fragment
>>            .... 0... = Retry: Frame is not being retransmitted
>>            ...0 .... = PWR MGT: STA will stay up
>>            ..0. .... = More Data: No data buffered
>>            .0.. .... = Protected flag: Data is not protected
>>            0... .... = Order flag: Not strictly ordered
>>    .000 0000 0000 0000 = Duration: 0 microseconds
>>    Receiver address: Broadcast (ff:ff:ff:ff:ff:ff)
>>    BSS Id: Broadcast (ff:ff:ff:ff:ff:ff)
>>    Transmitter address: 13:22:33:44:55:66 (13:22:33:44:55:66)
>>    Source address: 13:22:33:44:55:66 (13:22:33:44:55:66)
>>    Destination address: 13:22:33:44:55:66 (13:22:33:44:55:66)
>>    Fragment number: 0
>>    Sequence number: 2145
>>
>> Thanks for your help!
>>
>> Regards,
>>
>> Mark Gannon
>>
>> -- 
>> You have to accept whatever comes, and the only important thing is that you 
>> meet it with the best you have to give. 
>>
>> 	? Eleanor Roosevelt_______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> 
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> 

[ath9k-devel] Packet Injection in Monitor Mode Sending Packets Twice

[Mark Gannon]

On Wednesday, March 25, 2015 04:45:13 PM Michael Stahn wrote:
>  Because you're in
> monitor mode, you receive the packet you've just sent out as the card
> sees it's own signals, too. Your radiotap header should slightly differ
> for both packets in most cases.

Most of my experience has been on wired analysis, so I was unfamiliar with 
this behavior.  I will look into getting another interface do to the 
observations (I don't have another one that will work in monitor mode at the 
moment).

Thanks for helping me understand!  

Regards,

Mark Gannon

-- 
You have to accept whatever comes, and the only important thing is that you 
meet it with the best you have to give. 

	? Eleanor Roosevelt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20150325/b10a6c9e/attachment.pgp