[ath9k-devel] RadioTap Headers in Managed Mode

[ath9k-devel] RadioTap Headers in Managed Mode

[mahaveer gupta]

Hello,

RadioTap headers are produced only in monitor mode.

Wondering how hard it would be to tweak the driver is to get these headers
in a normal managed mode too.

Any pointers will be helpful, if such a feature is available

-- 
Thanks,
M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140614/1ffbb15a/attachment.htm 

[ath9k-devel] RadioTap Headers in Managed Mode

[Holger Schurig]

That would be pretty useless. No user-space application would know
about this (e.g. you couldn't use wpa_supplicant then), and the kernel
TCP/IP would also fail.

However, you can have one managed mode interface (e.g. "wlan0") and at
the same time a monitor interface ("mon0"). In that case you get
everything on mon0 what happens on wlan0. wpa_supplicant continues to
work, and TCP/IP isn't borked either.

[ath9k-devel] RadioTap Headers in Managed Mode

[mahaveer gupta]

Thanks for the suggestion, the user-space programs won't understand the
format, but the plan was to use a click modular router and strip off the
radiotap fields after logging them (and replace with ethernet header before
passing to host)

However, having another monitor interface should work well, should give
what i need without changing the kernel.




On Sat, Jun 14, 2014 at 2:36 PM, Holger Schurig <holgerschurig@gmail.com>
wrote:

> That would be pretty useless. No user-space application would know
> about this (e.g. you couldn't use wpa_supplicant then), and the kernel
> TCP/IP would also fail.
>
> However, you can have one managed mode interface (e.g. "wlan0") and at
> the same time a monitor interface ("mon0"). In that case you get
> everything on mon0 what happens on wlan0. wpa_supplicant continues to
> work, and TCP/IP isn't borked either.
>



-- 
Thanks,
M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140614/658a2cea/attachment.htm 

[ath9k-devel] Delayed transmission configuration switching

[Ali Abedi]

Hello,

We use the Ath9k driver for our 802.11 research projects. We transmit 
every frame using a new transmission rate (MCS, short GI, HT20/40). We 
cycle through all different rates (96 rates in our 3x3:3 testbed).
We noticed that when we change the transmission configuration (i.e. from 
Short GI to Long GI, and from HT40 to HT20) the next packet is sent at 
the previous configuration.


MCS    S-GI    HT40
12        1            0
12        1            0
12        1            0
6          1            0  <--- supposed to be 6  0  0  (The sender 
claims that this frame was sent using L-GI)
6          0            0
6          0            0

It seems that the hardware did not have time to switch the 
configuration. Does anyone know if this is the actual reason and if 
there is any solution?

Thank you,
Ali