On Thursday 29 October 2009 14:06:01 Michael Buesch wrote: > 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. > > > > 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). So there is a DTIM problem with multicast frames in ath5k. -- Greetings, Michael. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
