From: Christian Lamparter <chunkeey@googlemail.com>
To: Eric Hillary <eric.hillary-1@nasa.gov>
Cc: linux-wireless@vger.kernel.org
Subject: [RESEND] Re: carl9170 client RTS/CTS option being overridden by WAP's WMM option
Date: Fri, 05 Feb 2016 20:25:37 +0100 [thread overview]
Message-ID: <2823949.eMyd5ddxzU@debian64> (raw)
In-Reply-To: <loom.20160205T170355-618@post.gmane.org>
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
prev parent reply other threads:[~2016-02-05 19:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 16:07 carl9170 client RTS/CTS option being overridden by WAP's WMM option Eric Hillary
2016-02-05 19:25 ` Christian Lamparter [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2823949.eMyd5ddxzU@debian64 \
--to=chunkeey@googlemail.com \
--cc=eric.hillary-1@nasa.gov \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.