* [ath9k-devel] Packet Injection in Monitor Mode Sending Packets Twice
@ 2015-03-24 19:35 Mark Gannon
2015-03-25 5:19 ` Thomas V
0 siblings, 1 reply; 6+ messages in thread
From: Mark Gannon @ 2015-03-24 19:35 UTC (permalink / raw)
To: ath9k-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] Packet Injection in Monitor Mode Sending Packets Twice
2015-03-24 19:35 [ath9k-devel] Packet Injection in Monitor Mode Sending Packets Twice Mark Gannon
@ 2015-03-25 5:19 ` Thomas V
2015-03-25 14:26 ` Mark Gannon
0 siblings, 1 reply; 6+ messages in thread
From: Thomas V @ 2015-03-25 5:19 UTC (permalink / raw)
To: ath9k-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] Packet Injection in Monitor Mode Sending Packets Twice
2015-03-25 5:19 ` Thomas V
@ 2015-03-25 14:26 ` Mark Gannon
2015-03-25 14:42 ` Federico Tramarin
0 siblings, 1 reply; 6+ messages in thread
From: Mark Gannon @ 2015-03-25 14:26 UTC (permalink / raw)
To: ath9k-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread* [ath9k-devel] Packet Injection in Monitor Mode Sending Packets Twice
2015-03-25 14:26 ` Mark Gannon
@ 2015-03-25 14:42 ` Federico Tramarin
2015-03-25 15:45 ` Michael Stahn
0 siblings, 1 reply; 6+ messages in thread
From: Federico Tramarin @ 2015-03-25 14:42 UTC (permalink / raw)
To: ath9k-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] Packet Injection in Monitor Mode Sending Packets Twice
2015-03-25 14:42 ` Federico Tramarin
@ 2015-03-25 15:45 ` Michael Stahn
2015-03-25 17:04 ` Mark Gannon
0 siblings, 1 reply; 6+ messages in thread
From: Michael Stahn @ 2015-03-25 15:45 UTC (permalink / raw)
To: ath9k-devel
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] Packet Injection in Monitor Mode Sending Packets Twice
2015-03-25 15:45 ` Michael Stahn
@ 2015-03-25 17:04 ` Mark Gannon
0 siblings, 0 replies; 6+ messages in thread
From: Mark Gannon @ 2015-03-25 17:04 UTC (permalink / raw)
To: ath9k-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-03-25 17:04 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-03-24 19:35 [ath9k-devel] Packet Injection in Monitor Mode Sending Packets Twice Mark Gannon
2015-03-25 5:19 ` Thomas V
2015-03-25 14:26 ` Mark Gannon
2015-03-25 14:42 ` Federico Tramarin
2015-03-25 15:45 ` Michael Stahn
2015-03-25 17:04 ` Mark Gannon
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.