headers
Nick Kossifidis | 1 Nov 07:53
Picon
Gravatar

Re: ath5k AP issues

2009/10/31 Bob Copeland <me@...>:
> On Thu, Oct 29, 2009 at 02:31:46PM +0100, Michael Buesch wrote:
>> Ok, to sum up some discussion from IRC:
>>
>> The initial packets that fail are not pings, but ARPs. Which are broadcast
>> frames.  The access point simply fails to notify the station via DTIM for the
>> pending multicast frames, so it stays in PS. Unicast and the corresponding
>> TIM bitmap works properly, which also explains why it works once we got a
>> successful ARP (and it didn't expire, yet).
>
> I don't think this fixes everything (I'm still seeing some mishandled
> PS-poll frames) but this seemed to help pinging the PS client from the AP
> side.
>
> [Although we agreed beacon-sent-gated without a ready time component
> is the right way to go on the queue configuration, it seems badly
> broken in practice unless I'm missing some enable bit somewhere.  So
> this is what ath9k does.]
>

Well ready time is not disabled right now !

416                         ath5k_hw_reg_write(ah, ((AR5K_TUNE_BEACON_INTERVAL -
417                                 (AR5K_TUNE_SW_BEACON_RESP -
418                                 AR5K_TUNE_DMA_BEACON_RESP) -
419                                 AR5K_TUNE_ADDITIONAL_SWBA_BACKOFF) * 1024) |
420                                 AR5K_QCU_RDYTIMECFG_ENABLE,
421                                 AR5K_QUEUE_RDYTIMECFG(queue));

notice the AR5K_QCU_RDYTIMECFG_ENABLE. So it's probable that the queue
(Continue reading)

Permalink | Reply | 8 comments |
headers
Nick Kossifidis | 1 Nov 07:56
Picon
Gravatar

Re: ath5k AP issues

2009/11/1 Nick Kossifidis <mickflemm@...>:
> 2009/10/31 Bob Copeland <me@...>:
>> On Thu, Oct 29, 2009 at 02:31:46PM +0100, Michael Buesch wrote:
>>> Ok, to sum up some discussion from IRC:
>>>
>>> The initial packets that fail are not pings, but ARPs. Which are broadcast
>>> frames.  The access point simply fails to notify the station via DTIM for the
>>> pending multicast frames, so it stays in PS. Unicast and the corresponding
>>> TIM bitmap works properly, which also explains why it works once we got a
>>> successful ARP (and it didn't expire, yet).
>>
>> I don't think this fixes everything (I'm still seeing some mishandled
>> PS-poll frames) but this seemed to help pinging the PS client from the AP
>> side.
>>
>> [Although we agreed beacon-sent-gated without a ready time component
>> is the right way to go on the queue configuration, it seems badly
>> broken in practice unless I'm missing some enable bit somewhere.  So
>> this is what ath9k does.]
>>
>
> Well ready time is not disabled right now !
>
> 416                         ath5k_hw_reg_write(ah, ((AR5K_TUNE_BEACON_INTERVAL -
> 417                                 (AR5K_TUNE_SW_BEACON_RESP -
> 418                                 AR5K_TUNE_DMA_BEACON_RESP) -
> 419                                 AR5K_TUNE_ADDITIONAL_SWBA_BACKOFF) * 1024) |
> 420                                 AR5K_QCU_RDYTIMECFG_ENABLE,
> 421                                 AR5K_QUEUE_RDYTIMECFG(queue));
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jouni Malinen | 1 Nov 10:18
Picon

[PATCH] cfg80211: Fix WEXT compat siwauth wpa and group cipher

Neither of these commands should clear the current configuration value
if they return error. Furthermore, cfg80211_set_cipher_group() should
be able to handle IW_AUTH_CIPHER_NONE without reporting error.

Signed-off-by: Jouni Malinen <j <at> w1.fi>

---
 net/wireless/wext-compat.c |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

--- uml.orig/net/wireless/wext-compat.c	2009-11-01 10:54:56.000000000 +0200
+++ uml/net/wireless/wext-compat.c	2009-11-01 10:58:45.000000000 +0200
@@ -904,8 +904,6 @@ static int cfg80211_set_auth_alg(struct 

 static int cfg80211_set_wpa_version(struct wireless_dev *wdev, u32 wpa_versions)
 {
-	wdev->wext.connect.crypto.wpa_versions = 0;
-
 	if (wpa_versions & ~(IW_AUTH_WPA_VERSION_WPA |
 			     IW_AUTH_WPA_VERSION_WPA2|
 		             IW_AUTH_WPA_VERSION_DISABLED))
@@ -933,8 +931,6 @@ static int cfg80211_set_wpa_version(stru

 static int cfg80211_set_cipher_group(struct wireless_dev *wdev, u32 cipher)
 {
-	wdev->wext.connect.crypto.cipher_group = 0;
Permalink | Reply | 0 comments |
headers
Jouni Malinen | 1 Nov 10:30
Picon

[PATCH] mac80211_hwsim: Check idle state on TX

Track the idle state for hwsim radios and reject TX if mac80211 is
trying to transmit something when the radio is supposed to be idle. In
addition, do not deliver frames if the receiving radio is in the idle
state.

Signed-off-by: Jouni Malinen <j <at> w1.fi>

---
 drivers/net/wireless/mac80211_hwsim.c |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

--- uml.orig/drivers/net/wireless/mac80211_hwsim.c	2009-10-01 17:06:49.000000000 +0300
+++ uml/drivers/net/wireless/mac80211_hwsim.c	2009-10-01 17:22:15.000000000 +0300
@@ -284,7 +284,7 @@ struct mac80211_hwsim_data {
 	struct ieee80211_channel *channel;
 	unsigned long beacon_int; /* in jiffies unit */
 	unsigned int rx_filter;
-	int started;
+	bool started, idle;
 	struct timer_list beacon_timer;
 	enum ps_mode {
 		PS_DISABLED, PS_ENABLED, PS_AUTO_POLL, PS_MANUAL_POLL
@@ -402,6 +402,12 @@ static bool mac80211_hwsim_tx_frame(stru
 	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
 	struct ieee80211_rx_status rx_status;

+	if (data->idle) {
+		printk(KERN_DEBUG "%s: Trying to TX when idle - reject\n",
+		       wiphy_name(hw->wiphy));
+		return false;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jouni Malinen | 1 Nov 10:31
Picon

[PATCH] mac80211_hwsim: Send ACK frames on the hwsim0 interface

Report successful transmissions (receiver awake and on the same
channel) by generating ACK frames on the hwsim0 interface. This makes
it easier to figure out from packet capture logs whether frames were
delivered or not.

Signed-off-by: Jouni Malinen <j <at> w1.fi>

---
 drivers/net/wireless/mac80211_hwsim.c |   47 ++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

--- uml.orig/drivers/net/wireless/mac80211_hwsim.c	2009-10-01 17:22:15.000000000 +0300
+++ uml/drivers/net/wireless/mac80211_hwsim.c	2009-10-01 17:25:34.000000000 +0300
@@ -365,6 +365,49 @@ static void mac80211_hwsim_monitor_rx(st
 }

 
+static void mac80211_hwsim_monitor_ack(struct ieee80211_hw *hw, const u8 *addr)
+{
+	struct mac80211_hwsim_data *data = hw->priv;
+	struct sk_buff *skb;
+	struct hwsim_radiotap_hdr *hdr;
+	u16 flags;
+	struct ieee80211_hdr *hdr11;
+
+	if (!netif_running(hwsim_mon))
+		return;
+
+	skb = dev_alloc_skb(100);
+	if (skb == NULL)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Buesch | 1 Nov 11:34
Picon
Favicon

Re: ath5k AP issues

On Saturday 31 October 2009 21:21:56 Bob Copeland wrote:
> On Thu, Oct 29, 2009 at 02:31:46PM +0100, Michael Buesch wrote:
> > Ok, to sum up some discussion from IRC:
> > 
> > The initial packets that fail are not pings, but ARPs. Which are broadcast
> > frames.  The access point simply fails to notify the station via DTIM for the
> > pending multicast frames, so it stays in PS. Unicast and the corresponding
> > TIM bitmap works properly, which also explains why it works once we got a
> > successful ARP (and it didn't expire, yet).
> 
> I don't think this fixes everything (I'm still seeing some mishandled
> PS-poll frames) but this seemed to help pinging the PS client from the AP
> side.

Yeah this helps it a little bit.
It's able to get an ARP out and it's able to receive _some_ pongs now.

mb <at> homer:~$ ping 192.168.2.12 # ping the PS device
PING 192.168.2.12 (192.168.2.12) 56(84) bytes of data.
64 bytes from 192.168.2.12: icmp_seq=1 ttl=64 time=86.8 ms
64 bytes from 192.168.2.12: icmp_seq=2 ttl=64 time=4090 ms
64 bytes from 192.168.2.12: icmp_seq=3 ttl=64 time=3092 ms
64 bytes from 192.168.2.12: icmp_seq=4 ttl=64 time=2094 ms
64 bytes from 192.168.2.12: icmp_seq=5 ttl=64 time=1100 ms
64 bytes from 192.168.2.12: icmp_seq=6 ttl=64 time=101 ms
^C
--- 192.168.2.12 ping statistics ---
30 packets transmitted, 6 received, 80% packet loss, time 29002ms
rtt min/avg/max/mdev = 86.898/1760.979/4090.333/1489.080 ms, pipe 5
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Wiecki | 1 Nov 13:51

b43 with 14e4 gives DMA error

0c:00.0 Network controller [0280]: Broadcom Corporation BCM4312
802.11b/g [14e4:4315] (rev 01)
        Subsystem: Dell Device [1028:000c]
        Flags: bus master, fast devsel, latency 0, IRQ 17
        Memory at f1ffc000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: wl
        Kernel modules: wl, ssb

A variable delay after loading the most recent b43 driver I get a lot
of (I hope last nights patches would have fixed the problems, but they
didn't):
[ 6895.111946] b43-phy0 ERROR: Fatal DMA error: 0x00000800,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
[ 6895.111955] b43-phy0: Controller RESET (DMA error) ...
[ 6895.336490] b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
[ 6900.841372] b43-phy0: Controller restarted

After installing the driver for the first time, I have a few minutes I
can use the wifi card, after that the DMA errors start to occur. Once
they occured after the first loading, they appear immediatly after
each loading.

Ubuntu 9.04 (most recent) with kernel 2.6.31-14-generic

Laptop is Dell E6500.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 8 comments |
headers
Bob Copeland | 1 Nov 14:16
Favicon

Re: ath5k AP issues

On Sun, Nov 01, 2009 at 08:53:44AM +0200, Nick Kossifidis wrote:
> 2009/10/31 Bob Copeland <me@...>:
> notice the AR5K_QCU_RDYTIMECFG_ENABLE. So it's probable that the queue
> starts on time and we miss sync because we wait an extra ready-time
> period.

Yeah, I know -- I turned it off before running tests.  I don't
think it ever ran the queue, or if it did it was very late.

--

-- 
Bob Copeland %% www.bobcopeland.com

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 6 comments |
headers
Nick Kossifidis | 1 Nov 14:41
Picon
Gravatar

Re: ath5k AP issues

2009/11/1 Bob Copeland <me@...>:
> On Sun, Nov 01, 2009 at 08:53:44AM +0200, Nick Kossifidis wrote:
>> 2009/10/31 Bob Copeland <me@...>:
>> notice the AR5K_QCU_RDYTIMECFG_ENABLE. So it's probable that the queue
>> starts on time and we miss sync because we wait an extra ready-time
>> period.
>
> Yeah, I know -- I turned it off before running tests.  I don't
> think it ever ran the queue, or if it did it was very late.
>

So beacon-sent gated option doesn't work ?
Did you try also AR5K_DCU_MISC_ARBLOCK_IGNORE ?

Also according to docs Beacon frames should use queue 9 and CAB should
use queue 8 (don't know why but docs say that these are the
appropriate DCUs), beacon-gated triggering might only work if we use
DCU 9 for beacons (now we are using queue 7 for beacons and queue 6
for cab).

--

-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 5 comments |
headers
Bob Copeland | 1 Nov 15:44
Favicon

Re: ath5k AP issues

On Sun, Nov 01, 2009 at 03:41:49PM +0200, Nick Kossifidis wrote:
> So beacon-sent gated option doesn't work ?
> Did you try also AR5K_DCU_MISC_ARBLOCK_IGNORE ?

No, but I'll try that today.

> Also according to docs Beacon frames should use queue 9 and CAB should
> use queue 8 (don't know why but docs say that these are the
> appropriate DCUs), beacon-gated triggering might only work if we use
> DCU 9 for beacons (now we are using queue 7 for beacons and queue 6
> for cab).

Yeah, I read the same thing.  The docs say 8 and 9 are highest priority
queues, it also says they both need to be DBA gated, but then on the
other hand it describes beacon-sent gated as precisely what we want,
and that queue 8 is "typically associated with beacon-gated frames."

I originally assumed the queue with AR5K_DCU_MISC_BCN_ENABLE is used
for triggering beacon sent but I'll try renumbering the queues and
see what happens.

Just copying ath9k list in case anyone with the inside scoop from Atheros
wants to chime in. :)  The issue is queue settings for the CAB queue.
Beacon sent gating seems like a better option than using time throttled
DBA gating (with ready time for the next beacon interval).  Ath9k is using
the latter, the former seems not to work at least in ath5k, or we're doing
it wrong.

--

-- 
Bob Copeland %% www.bobcopeland.com
(Continue reading)

Permalink | Reply | 0 comments |

Gmane