ath5k AP issues

Attached is a wireshark log. Let me explain what you see in there:

I have an ath5k AP and the powersaving n810 device as STA.
What I try to do is ping the n810. You can see that at the start of the log.

Packet #31 is a ping to the n810. #42, too. and so on... You see that the n810 does not reply. (not even with an 802.11 ack) I guess the n810 is in PS at that time.
Also note that the TIM sent by the AP is empty.

What I did at #135 is _simultaneously_ ping from the n810 to the ath5k. At that point suddenly both pings running on both ends start to succeed.

This is with a vanilla 2.6.31.5 kernel, but I can also reproduce this with compat-wireless and compat-wireless-stable.

Quoted 10 lines · On Thursday 29 October 2009 13:30:24 Michael Buesch wrote:

Attached is a wireshark log. Let me explain what you see in there:

I have an ath5k AP and the powersaving n810 device as STA.
What I try to do is ping the n810. You can see that at the start of the log.

Packet #31 is a ping to the n810. #42, too. and so on... You see that the n810 does not reply. (not even with an 802.11 ack) I guess the n810 is in PS at that time.
Also note that the TIM sent by the AP is empty.

Quoted 6 lines

What I did at #135 is _simultaneously_ ping from the n810 to the ath5k. At that point suddenly both pings running on both ends start to succeed.

This is with a vanilla 2.6.31.5 kernel, but I can also reproduce this with compat-wireless and compat-wireless-stable.

This is dmesg log with verbose PS debugging enabled.

[265617.902457] phy0: Allocated STA 00:1d:6e:9b:c5:a6
[265617.903187] phy0: Inserted STA 00:1d:6e:9b:c5:a6
[265620.539771] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 enters power save mode

Here I start pinging the n810. No dmesg messages appear and pinging does not work.

When I start pinging _from_ the n810, the following messages appear:

[265660.078055] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 exits power save mode
[265660.078066] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 sending 0 filtered/0 PS frames since STA not sleeping anymore
[265660.289206] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 enters power save mode
[265660.938988] STA 00:1d:6e:9b:c5:a6 aid 1: PS buffer (entries before 0)
[265660.985997] STA 00:1d:6e:9b:c5:a6 aid 1: PS Poll (entries after 0)
[265660.986016] wlan0: STA 00:1d:6e:9b:c5:a6 in PS mode, but pspoll set -> send frame
[265661.008310] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 exits power save mode
[265661.008321] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 sending 0 filtered/0 PS frames since STA not sleeping anymore
[265661.226915] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 enters power save mode

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).

Quoted 7 lines

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.]

2009/10/31 Bob Copeland <[email protected]>:

Quoted 9 lines · Michael Buesch

Quoted 7 lines

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).

Quoted 9 lines

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 starts on time and we miss sync because we wait an extra ready-time period.

2009/10/31 Bob Copeland <[email protected]>:
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.

Quoted 4 lines

2009/10/31 Bob Copeland <[email protected]>:
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).

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).

Quoted 8 lines

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).

So the results of that testing aren't so good; I still couldn't get it to work.  See the following patch if you want to play with it.  Eventually TXDESC interrupt should fire and you would see:

cabq: enqueued xxxxx
cabq: processed xxxxx

But that only happens with DBA gating, with BCN_SENT_GT I never see 'processed.'  Anything else to try?

Well let's enable them both :P

I still think that ready-time thing is evil, we should use a more accurate way.

Quoted 4 lines

Well let's enable them both :P

I still think that ready-time thing is evil, we should use a more accurate way.

I don't follow, you want to try both DBA and BCN_SENT to see what happens (with/without ready-time)?

Quoted 7 lines · Michael Buesch

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.

Attached is a wireshark log. Let me explain what you see in there:

I have an ath5k AP and the powersaving n810 device as STA.
What I try to do is ping the n810. You can see that at the start of the log.

Packet #31 is a ping to the n810. #42, too. and so on...