2009/10/31 Bob Copeland <me@xxxxxxxxxxxxxxx>: > 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 starts on time and we miss sync because we wait an extra ready-time period. -- 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
