SGFzIGFueW9uZSBleHBlcmllbmNlZCB0aGF0IFJUUy9DVFMgaGFuZHNoYWtpbmcgc3RvcHMgb2NjdXJyaW5nIGF0IHRoZQpjbGllbnQgaWYgdGhlIHRoZSBhY2Nlc3MgcG9pbnQgZW5hYmxlcyBXTU0/CgoKVXNpbmcgdGhlIGNhcmw5MTcwIGRyaXZlciB3aXRoIFJUUy9DVFMgaGFuZHNoYWtpbmcgZW5hYmxlZCBvbiBhIFVTQiAKVWJpcXVpdGkgU1I3MS1VU0IgKEF0aGVyb3MgQVI5MTcwIGJhc2VkIHdpcmVsZXNzIGFkYXB0ZXIpLiAgUlRTL0NUUyB3aWxsIApzdG9wIHdvcmtpbmcgd2hlbiBXTU0gaXMgZW5hYmxlZCBvbiB0aGUgV0FQLiAgCgpUaGUgbmV0d29yayBpcyBydW5uaW5nIGluIDgwMi4xMW4gQy1iYW5kICg1R0h6KSBjaGFubmVscyBpbiAKSW5mcmFzdHJ1Y3R1cmUgbW9kZSB3aXRoIGFuIEF0aGVyb3MgQVI5MzcwIGJhc2VkIEFjY2VzcyBQb2ludC4gIFdlIGFyZSAKdXNpbmcgUlRTL0NUUyBoYW5kc2hha2luZyB0byByZWR1Y2Ug4oCcSGlkZGVuIE5vZGXigJ0gZWZmZWN0cy4gIE90aGVyIApjbGllbnRzIGluIHRoZSBuZXR3b3JrIHJlcXVpcmUgV01NIHRvIGJlIGVuYWJsZWQuICBGb3IgcmVhc29ucyBjaXRlZCBpbiAKaHR0cDovL3d3dy5zbWFsbG5ldGJ1aWxkZXIuY29tL3dpcmVsZXNzL3dpcmVsZXNzLWZlYXR1cmVzLzMwOTM4LWRvbnQtCm1lc3Mtd2l0aC13bW0sIFdNTSBzaG91bGQgYmUgZW5hYmxlZCB0byBzdXBwb3J0IDgwMi4xMWUsIApyZXF1aXJlZCBmb3IgODAyLjExbiB0byB1c2UgSFQgKEhpZ2ggVGhyb3VnaHB1dCkgbGluayByYXRlcy4KCldpdGggdGhlIFdNTSB0dXJuZWQgT0ZGIGF0IHRoZSBBUCBhbmQgUlRTIHZhbHVlID0gMjU2IGF0IHRoZSBVYmlxdWl0aSAKY2xpZW50LCB0aGUgUlRTL0NUUyBoYW5kc2hha2UgZnVuY3Rpb25zIG5vcm1hbGx5LiAgV2l0aCBXTU0gdHVybmVkIE9OIGF0IAp0aGUgQVAgYW5kIFJUUyB2YWx1ZSA9IDI1NiBzdGlsbCBvbiBhdCB0aGUgY2xpZW50IG5vIFJUUy9DVFMgaGFuZHNoYWtlIApvY2N1cnMuICBUaGUgY2FybDkxNzAgY2xpZW50IHN0b3BzIHNlbmRpbmcgdGhlIFJUUywgYW5kIHRoZSBjYXJsMTk3MCAKY2xpZW50IGlnbm9yaW5nIHRoZSBDVFMgbWVzc2FnZXMgdHJhbnNtaXR0ZWQgYnkgdGhlIEFQLCBjYXVzaW5nIApjb2xsaXNpb25zIGJlY2F1c2Ugb2YgbXkg4oCcSGlkZGVuIE5vZGXigJ0gY29uZGl0aW9uLgoKSGFkIHRvIGdldCBzY29wZSBwbG90cyBvZiB0aGUgUkYgbmV0d29yayB0cmFmZmljIGJldHdlZW4gdGhlIEFQIGFuZCAKY2xpZW50IHRvIG9ic2VydmUgdGhpcyBoYXBwZW5pbmcuCgoKdGhhbmtzLApFcmlj
On Friday, February 05, 2016 04:07:22 PM Eric Hillary wrote:
> Has anyone experienced that RTS/CTS handshaking stops occurring at the
> client if the the access point enables WMM?
yes, the 802.11-draftn device has problems (rx and tx become stuck) with
802.11n and proper WMM (and with RTS/CTS). Sadly, I don't know of any
workaround that works for all the configurations I tested, other than
going for a ath9k_htc device.
> Using the carl9170 driver with RTS/CTS handshaking enabled on a USB
> Ubiquiti SR71-USB (Atheros AR9170 based wireless adapter). RTS/CTS will
> stop working when WMM is enabled on the WAP.
You can overwrite carl9170's behavior (per device). You need to have
DEBUGFS enabled for the driver (CONFIG_CARL9170_DEBUGFS). There is a
control setting in: /sys/kernel/debug/ieee80211/phyX/carl9170/erp
1 - Automatic (default)
2 - Set by mac80211
3 - Force off
4 - Force CTS
5 - Force RTS
You can try echo 2 > erp. And check the setting with cat erp
> The network is running in 802.11n C-band (5GHz) channels in
> Infrastructure mode with an Atheros AR9370 based Access Point. We are
> using RTS/CTS handshaking to reduce “Hidden Node” effects. Other
> clients in the network require WMM to be enabled. For reasons cited in
> http://www.smallnetbuilder.com/wireless/wireless-features/30938-dont-
> mess-with-wmm, WMM should be enabled to support 802.11e,
> required for 802.11n to use HT (High Throughput) link rates.
>
> With the WMM turned OFF at the AP and RTS value = 256 at the Ubiquiti
> client, the RTS/CTS handshake functions normally. With WMM turned ON at
> the AP and RTS value = 256 still on at the client no RTS/CTS handshake
> occurs. The carl9170 client stops sending the RTS, and the carl1970
> client ignoring the CTS messages transmitted by the AP, causing
> collisions because of my “Hidden Node” condition.
>
> Had to get scope plots of the RF network traffic between the AP and
> client to observe this happening.
scope plots from a real analyzer? I would love to have a look at those :).
Regards,
Christian