Re: [ath9k-devel] [RFC] ath9k: validate for non-zero BSSID
On Wednesday 30 November 2011 12:17 PM, Kalle Valo wrote: > Mohammed Shafi Shajakhan writes: > >> unassociated state for station. >> >> but I observed this when i tested ad-hoc mode. I just started an >> ad-hoc mode creator and left it for some time with no one joining. i >> observed there are few frames in rx_tasklet of ath9k driver which seem >> to be beacons and their BSSID is '0', as our curbssid is also '0' they >> seem to be wrongly identified as 'my_beacons'. > > This is a perfect addition to the commit log. Remember that the commit > log should especially answer the question "why?". > Kalle, thanks. I will properly test this in STA and IBSS mode, and add this commit log. -- thanks, shafi ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC] ath9k: validate for non-zero BSSID
Mohammed Shafi Shajakhan writes: > unassociated state for station. > > but I observed this when i tested ad-hoc mode. I just started an > ad-hoc mode creator and left it for some time with no one joining. i > observed there are few frames in rx_tasklet of ath9k driver which seem > to be beacons and their BSSID is '0', as our curbssid is also '0' they > seem to be wrongly identified as 'my_beacons'. This is a perfect addition to the commit log. Remember that the commit log should especially answer the question "why?". -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC] ath9k: validate for non-zero BSSID
Hi Peter, On Wednesday 30 November 2011 08:06 AM, Peter Stuge wrote: > Mohammed Shafi Shajakhan wrote: >> before concluding that the recieved beacon is for us, let us make sure >> that the BSSID is non-zero. > > Under what circumstances would the BSSID be zero? > > > //Peter unassociated state for station. but I observed this when i tested ad-hoc mode. I just started an ad-hoc mode creator and left it for some time with no one joining. i observed there are few frames in rx_tasklet of ath9k driver which seem to be beacons and their BSSID is '0', as our curbssid is also '0' they seem to be wrongly identified as 'my_beacons'. let me also verify it in STA mode and find the effect of this before sending it as a PATCH. let me also check if it has any effect in ath9k_process_rssi and ath_rx_ps. -- thanks, shafi ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Stuck TX DMA
On 30 November 2011 10:35, Peter Stuge wrote: > Adrian Chadd wrote: >> * wait for the TX DMA to complete (and hope it does, rather than get stuck); > > Under what circumstances does DMA typically get stuck in your > experience? On FreeBSD? I only get that when doing channel scans. I haven't figured out why though (and it's not a big deal as FreeBSD doesn't do fast channel change, so a full reset is fine.) I haven't seen it happen in normal everyday hostap mode or STA mode when not scanning. I'll do some digging once I've finished off the FreeBSD atheros 11n changes. (Yes, I have 11n working in FreeBSD now..) Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC] ath9k: validate for non-zero BSSID
Mohammed Shafi Shajakhan wrote: > before concluding that the recieved beacon is for us, let us make sure > that the BSSID is non-zero. Under what circumstances would the BSSID be zero? //Peter ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Stuck TX DMA
Adrian Chadd wrote: > * wait for the TX DMA to complete (and hope it does, rather than get stuck); Under what circumstances does DMA typically get stuck in your experience? //Peter ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] ath9k: change the default antenna settings based on diversity
From: Mohammed Shafi Shajakhan
change the AR_DEF_ANTENNA register settings i.e setting default antenna
setting only for antenna diversity enabled chipsets. no point in
doing this for MIMO chipsets
Signed-off-by: Mohammed Shafi Shajakhan
---
drivers/net/wireless/ath/ath9k/recv.c | 23 ++-
1 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c
b/drivers/net/wireless/ath/ath9k/recv.c
index 4c8e296..b1b0ec7 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -1923,15 +1923,20 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush,
bool hp)
skb = hdr_skb;
}
- /*
-* change the default rx antenna if rx diversity chooses the
-* other antenna 3 times in a row.
-*/
- if (sc->rx.defant != rs.rs_antenna) {
- if (++sc->rx.rxotherant >= 3)
- ath_setdefantenna(sc, rs.rs_antenna);
- } else {
- sc->rx.rxotherant = 0;
+
+ if (ah->caps.hw_caps & ATH9K_HW_CAP_ANT_DIV_COMB) {
+
+ /*
+* change the default rx antenna if rx diversity
+* chooses the other antenna 3 times in a row.
+*/
+ if (sc->rx.defant != rs.rs_antenna) {
+ if (++sc->rx.rxotherant >= 3)
+ ath_setdefantenna(sc, rs.rs_antenna);
+ } else {
+ sc->rx.rxotherant = 0;
+ }
+
}
if (rxs->flag & RX_FLAG_MMIC_STRIPPED)
--
1.7.0.4
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] ath9k: Fix LED GPIO pin for AR9462
From: Mohammed Shafi Shajakhan GPIO pin 4 is assigned AR9462 chipsets LED. while GPIO pin 0 worked for obselete AR9462 chipsets though they are meant for EEPROM as per Russell Cc: Senthil Balasubramanian Signed-off-by: Russell Hu Signed-off-by: Mohammed Shafi Shajakhan --- drivers/net/wireless/ath/ath9k/ath9k.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h index 93b45b4..386402c 100644 --- a/drivers/net/wireless/ath/ath9k/ath9k.h +++ b/drivers/net/wireless/ath/ath9k/ath9k.h @@ -462,7 +462,7 @@ void ath9k_btcoex_timer_pause(struct ath_softc *sc); #define ATH_LED_PIN_9287 8 #define ATH_LED_PIN_9300 10 #define ATH_LED_PIN_9485 6 -#define ATH_LED_PIN_9462 0 +#define ATH_LED_PIN_9462 4 #ifdef CONFIG_MAC80211_LEDS void ath_init_leds(struct ath_softc *sc); -- 1.7.0.4 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [RFC] ath9k: validate for non-zero BSSID
From: Mohammed Shafi Shajakhan before concluding that the recieved beacon is for us, let us make sure that the BSSID is non-zero. Signed-off-by: Mohammed Shafi Shajakhan --- drivers/net/wireless/ath/ath9k/recv.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c index 4c8e296..620230d 100644 --- a/drivers/net/wireless/ath/ath9k/recv.c +++ b/drivers/net/wireless/ath/ath9k/recv.c @@ -1824,6 +1824,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp) hdr = (struct ieee80211_hdr *) (hdr_skb->data + rx_status_len); rxs = IEEE80211_SKB_RXCB(hdr_skb); if (ieee80211_is_beacon(hdr->frame_control) && + !is_zero_ether_addr(common->curbssid) && !compare_ether_addr(hdr->addr3, common->curbssid)) rs.is_mybeacon = true; else -- 1.7.0.4 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Re : Sinding A-MPDU
.. hm. If edma is true, then you're using an AR9300 or later series NIC. I have no idea (yet) about how the EDMA stuff works for the AR9300 and later MAC/PCU. Sorry. :) MPDUs aren't delivered to the hardware at transmission time. They're delivered before the transmission time. Otherwise throughput is going to be quite a bit lower than maximum. The software aggregation queue code will queue upto N (=2?) aggregate frames to the hardware, to ensure the TX FIFO is kept busy and thus the MAC keeps transmitting frames. At low frame rates, you'll be queuing frames just before transmission time because the hardware TX'es aggregate frames very quickly. But the minute you start doing more than a few tens of frames a second (which you can calculate with some reasonably simple modelling), depending upon how busy your air is (ie, how often it can actually get the air and start TX'ing), you'll soon find you can queue frames faster than the hardware can squeeze them into the air. Doubly so if it's also doing RX. Note: the RX timestamp in my traces (why are you looking there? those are for failures.. :) are done by the MAC, not the OS. Again, your problem is going to be knowing if the hardware has begun transmitting the A-MPDU or not. You can't just assume that you can fondle with the TX frame chain at any stage - once it's passed to the hardware, I think the only way you can _reliably_ achieve what you're doing is: * shut down TX DMA; * wait for the TX DMA to complete (and hope it does, rather than get stuck); * investigate whether your A-MPDU has been TX'ed or not. * Fondle with the descriptor/ring buffer, again I don't know EDMA; * restart TX DMA. You can't just check "is the TX DMA (TXDP) pointer pointing at my entry or before it? (or the EDMA equivalent)" because by the time that check has run, the hardware may have begun TX'ing whilst your check is running. To answer the rest of your question - you can find all the bits you need in ath9k/xmit.c to figure out exactly how/when an A-MPDU frame is created and queued to the hardware. Just keep in mind it queues >1 (up to a maximum of two) and then queues another the minute that it gets notification of the completion of the first A-MPDU. So hopefully the MAC/PCU is always TX'ing an A-MPDU ahead of what the software is queuing. Good luck! Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] About ieee80211.h
Hi all,
I have some question related to defined value. In ieee80211.h there is
#define IEEE80211_QOS_CTL_ACK_POLICY_NORMAL 0x
#define IEEE80211_QOS_CTL_ACK_POLICY_NOACK 0x0020
#define IEEE80211_QOS_CTL_ACK_POLICY_NO_EXPL0x0040
#define IEEE80211_QOS_CTL_ACK_POLICY_BLOCKACK 0x0060
But there is none of the any other void try to call the following 3 deintions
(what i mean is that they are never used)
IEEE80211_QOS_CTL_ACK_POLICY_NORMAL,
IEEE80211_QOS_CTL_ACK_POLICY_NO_EXPL,
IEEE80211_QOS_CTL_ACK_POLICY_BLOCKACK
in the whole driver folder. And for the IEEE80211_QOS_CTL_ACK_POLICY_NOACK
it appears in wme.c in the following function.
void ieee80211_set_qos_hdr(struct ieee80211_local *local, struct sk_buff
*skb)
{
struct ieee80211_hdr *hdr = (void *)skb->data;
/* Fill in the QoS header if there is one. */
if (ieee80211_is_data_qos(hdr->frame_control)) {
u8 *p = ieee80211_get_qos_ctl(hdr);
u8 ack_policy = 0, tid;
tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
if (unlikely(local->wifi_wme_noack_test))
ack_policy |= IEEE80211_QOS_CTL_ACK_POLICY_NOACK;
/* qos header is 2 bytes, second reserved */
*p++ = ack_policy | tid;
*p = 0;
}
}
I am just wondering how to modify the policy if there is only one policy
that is in operation. When I used raw socket to send out packet, the
policy that filled in side the packet is "normal ack".
For normal ACK, there is 0 in the QoS header, and u8 ack_policy = 0
implies normal ACK. But when I modify this void by adding a line after the
"tid= ..."
ack_policy|=IEEE80211_QOS_CTL_ACK_POLICY_NOACK ;
And compile the driver again, it doesn't do me a favour.
Actually my target is to set a policy that all qos data from normal_ack
packet to no_ack. Or am i in wrong direction? Thanks for help.
Regards,
Jax
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Re : Sinding A-MPDU
Thank you a lot for your answer. I am aware about the A-MPDU size constraint. Data exceeding the announced size will be considered as noise. This is not a problem! I do not use RTS/CTS I will disable the use of the Block ack. I do not need any feedback policy! When I saw your example : http://people.freebsd.org/~adrian/pcap4-ampdu-tx-dup.pcapI understood that the hardware does not wait the reception end of the entire A-MPDU to deliver the received MPDUs to the upper layer. Each MPDU is delivered once it is received (conclusion made based on the reception time in your example). That is why I am saying "may be" the same thing is done for the transmission: MPDUs are stored somewhere by the driver and delivered to the hardware at the transmission time. If this is the case, then may be I can deliver the priority frame instead of the 6th frame, and afterward I deliver the 6th to the 9th frames and I cancel the 10th frame since it will be considered as noise. However I do not see where the driver asks the hardware to start transmitting an A-MPDU. The function "ath_tx_send_ampdu()" calls "ath_tx_txqaddbuf()" which will never call "ath9k_hw_txstart()" since "edma" is always "True". And I do not see any place else where the driver may ask the hardware to start transmitting an A-MPDU. Do you have any idea about this? Regards, > Hi all, > I have some questions concerning the transmission of an A-MPDUs using ath9k: > * If we aggregate several MPDUs, say 10 MPDUs, into an A-MPDU and send them > to receiver "R1". And during the transmission of this A-MPDU, a priority > frame, say "Fp", comes from the upper layer and should be transmitted > urgently to "R1". Let suppose that the 5th MPDU is being transmitted when > the frame "Fp" comes. Is it possible to insert "Fp" into the A-MPDU in the > 6th position and send it without waiting the transmission end of the current > A-MPDU? The aggregate field has a "total length" field in the first frame, so I think you may confuse the hardware. There's no guarantee that you'll be able to sneak in that frame before the hardware reads the next/last descriptor, so you may have it sometimes TX and sometimes not. If RTS/CTS protection is being used then you've already announced how long the aggregate frame is, so you'd be breaking the spec by adding to it. There's no guarantee that priority frame will be within the block-ack window (or that it should even be -in- an aggregate - eg, a null data frame) so you may not want to aggregate it anyway. > * What is the difference between the hardware transmission queue and the > software transmission queue? Do I have the choice to use the software queue > instead of the hardware queue, or is the software queue and intermediate > queue and any frame will end in the hardware queue? > Best regard The hardware queue is for frames that are actually pending to the hardware. Ie, the descriptors are setup in the relevant ring/chain (depending upon your chipset) and the hardware will eventually TX those. The software queue is a staging ground for what is put into the hardware queue. It gives the aggregation logic time to figure out what/how to aggregate and allows for out of order transmission and software retransmit (however strictly speaking these latter two can be done without a software queue..) There's also the CAB and multicast queues - the multicast queue is a software queue; a staging ground for what goes into the hardware CAB queue just before the beacon goes out. Adrian On 28 November 2011 22:24, daldoul yousri wrote: ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] ar9390 failing AGC calibration on powerpc platform
Hi, I have been trying to get my ar9390 based wlan module to work as an AP on my powerpc target. There seems to be some issues with AGC calibration though. As soon as I start hostapd, I get the following: ath9k :01:00.0: mon.wlan0: Features changed: 0x4800 -> 0x4000 ath: Unable to reset hardware; reset status -5 (freq 2412 MHz) Could not set interface mon.wlan0 flags: Input/output error nl80211: Failed to set interface wlan0 into AP mode nl80211 driver initialization failed. ELOOP: remaining socket: sock=8 eloop_data=0x10219770 user_data=0x10219d18 handler=0x1002b8c0 ELOOP: remaining socket: sock=10 eloop_data=0x1021c0b8 user_data=(nil) handler=0x100353e0 Further debugging revealed that the problem was AGC calibration that didn't finish and that can be seen from the logs too: ath: timeout (10 us) on reg 0xa2c4: 0x00158dd9 & 0x0001 != 0x I moved that module to x86 ubuntu 11.10 pc to see if it works there. For my surprise it worked just fine. So it seems that there is something related to powerpc platform. I'm using kernel 2.6.39 and compat wireless drivers from november. Would it be possible that there is some endianess stuff somewhere that isn't handled properly? ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
