On Wed, Jun 10, 2009 at 8:30 AM, Johannes Berg<johannes@xxxxxxxxxxxxxxxx> wrote: > On Wed, 2009-06-10 at 04:18 +0100, Hin-Tak Leung wrote: > >> But I have been using vendor driver 3.0 for a few weeks in AP mode and >> I am as happy with it as I could be, I think; I have >> suspended//resumed clients. It works adequately. > > We're not concerned about suspend/hibernate, we're concerned about > 802.11 power saving, where the AP is required to buffer frames until the > clients wake up again. This will work adequately, but not perfectly, for > unicast frames, but we have not found a way of making zd1211 send > buffered multicast frames after the DTIM beacon as required. > > This means that your sleeping clients will not be receiving multicast, > and as such be invisible to the network once they fall off the ARP/NDP > caches. This is the reason we have said that it will not be possible to > support AP mode with this card. I'm curious how, if at all, the vendor > driver handles that. I was talking about the client suspending/resuming (i.e. the client disappearing). This is what appears in the AP machine's dmesg during the client's sleep: --------------------------------------------------------- *****Age one***** aid:1 now:264313809 ttl:264163665 idleTime:150144 zd1205_notify_disjoin_event Send Deasoc Req to 00:16:44:8f:71:93 RSN=4 STA_DISASSOCIATED:00:16:44:8f:71:93 Reject Auth Due to ar2524drv/src/zdpsmon.c,568. staSte=4 Update BCN @ 286757537 Re_Asoc: 00:16:44:8f:71:93, aid=1 ------------------------------------------------------------ It seems that the vendor driver on the AP machine simply diassociates a sleeping cliient for inactivity after 10 minutes during the sleep and let the client does reassociating when it wakes again. I just grep for 'idleTime' in the 3.0 source and 10 minutes is exactly what it does. -- 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
