Hey Arend, Arend van Spriel [Sun, Oct 23, 2011 at 12:04:29PM +0200]: > I see three different AP's in this log. Could you indicate what AP you > have issues with. Sure, it's this one: > [19010.367351] wlan0: RX AssocResp from 00:14:6c:67:9c:32 (capab=0x611 > status=0 aid=2) > [19010.367355] wlan0: associated It's a WPNT384 (Netgear), an early pre-draft-n ap. > With the suspend/resume cycles early in the dmesg log it seems brcmsmac > gets disassoc/deauth before going to sleep. When things start to get > flaky this does not seem to happen and I see a lot of deauth reason=2 in > the log. If I am correct that would mean previousAuthNotValid. Not sure > why we see that. Will try to reproduce this tomorrow. Thanks for digging in there. I've to update my report: After another two suspend/resume cycles, the connection works fine again: 64 bytes from 192.168.42.1: icmp_req=38950 ttl=64 time=103 ms 64 bytes from 192.168.42.1: icmp_req=38951 ttl=64 time=47.4 ms 64 bytes from 192.168.42.1: icmp_req=38952 ttl=64 time=34.1 ms 64 bytes from 192.168.42.1: icmp_req=38953 ttl=64 time=3.57 ms 64 bytes from 192.168.42.1: icmp_req=38954 ttl=64 time=10.6 ms 64 bytes from 192.168.42.1: icmp_req=38955 ttl=64 time=1.24 ms 64 bytes from 192.168.42.1: icmp_req=38956 ttl=64 time=64.8 ms [...] I'm watching this problem for the next time and as soon it happens again, I'll test with other wifi devices to verify that the problem is not within the AP. I've attached the updated dmesg. Cheers, Nico -- PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0
Attachment:
dmesg.gz
Description: Binary data
