carl9170: Beacons at lower Tx power than data frames?

carl9170: Beacons at lower Tx power than data frames?

[Harshal Chhaya]

Hello,

I am working on an AP design that uses a TI-OMAP3 host processor with
an Atheros AR9170 + AR9101 WLAN chipset. We are currently using
carl9170 version 1.9.2 and carl9170 firmware version 1.9.4.

During network tests, several of the clients drop-off the network. The
packet captures show that the beacons sent by the AP are at a much
lower power than the other data packets. For example, the beacons are
typically at -75 dbm while the data packets are at -54 dbm or better.
The power for all packets ranges from -99dBm to -45dbm at a sniffer
(Omnipeek) sitting about 4 ft away.

One theory is that the clients are missing enough beacons that they
assume that they are disconnected.

Is this wide variation in the AP's transmit power the expected
behavior with this driver/firmware/chipset? If not, where do I look to
fix this.

Thanks,
- Harshal

Re: carl9170: Beacons at lower Tx power than data frames?

[Christian Lamparter]

On Thursday 14 July 2011 21:37:29 Harshal Chhaya wrote:
> I am working on an AP design that uses a TI-OMAP3 host processor with
> an Atheros AR9170 + AR9101 WLAN chipset. We are currently using
> carl9170 version 1.9.2 and carl9170 firmware version 1.9.4.
One question: have you considered ath9k_htc? I would certainly recommend
it over any ar9170 device.
 
> During network tests, several of the clients drop-off the network.
what tests? Also isn't there any verbose logs on the client/ap to why
they kick each other? 

> The packet captures show that the beacons sent by the AP are at a much
> lower power than the other data packets. Is this wide variation in the AP's
> transmit power the expected behavior with this driver/firmware/chipset?
> If not, where do I look to fix this.
Try this:
---
diff --git a/drivers/net/wireless/ath/carl9170/hw.h b/drivers/net/wireless/ath/carl9170/hw.h
index 261f893..3025f0b 100644
--- a/drivers/net/wireless/ath/carl9170/hw.h
+++ b/drivers/net/wireless/ath/carl9170/hw.h
@@ -391,7 +391,39 @@
 
 
 #define	AR9170_MAC_REG_BCN_HT1			(AR9170_MAC_REG_BASE + 0xda0)
+#define		AR9170_MAC_BCN_HT1_HT_EN		BIT(0)
+#define		AR9170_MAC_BCN_HT1_GF_PMB		BIT(1)
+#define		AR9170_MAC_BCN_HT1_SP_EXP		BIT(2)
+#define		AR9170_MAC_BCN_HT1_TX_BF		BIT(3)
+#define		AR9170_MAC_BCN_HT1_PWR_CTRL_S		4
+#define		AR9170_MAC_BCN_HT1_PWR_CTRL		0x70
+#define		AR9170_MAC_BCN_HT1_TX_ANT1		BIT(7)
+#define		AR9170_MAC_BCN_HT1_TX_ANT0		BIT(8)
+#define		AR9170_MAC_BCN_HT1_NUM_LFT_S		9
+#define		AR9170_MAC_BCN_HT1_NUM_LFT		0x600
+#define		AR9170_MAC_BCN_HT1_BWC_20M_EXT		BIT(16)
+#define		AR9170_MAC_BCN_HT1_BWC_40M_SHARED	BIT(17)
+#define		AR9170_MAC_BCN_HT1_BWC_40M_DUP		(BIT(16) | BIT(17))
+#define		AR9170_MAC_BCN_HT1_BF_MCS_S		18
+#define		AR9170_MAC_BCN_HT1_BF_MCS		0x1c0000
+#define		AR9170_MAC_BCN_HT1_TPC_S		21
+#define		AR9170_MAC_BCN_HT1_TPC			0x7e00000
+#define		AR9170_MAC_BCN_HT1_CHAIN_MASK_S		27
+#define		AR9170_MAC_BCN_HT1_CHAIN_MASK		0x38000000
+
 #define	AR9170_MAC_REG_BCN_HT2			(AR9170_MAC_REG_BASE + 0xda4)
+#define		AR9170_MAC_BCN_HT2_MCS_S		0
+#define		AR9170_MAC_BCN_HT2_MCS			0x7f
+#define		AR9170_MAC_BCN_HT2_BW40			BIT(8)
+#define		AR9170_MAC_BCN_HT2_SMOOTHING		BIT(9)
+#define		AR9170_MAC_BCN_HT2_SS			BIT(10)
+#define		AR9170_MAC_BCN_HT2_NSS			BIT(11)
+#define		AR9170_MAC_BCN_HT2_STBC_S		12
+#define		AR9170_MAC_BCN_HT2_STBC			0x3000
+#define		AR9170_MAC_BCN_HT2_ADV_COD		BIT(14)
+#define		AR9170_MAC_BCN_HT2_SGI			BIT(15)
+#define		AR9170_MAC_BCN_HT2_LEN_S		16
+#define		AR9170_MAC_BCN_HT2_LEN			0xffff0000
 
 #define	AR9170_MAC_REG_DMA_TXQX_ADDR_CURR	(AR9170_MAC_REG_BASE + 0xdc0)
 
diff --git a/drivers/net/wireless/ath/carl9170/mac.c b/drivers/net/wireless/ath/carl9170/mac.c
index 385cf50..4a2e9ad 100644
--- a/drivers/net/wireless/ath/carl9170/mac.c
+++ b/drivers/net/wireless/ath/carl9170/mac.c
@@ -460,8 +460,10 @@ int carl9170_update_beacon(struct ar9170 *ar, const bool submit)
 	struct sk_buff *skb = NULL;
 	struct carl9170_vif_info *cvif;
 	struct ieee80211_tx_info *txinfo;
+	struct ieee80211_rate *rate;
 	__le32 *data, *old = NULL;
-	u32 word, off, addr, len;
+	u8 *txpower;
+	u32 word, ht1 = 0, chains, off, addr, len;
 	int i = 0, err = 0;
 
 	rcu_read_lock();
@@ -527,17 +529,43 @@ found:
 	}
 
 	i = txinfo->control.rates[0].idx;
-	if (txinfo->band != IEEE80211_BAND_2GHZ)
+	if (txinfo->band != IEEE80211_BAND_2GHZ) {
 		i += 4;
+		txpower = ar->power_5G_leg;
+	} else {
+		if (i < 4)
+			txpower = ar->power_2G_cck;
+		else
+			txpower = ar->power_2G_ofdm;
+	}
 
-	word = __carl9170_ratetable[i].hw_value & 0xf;
+	rate = &__carl9170_ratetable[i];
+	word = rate->hw_value & 0xf;
 	if (i < 4)
 		word |= ((skb->len + FCS_LEN) << (3 + 16)) + 0x0400;
 	else
 		word |= ((skb->len + FCS_LEN) << 16) + 0x0010;
 
+	SET_VAL(AR9170_MAC_BCN_HT1_PWR_CTRL, ht1, 7);
+	SET_VAL(AR9170_MAC_BCN_HT1_TPC, ht1,
+		txpower[(rate->hw_value & 0x30) >> 4]);
+
+	if (ar->eeprom.tx_mask == 1) {
+		chains = AR9170_TX_PHY_TXCHAIN_1;
+	} else {
+		chains = AR9170_TX_PHY_TXCHAIN_2;
+		if (rate && rate->bitrate >= 360)
+			chains = AR9170_TX_PHY_TXCHAIN_1;
+	}
+	if (chains == AR9170_TX_PHY_TXCHAIN_2)
+		ht1 |= AR9170_MAC_BCN_HT1_TX_ANT1;
+
+	ht1 |= AR9170_MAC_BCN_HT1_TX_ANT0;
+	SET_VAL(AR9170_MAC_BCN_HT1_CHAIN_MASK, ht1, chains);
+
 	carl9170_async_regwrite_begin(ar);
 	carl9170_async_regwrite(AR9170_MAC_REG_BCN_PLCP, word);
+	carl9170_async_regwrite(AR9170_MAC_REG_BCN_HT1, ht1);
 
 	for (i = 0; i < DIV_ROUND_UP(skb->len, 4); i++) {
 		/*

Re: carl9170: Beacons at lower Tx power than data frames?

[Harshal Chhaya]

Christian,

Thanks for your patch - it definitely helped. My feedback to this (and
some more info) is below.


On Fri, Jul 15, 2011 at 9:22 AM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Thursday 14 July 2011 21:37:29 Harshal Chhaya wrote:
>> I am working on an AP design that uses a TI-OMAP3 host processor with
>> an Atheros AR9170 + AR9101 WLAN chipset. We are currently using
>> carl9170 version 1.9.2 and carl9170 firmware version 1.9.4.
> One question: have you considered ath9k_htc? I would certainly recommend
> it over any ar9170 device.

I was under the impression that AP mode support is better in carl9170
than in ath9k_htc. I had considered using AR9271 (which is a more
recent chipset than the AR9170) but decided against it based on my
understanding (which is based on the info on the wiki pages).

If AR9271 (and ath9k_htc) are more stable and preferable to the AR9170
w/ carl9170, please let me know.

Also, to clarify: my application is a wireless network that needs to
support 60-70 802.11g clients connecting to the AP using WPA2-PEAP.
All of the clients are battery powered and use the power save
mechanisms of 802.11.

Do you see any issues using AR9170 and carl9170 in this scenario?

Also, I am running openWRT on an TI-OMAP3 processor @ 600 MHz.


>> During network tests, several of the clients drop-off the network.
> what tests? Also isn't there any verbose logs on the client/ap to why
> they kick each other?

The clients didn't have any helpful logs except that they disconnected
due to not seeing any beacons for a few seconds. That's when I started
looking at the beacons in more detail.


>> The packet captures show that the beacons sent by the AP are at a much
>> lower power than the other data packets. Is this wide variation in the AP's
>> transmit power the expected behavior with this driver/firmware/chipset?
>> If not, where do I look to fix this.
> Try this:
> ---
> diff --git a/drivers/net/wireless/ath/carl9170/hw.h b/drivers/net/wireless/ath/carl9170/hw.h
> index 261f893..3025f0b 100644
> --- a/drivers/net/wireless/ath/carl9170/hw.h
> +++ b/drivers/net/wireless/ath/carl9170/hw.h
> @@ -391,7 +391,39 @@
>
>
[patch snipped for brevity and also because it has been submitted in a
separate email]


This patch definitely helped stabilize the network. Thanks a lot for
looking into this and providing the patch.

However, I still see problems when I enable both WPA2 and power-save
on the clients.

Here is what I have tried so far:

30 802.11g clients

open mode + power save - no problems, can send data to all 30 for hrs
wpa2 + disable power save - no problems, can send data to all 30 for hrs
wpa2 + enable power save - clients connect but then randomly
disconnect every few seconds.

My delay in replying is due to this odd behavior I was seeing. It took
me a couple of days to figure out what was going on.


Any suggestions on where to look for this problem?

Thanks again,
- Harshal

Re: carl9170: Beacons at lower Tx power than data frames?

[Christian Lamparter]

On Saturday 23 July 2011 21:22:35 Harshal Chhaya wrote:
> On Fri, Jul 15, 2011 at 9:22 AM, Christian Lamparter
> <chunkeey@googlemail.com> wrote:
> > On Thursday 14 July 2011 21:37:29 Harshal Chhaya wrote:
> >> I am working on an AP design that uses a TI-OMAP3 host processor with
> >> an Atheros AR9170 + AR9101 WLAN chipset. We are currently using
> >> carl9170 version 1.9.2 and carl9170 firmware version 1.9.4.
> > One question: have you considered ath9k_htc? I would certainly recommend
> > it over any ar9170 device.
> 
> I was under the impression that AP mode support is better in carl9170
> than in ath9k_htc. I had considered using AR9271 (which is a more
> recent chipset than the AR9170) but decided against it based on my
> understanding (which is based on the info on the wiki pages).
Interesting... Sujith, can you please take a look at the wiki if ath9k_htc's AP/P2P
infos are still up to date?
 
> If AR9271 (and ath9k_htc) are more stable and preferable to the AR9170
> w/ carl9170, please let me know.
AR9271 recevied a lot more testing, so it's ought to perform better.

> Also, to clarify: my application is a wireless network that needs to
> support 60-70 802.11g clients connecting to the AP using WPA2-PEAP.
> All of the clients are battery powered and use the power save
> mechanisms of 802.11.
60-70 clients is a lot. This would rule out ath9k_htc since the firmwares
only supports 7/8 stations at a time and I think that's a reasonable limit
for any wireless network. Also, with so many stations the hardware crypto
will not have enough space to store all station keys and has to switch to
software de- and encryption. 
 
> Do you see any issues using AR9170 and carl9170 in this scenario?
Sorry, but I've no data about this scenario. However some time ago
Ben <greearb@candelatech.com> played around 128 stations on a ath9k
network. But I don't know if he tested any USB solutions at that time.
 
> Also, I am running openWRT on an TI-OMAP3 processor @ 600 MHz.
Any word about the USB hcd? Does it support sending unaligned data dma,
or is it necessary to align all buffer addresses to a 4-byte boundary?

> [...]
> The patch definitely helped stabilize the network. Thanks a lot for
> looking into this and providing the patch.
great, but it's a little to late for a tested-by tag. The patch is already on
its way to mainline ;).

> However, I still see problems when I enable both WPA2 and power-save
> on the clients.
> 
> Here is what I have tried so far:
> 
> 30 802.11g clients
> 
> open mode + power save - no problems, can send data to all 30 for hrs
> wpa2 + disable power save - no problems, can send data to all 30 for hrs
> wpa2 + enable power save - clients connect but then randomly
> disconnect every few seconds.
Is this with or without the hardware crypto enabled? Usually it's enabled by
default. But in your case I would give it a try to go without one. Just load
the module with:

nohwcrypt=1

this will help to rule out any hw limitations in this regard.

Regards,
	Chr

Re: carl9170: Beacons at lower Tx power than data frames?

[Harshal Chhaya]

On Sat, Jul 23, 2011 at 3:35 PM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Saturday 23 July 2011 21:22:35 Harshal Chhaya wrote:
>> On Fri, Jul 15, 2011 at 9:22 AM, Christian Lamparter
>> <chunkeey@googlemail.com> wrote:
>> > On Thursday 14 July 2011 21:37:29 Harshal Chhaya wrote:
>> >> I am working on an AP design that uses a TI-OMAP3 host processor with
>> >> an Atheros AR9170 + AR9101 WLAN chipset. We are currently using
>> >> carl9170 version 1.9.2 and carl9170 firmware version 1.9.4.
>> > One question: have you considered ath9k_htc? I would certainly recommend
>> > it over any ar9170 device.
>>
>> I was under the impression that AP mode support is better in carl9170
>> than in ath9k_htc. I had considered using AR9271 (which is a more
>> recent chipset than the AR9170) but decided against it based on my
>> understanding (which is based on the info on the wiki pages).
> Interesting... Sujith, can you please take a look at the wiki if ath9k_htc's AP/P2P
> infos are still up to date?

Thanks for following up on this. I am really interested to know if I
should switch to using the AR9271 (or some other similar chipset).

>
>> If AR9271 (and ath9k_htc) are more stable and preferable to the AR9170
>> w/ carl9170, please let me know.
> AR9271 recevied a lot more testing, so it's ought to perform better.
>
>> Also, to clarify: my application is a wireless network that needs to
>> support 60-70 802.11g clients connecting to the AP using WPA2-PEAP.
>> All of the clients are battery powered and use the power save
>> mechanisms of 802.11.
> 60-70 clients is a lot. This would rule out ath9k_htc since the firmwares
> only supports 7/8 stations at a time and I think that's a reasonable limit
> for any wireless network. Also, with so many stations the hardware crypto
> will not have enough space to store all station keys and has to switch to
> software de- and encryption.
>
>> Do you see any issues using AR9170 and carl9170 in this scenario?
> Sorry, but I've no data about this scenario. However some time ago
> Ben <greearb@candelatech.com> played around 128 stations on a ath9k
> network. But I don't know if he tested any USB solutions at that time.

I agree - ~8 clients is a reasonable number for most wireless
networks. However, I have a specific application where I need to
support 60-70 clients on a single AP. I will check with Ben on his
experience. Thanks for his contact info.


>> Also, I am running openWRT on an TI-OMAP3 processor @ 600 MHz.
> Any word about the USB hcd? Does it support sending unaligned data dma,
> or is it necessary to align all buffer addresses to a 4-byte boundary?

On the specific OMAP3 (the AM3703) in my design, all DMA buffers have
to be on a 4-byte boundary. This actually caused some problems for us
since we didn't know of this requirement and the openWRT release
didn't include this either. We had to merge the TI kernel (the 'arago'
project) with the openWRT release to get USB DMA working right.


>
>> [...]
>> The patch definitely helped stabilize the network. Thanks a lot for
>> looking into this and providing the patch.
> great, but it's a little to late for a tested-by tag. The patch is already on
> its way to mainline ;).

Sorry - like I said, I started seeing other problems and wanted to
track those down.


>> However, I still see problems when I enable both WPA2 and power-save
>> on the clients.
>>
>> Here is what I have tried so far:
>>
>> 30 802.11g clients
>>
>> open mode + power save - no problems, can send data to all 30 for hrs
>> wpa2 + disable power save - no problems, can send data to all 30 for hrs
>> wpa2 + enable power save - clients connect but then randomly
>> disconnect every few seconds.
> Is this with or without the hardware crypto enabled? Usually it's enabled by
> default. But in your case I would give it a try to go without one. Just load
> the module with:
>
> nohwcrypt=1
>
> this will help to rule out any hw limitations in this regard.

Since I don't explicitly disable hw crypto, it is probably enabled by default.

I will try disabling hw crypto to see if I can go beyond 30 clients.

Thanks again,
- Harshal


> Regards,
>        Chr
>

Re: carl9170: Beacons at lower Tx power than data frames?

[Ben Greear]

On 07/23/2011 02:18 PM, Harshal Chhaya wrote:
> On Sat, Jul 23, 2011 at 3:35 PM, Christian Lamparter
> <chunkeey@googlemail.com>  wrote:
>> On Saturday 23 July 2011 21:22:35 Harshal Chhaya wrote:
>>> On Fri, Jul 15, 2011 at 9:22 AM, Christian Lamparter
>>> <chunkeey@googlemail.com>  wrote:
>>>> On Thursday 14 July 2011 21:37:29 Harshal Chhaya wrote:
>>>>> I am working on an AP design that uses a TI-OMAP3 host processor with
>>>>> an Atheros AR9170 + AR9101 WLAN chipset. We are currently using
>>>>> carl9170 version 1.9.2 and carl9170 firmware version 1.9.4.
>>>> One question: have you considered ath9k_htc? I would certainly recommend
>>>> it over any ar9170 device.
>>>
>>> I was under the impression that AP mode support is better in carl9170
>>> than in ath9k_htc. I had considered using AR9271 (which is a more
>>> recent chipset than the AR9170) but decided against it based on my
>>> understanding (which is based on the info on the wiki pages).
>> Interesting... Sujith, can you please take a look at the wiki if ath9k_htc's AP/P2P
>> infos are still up to date?
>
> Thanks for following up on this. I am really interested to know if I
> should switch to using the AR9271 (or some other similar chipset).
>
>>
>>> If AR9271 (and ath9k_htc) are more stable and preferable to the AR9170
>>> w/ carl9170, please let me know.
>> AR9271 recevied a lot more testing, so it's ought to perform better.
>>
>>> Also, to clarify: my application is a wireless network that needs to
>>> support 60-70 802.11g clients connecting to the AP using WPA2-PEAP.
>>> All of the clients are battery powered and use the power save
>>> mechanisms of 802.11.
>> 60-70 clients is a lot. This would rule out ath9k_htc since the firmwares
>> only supports 7/8 stations at a time and I think that's a reasonable limit
>> for any wireless network. Also, with so many stations the hardware crypto
>> will not have enough space to store all station keys and has to switch to
>> software de- and encryption.
>>
>>> Do you see any issues using AR9170 and carl9170 in this scenario?
>> Sorry, but I've no data about this scenario. However some time ago
>> Ben<greearb@candelatech.com>  played around 128 stations on a ath9k
>> network. But I don't know if he tested any USB solutions at that time.
>
> I agree - ~8 clients is a reasonable number for most wireless
> networks. However, I have a specific application where I need to
> support 60-70 clients on a single AP. I will check with Ben on his
> experience. Thanks for his contact info.

We haven't used USB, but we can reliably support 128 stations,
using WPA on AR9380 and the older mini-pci chipsets.  We have hacks
to make wpa_supplicant be much more efficient when using lots
of virtual stations on one machine, but no significant changes
to AP mode.

Also, we are associating 128 virtual stations from a single or
small number of radios.  You may get different behaviour if you
are using 128 real radios.

You can find our hostap repository here:
https://github.com/greearb/hostap-ct

We are trying to get our changes pushed upstream, but it's a slow
process...

The 'can-scan-one' logic requires hacks to the kernel as well, in case
you want to use it.  Our kernel patches are here:
http://dmz2.candelatech.com/git/?p=linux-3.0.dev.y/.git;a=summary

I don't think any of our current kernel wireless patches have a chance at upstream
acceptance, but they are fairly minimal, so the stock 3.0 kernel might
be fine for you.

Our hardware is dual-core Atom systems or better, 1GB+ RAM, etc.  These are fairly powerful,
and we disable power saving by default.  We use software encryption to allow
virtualization.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: carl9170: Beacons at lower Tx power than data frames?

[Harshal Chhaya]

On Sat, Jul 23, 2011 at 11:34 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 07/23/2011 02:18 PM, Harshal Chhaya wrote:
>>
>> On Sat, Jul 23, 2011 at 3:35 PM, Christian Lamparter
>> <chunkeey@googlemail.com>  wrote:
>>>
>>> On Saturday 23 July 2011 21:22:35 Harshal Chhaya wrote:
>>>>
>>>> On Fri, Jul 15, 2011 at 9:22 AM, Christian Lamparter
>>>> <chunkeey@googlemail.com>  wrote:
>>>>>
>>>>> On Thursday 14 July 2011 21:37:29 Harshal Chhaya wrote:
>>>>>>
>>>>>> I am working on an AP design that uses a TI-OMAP3 host processor with
>>>>>> an Atheros AR9170 + AR9101 WLAN chipset. We are currently using
>>>>>> carl9170 version 1.9.2 and carl9170 firmware version 1.9.4.
>>>>>
>>>>> One question: have you considered ath9k_htc? I would certainly
>>>>> recommend
>>>>> it over any ar9170 device.
>>>>
>>>> I was under the impression that AP mode support is better in carl9170
>>>> than in ath9k_htc. I had considered using AR9271 (which is a more
>>>> recent chipset than the AR9170) but decided against it based on my
>>>> understanding (which is based on the info on the wiki pages).
>>>
>>> Interesting... Sujith, can you please take a look at the wiki if
>>> ath9k_htc's AP/P2P
>>> infos are still up to date?
>>
>> Thanks for following up on this. I am really interested to know if I
>> should switch to using the AR9271 (or some other similar chipset).
>>
>>>
>>>> If AR9271 (and ath9k_htc) are more stable and preferable to the AR9170
>>>> w/ carl9170, please let me know.
>>>
>>> AR9271 recevied a lot more testing, so it's ought to perform better.
>>>
>>>> Also, to clarify: my application is a wireless network that needs to
>>>> support 60-70 802.11g clients connecting to the AP using WPA2-PEAP.
>>>> All of the clients are battery powered and use the power save
>>>> mechanisms of 802.11.
>>>
>>> 60-70 clients is a lot. This would rule out ath9k_htc since the firmwares
>>> only supports 7/8 stations at a time and I think that's a reasonable
>>> limit
>>> for any wireless network. Also, with so many stations the hardware crypto
>>> will not have enough space to store all station keys and has to switch to
>>> software de- and encryption.
>>>
>>>> Do you see any issues using AR9170 and carl9170 in this scenario?
>>>
>>> Sorry, but I've no data about this scenario. However some time ago
>>> Ben<greearb@candelatech.com>  played around 128 stations on a ath9k
>>> network. But I don't know if he tested any USB solutions at that time.
>>
>> I agree - ~8 clients is a reasonable number for most wireless
>> networks. However, I have a specific application where I need to
>> support 60-70 clients on a single AP. I will check with Ben on his
>> experience. Thanks for his contact info.
>
> We haven't used USB, but we can reliably support 128 stations,
> using WPA on AR9380 and the older mini-pci chipsets.  We have hacks
> to make wpa_supplicant be much more efficient when using lots
> of virtual stations on one machine, but no significant changes
> to AP mode.

Ben,

Thanks for this information. Did you have to make any changes to
ath9k_htc on the AP side to support this large number of stations?

Also, any feedback on whether AR9380 (or AR971) chipset with ath9k_htc
is a better choice on the AP for a large network than the AR9170 +
carl9170 (which is what I am currently using)?


> Also, we are associating 128 virtual stations from a single or
> small number of radios.  You may get different behaviour if you
> are using 128 real radios.

Good point. I would guess that the memory mgmt and CPU load on the AP
will be similar in both cases - but the actual over-the-air packet
exchanges could be different.


> You can find our hostap repository here:
> https://github.com/greearb/hostap-ct

Is this a super-set of the patches at
http://www.candelatech.com/~greearb/patches/hostap-h/?


> We are trying to get our changes pushed upstream, but it's a slow
> process...
>
> The 'can-scan-one' logic requires hacks to the kernel as well, in case
> you want to use it.  Our kernel patches are here:
> http://dmz2.candelatech.com/git/?p=linux-3.0.dev.y/.git;a=summary

We are currently using the 2.6.37 kernel because later kernels don't
have support for my host processor (TI AM3703).

Also, based on your description of 'can-scan-one' (from the list
archives), I don't think it applies to my application since I don't
use virtual interfaces.

But I will take a look at your kernel patches to see which ones apply
to our config.

> I don't think any of our current kernel wireless patches have a chance at
> upstream
> acceptance, but they are fairly minimal, so the stock 3.0 kernel might
> be fine for you.
>
> Our hardware is dual-core Atom systems or better, 1GB+ RAM, etc.  These are
> fairly powerful,
> and we disable power saving by default.  We use software encryption to allow
> virtualization.

I am going to try s/w encryption but I can't disable power saving
since my clients are all battery powered. Also, my current h/w has
64MB of RAM - I have already asked the hardware guys to double it to
128. Hopefully that willl be enough.

Thanks again for your help. I will let you know if using software
encryption helps.

Thanks,
- Harshal


>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>

Re: carl9170: Beacons at lower Tx power than data frames?

[Ben Greear]

On 07/24/2011 09:04 AM, Harshal Chhaya wrote:
> On Sat, Jul 23, 2011 at 11:34 PM, Ben Greear<greearb@candelatech.com>  wrote:
>> On 07/23/2011 02:18 PM, Harshal Chhaya wrote:
>>>
>>> On Sat, Jul 23, 2011 at 3:35 PM, Christian Lamparter
>>> <chunkeey@googlemail.com>    wrote:
>>>>
>>>> On Saturday 23 July 2011 21:22:35 Harshal Chhaya wrote:
>>>>>
>>>>> On Fri, Jul 15, 2011 at 9:22 AM, Christian Lamparter
>>>>> <chunkeey@googlemail.com>    wrote:
>>>>>>
>>>>>> On Thursday 14 July 2011 21:37:29 Harshal Chhaya wrote:
>>>>>>>
>>>>>>> I am working on an AP design that uses a TI-OMAP3 host processor with
>>>>>>> an Atheros AR9170 + AR9101 WLAN chipset. We are currently using
>>>>>>> carl9170 version 1.9.2 and carl9170 firmware version 1.9.4.
>>>>>>
>>>>>> One question: have you considered ath9k_htc? I would certainly
>>>>>> recommend
>>>>>> it over any ar9170 device.
>>>>>
>>>>> I was under the impression that AP mode support is better in carl9170
>>>>> than in ath9k_htc. I had considered using AR9271 (which is a more
>>>>> recent chipset than the AR9170) but decided against it based on my
>>>>> understanding (which is based on the info on the wiki pages).
>>>>
>>>> Interesting... Sujith, can you please take a look at the wiki if
>>>> ath9k_htc's AP/P2P
>>>> infos are still up to date?
>>>
>>> Thanks for following up on this. I am really interested to know if I
>>> should switch to using the AR9271 (or some other similar chipset).
>>>
>>>>
>>>>> If AR9271 (and ath9k_htc) are more stable and preferable to the AR9170
>>>>> w/ carl9170, please let me know.
>>>>
>>>> AR9271 recevied a lot more testing, so it's ought to perform better.
>>>>
>>>>> Also, to clarify: my application is a wireless network that needs to
>>>>> support 60-70 802.11g clients connecting to the AP using WPA2-PEAP.
>>>>> All of the clients are battery powered and use the power save
>>>>> mechanisms of 802.11.
>>>>
>>>> 60-70 clients is a lot. This would rule out ath9k_htc since the firmwares
>>>> only supports 7/8 stations at a time and I think that's a reasonable
>>>> limit
>>>> for any wireless network. Also, with so many stations the hardware crypto
>>>> will not have enough space to store all station keys and has to switch to
>>>> software de- and encryption.
>>>>
>>>>> Do you see any issues using AR9170 and carl9170 in this scenario?
>>>>
>>>> Sorry, but I've no data about this scenario. However some time ago
>>>> Ben<greearb@candelatech.com>    played around 128 stations on a ath9k
>>>> network. But I don't know if he tested any USB solutions at that time.
>>>
>>> I agree - ~8 clients is a reasonable number for most wireless
>>> networks. However, I have a specific application where I need to
>>> support 60-70 clients on a single AP. I will check with Ben on his
>>> experience. Thanks for his contact info.
>>
>> We haven't used USB, but we can reliably support 128 stations,
>> using WPA on AR9380 and the older mini-pci chipsets.  We have hacks
>> to make wpa_supplicant be much more efficient when using lots
>> of virtual stations on one machine, but no significant changes
>> to AP mode.
>
> Ben,
>
> Thanks for this information. Did you have to make any changes to
> ath9k_htc on the AP side to support this large number of stations?
>
> Also, any feedback on whether AR9380 (or AR971) chipset with ath9k_htc
> is a better choice on the AP for a large network than the AR9170 +
> carl9170 (which is what I am currently using)?

We've had good luck with the AR9380, once we force it to have a proper
reg-domain.  We don't use ath9k_htc as far as I know.

Our main testing is with client-mode and lots of virtual clients:  We
just use AP mode to run the clients against mostly...

>> Also, we are associating 128 virtual stations from a single or
>> small number of radios.  You may get different behaviour if you
>> are using 128 real radios.
>
> Good point. I would guess that the memory mgmt and CPU load on the AP
> will be similar in both cases - but the actual over-the-air packet
> exchanges could be different.
>
>
>> You can find our hostap repository here:
>> https://github.com/greearb/hostap-ct
>
> Is this a super-set of the patches at
> http://www.candelatech.com/~greearb/patches/hostap-h/?

I think so, currently.  But, we update and rebase against upstream
every now and then.  At any rate, the hostap-ct repo is what we use
for our actual testing.

If you do end up using our tree, bug reports and patches are welcome.

>> We are trying to get our changes pushed upstream, but it's a slow
>> process...
>>
>> The 'can-scan-one' logic requires hacks to the kernel as well, in case
>> you want to use it.  Our kernel patches are here:
>> http://dmz2.candelatech.com/git/?p=linux-3.0.dev.y/.git;a=summary
>
> We are currently using the 2.6.37 kernel because later kernels don't
> have support for my host processor (TI AM3703).

We saw a lot of flakiness in older kernels (basically, I would
suspect anything before 3.0 unless perhaps if you have all of
the stable patches from .37, .38 and .39 applied.  No one is automatically
backporting patches to .37 still, I think..so you'd have to dig them out
yourself...

Might be worth the effort to get 3.0 working on your processor instead
of trying to backport wireless fixes.

>
> Also, based on your description of 'can-scan-one' (from the list
> archives), I don't think it applies to my application since I don't
> use virtual interfaces.
>
> But I will take a look at your kernel patches to see which ones apply
> to our config.
>
>> I don't think any of our current kernel wireless patches have a chance at
>> upstream
>> acceptance, but they are fairly minimal, so the stock 3.0 kernel might
>> be fine for you.
>>
>> Our hardware is dual-core Atom systems or better, 1GB+ RAM, etc.  These are
>> fairly powerful,
>> and we disable power saving by default.  We use software encryption to allow
>> virtualization.
>
> I am going to try s/w encryption but I can't disable power saving
> since my clients are all battery powered. Also, my current h/w has
> 64MB of RAM - I have already asked the hardware guys to double it to
> 128. Hopefully that willl be enough.
>
> Thanks again for your help. I will let you know if using software
> encryption helps.

I doubt that software encryption will help in your case...and if it does,
it's probably due to a bug somewhere, but it's surely worth a try.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: carl9170: Beacons at lower Tx power than data frames?

[Harshal Chhaya]

On Sat, Jul 23, 2011 at 3:35 PM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Saturday 23 July 2011 21:22:35 Harshal Chhaya wrote:
>> On Fri, Jul 15, 2011 at 9:22 AM, Christian Lamparter
>> <chunkeey@googlemail.com> wrote:
>> > On Thursday 14 July 2011 21:37:29 Harshal Chhaya wrote:
>> >> I am working on an AP design that uses a TI-OMAP3 host processor with
>> >> an Atheros AR9170 + AR9101 WLAN chipset. We are currently using
>> >> carl9170 version 1.9.2 and carl9170 firmware version 1.9.4.
>> > One question: have you considered ath9k_htc? I would certainly recommend
>> > it over any ar9170 device.
>>
>> I was under the impression that AP mode support is better in carl9170
>> than in ath9k_htc. I had considered using AR9271 (which is a more
>> recent chipset than the AR9170) but decided against it based on my
>> understanding (which is based on the info on the wiki pages).
> Interesting... Sujith, can you please take a look at the wiki if ath9k_htc's AP/P2P
> infos are still up to date?

Sujith, Christian,

On the wiki page for carl9170, the first item in the "not working yet" list is:
* Power Save Mode, It's implemented but buggy

Is this still the case?

I am seeing clients disconnect after a few seconds when I enable power
saving on the clients. I can send more details if needed.


>> If AR9271 (and ath9k_htc) are more stable and preferable to the AR9170
>> w/ carl9170, please let me know.
> AR9271 recevied a lot more testing, so it's ought to perform better.
>
>> Also, to clarify: my application is a wireless network that needs to
>> support 60-70 802.11g clients connecting to the AP using WPA2-PEAP.
>> All of the clients are battery powered and use the power save
>> mechanisms of 802.11.
> 60-70 clients is a lot. This would rule out ath9k_htc since the firmwares
> only supports 7/8 stations at a time and I think that's a reasonable limit
> for any wireless network. Also, with so many stations the hardware crypto
> will not have enough space to store all station keys and has to switch to
> software de- and encryption.
>
>> Do you see any issues using AR9170 and carl9170 in this scenario?
> Sorry, but I've no data about this scenario. However some time ago
> Ben <greearb@candelatech.com> played around 128 stations on a ath9k
> network. But I don't know if he tested any USB solutions at that time.
>
>> Also, I am running openWRT on an TI-OMAP3 processor @ 600 MHz.
> Any word about the USB hcd? Does it support sending unaligned data dma,
> or is it necessary to align all buffer addresses to a 4-byte boundary?
>
>> [...]
>> Here is what I have tried so far:
>>
>> 30 802.11g clients
>>
>> open mode + power save - no problems, can send data to all 30 for hrs
>> wpa2 + disable power save - no problems, can send data to all 30 for hrs
>> wpa2 + enable power save - clients connect but then randomly
>> disconnect every few seconds.
> Is this with or without the hardware crypto enabled? Usually it's enabled by
> default. But in your case I would give it a try to go without one. Just load
> the module with:
>
> nohwcrypt=1
>
> this will help to rule out any hw limitations in this regard.

Thanks for this suggestion. With h/w crypto enabled, I was limited to
32 clients. With 'nohwcrypt=1', I can connect up to 50 clients
(haven't tried more).

However - I am curious about the limit of 32. The chip itself supports
keys for up to 64 users (i.e. a total of 128 keys). I didn't see any
obvious pieces of the carl9170 code that limited this number to 32.

I first thought that the 'u64 usedkeys;' field in the ar9170 struct
(carl9170.h) limited me to 32 users (each user took up two bits - one
for tx, one for rx). But that doesn't seem to be the case.
Any ideas why I couldn't go beyond 32 when I used h/w encryption?

Thanks,
- Harshal


> Regards,
>        Chr

Re: carl9170: Beacons at lower Tx power than data frames?

[Christian Lamparter]

On Thursday, July 28, 2011 06:18:09 PM Harshal Chhaya wrote:
> Sujith, Christian,
> 
> On the wiki page for carl9170, the first item in the "not working yet" list is:
> * Power Save Mode, It's implemented but buggy
> 
> Is this still the case?
>
> I am seeing clients disconnect after a few seconds when I enable power
> saving on the clients. I can send more details if needed.
Oh no, unless of course your failing clients are also running carl9170.
Take a look at 802.11-2007 11.2 for an explantation. APs usually don't
do any PSM.  
 

> >> Here is what I have tried so far:
> >>
> >> 30 802.11g clients
> >>
> >> open mode + power save - no problems, can send data to all 30 for hrs
> >> wpa2 + disable power save - no problems, can send data to all 30 for hrs
> >> wpa2 + enable power save - clients connect but then randomly
> >> disconnect every few seconds.
> > Is this with or without the hardware crypto enabled? Usually it's enabled by
> > default. But in your case I would give it a try to go without one. Just load
> > the module with:
> >
> > nohwcrypt=1
> >
> > this will help to rule out any hw limitations in this regard.
> 
> However - I am curious about the limit of 32. The chip itself supports
> keys for up to 64 users (i.e. a total of 128 keys). I didn't see any
> obvious pieces of the carl9170 code that limited this number to 32.
well, the second "user" is currently only used by the tkip mic. If you
are only using ccmp you may be able to utilize the second slot as well.
However this requires a more sophisticated key-management in the driver.

Regards,
	Chr

Re: carl9170: Beacons at lower Tx power than data frames?

[Harshal Chhaya]

On Thu, Jul 28, 2011 at 11:49 AM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Thursday, July 28, 2011 06:18:09 PM Harshal Chhaya wrote:
>> Sujith, Christian,
>>
>> On the wiki page for carl9170, the first item in the "not working yet" list is:
>> * Power Save Mode, It's implemented but buggy
>>
>> Is this still the case?
>>
>> I am seeing clients disconnect after a few seconds when I enable power
>> saving on the clients. I can send more details if needed.
> Oh no, unless of course your failing clients are also running carl9170.
> Take a look at 802.11-2007 11.2 for an explantation. APs usually don't
> do any PSM.

Sorry - looks like I misread the statement.  I didn't realize it
applied only for STA mode.

To clarify, my clients are not running carl9170 - only my AP is.

But I am seeing a definite problem with network stability when I
enable power saving on my clients. The clients work as expected with
another off-the-shelf AP.

Could you tell me how to enable debug output in carl9170? I would like
to better understand what's going on in the carl9170 driver/firmware
when I see these disconnects.

I found the 'ath_debug_level' enum in ath.h but don't know how to use
this with carl9170.


>> >> Here is what I have tried so far:
>> >>
>> >> 30 802.11g clients
>> >>
>> >> open mode + power save - no problems, can send data to all 30 for hrs
>> >> wpa2 + disable power save - no problems, can send data to all 30 for hrs
>> >> wpa2 + enable power save - clients connect but then randomly
>> >> disconnect every few seconds.
>> > Is this with or without the hardware crypto enabled? Usually it's enabled by
>> > default. But in your case I would give it a try to go without one. Just load
>> > the module with:
>> >
>> > nohwcrypt=1
>> >
>> > this will help to rule out any hw limitations in this regard.
>>
>> However - I am curious about the limit of 32. The chip itself supports
>> keys for up to 64 users (i.e. a total of 128 keys). I didn't see any
>> obvious pieces of the carl9170 code that limited this number to 32.
>
> well, the second "user" is currently only used by the tkip mic. If you
> are only using ccmp you may be able to utilize the second slot as well.
> However this requires a more sophisticated key-management in the driver.

All of my clients use CCMP. Which file/function do I look at to see
what it would take to use all 64 key entries for CCMP?

Thanks,
- Harshal

Re: carl9170: Beacons at lower Tx power than data frames?

[Christian Lamparter]

On Thursday, July 28, 2011 08:57:01 PM Harshal Chhaya wrote:
> On Thu, Jul 28, 2011 at 11:49 AM, Christian Lamparter
> <chunkeey@googlemail.com> wrote:
> > On Thursday, July 28, 2011 06:18:09 PM Harshal Chhaya wrote:
> >> Sujith, Christian,
> >>
> >> On the wiki page for carl9170, the first item in the "not working yet" list is:
> >> * Power Save Mode, It's implemented but buggy
> >>
> >> Is this still the case?
> >>
> >> I am seeing clients disconnect after a few seconds when I enable power
> >> saving on the clients. I can send more details if needed.
> > Oh no, unless of course your failing clients are also running carl9170.
> > Take a look at 802.11-2007 11.2 for an explantation. APs usually don't
> > do any PSM.
> 
> But I am seeing a definite problem with network stability when I
> enable power saving on my clients. The clients work as expected with
> another off-the-shelf AP.
Well, there are several different ps schemes [legacy ps, aspd and u-aspd]
and each implementation might differ in this regard. So, this is always a
bit of a apple and orange comparision... unless of course your off-the-shelf
AP uses the same mac80211 stack and just a different driver
[e.g.: ath9k(_htc)/iwlagn/p54/b43]

> Could you tell me how to enable debug output in carl9170? I would like
> to better understand what's going on in the carl9170 driver/firmware
> when I see these disconnects.
There's no such switch in the driver or firmware. But because the driver
relies on mac80211 to do the actual management, you can enable a few
options there:

CONFIG_MAC80211_VERBOSE_PS_DEBUG [dmesg]
CONFIG_MAC80211_DEBUGFS [/sys/kernel/debug/ieee80211/phyX/]

http://linuxwireless.org/en/developers/Documentation/mac80211/tracing

> All of my clients use CCMP. Which file/function do I look at to see
> what it would take to use all 64 key entries for CCMP?
drivers/net/wireless/ath/carl9170/main.c / carl9170_op_set_key

Regards,
	Christian