Le vendredi 27 janvier 2012 à 12:37 +0100, Arend van Spriel a écrit : On 01/27/2012 11:26 AM, Milan Bouchet-Valat wrote: > > Le vendredi 27 janvier 2012 à 11:08 +0100, Arend van Spriel a écrit : > >> Another thing to consider. I notice that you have a bluetooth device in > >> there as well. Can you disable that (if possible) and try again. > > I'll try that, but sadly not before Tuesday as I'm not in the right > > place ATM. > > Ok. To disable bluetooth you could use the rfkill utility: > > $ rfkill block bluetooth > Yes, I did that, but it doesn't fix the problem. >> Does your AP have DFS enabled? > > I'll ask my IT staff about that. Or is there a way to get this > > information from the logs or iwconfig? > > > > I actually did mean whether the AP has automatic channel selection. I am > not sure whether it is advertised in the beacons. > I think you found the origin of the problem. I ran iwlist scan after the bug happened, and my network's APs are visible on 3 different channels (1, 6 and 11). When everything was fine, it was only on channel 11. The most surprising thing is that the precise AP I'm associated with is now visible on two channels (1 and 11). Another weird fact is that after reloading brcmsmac (I had to do it twice to be able to reconnect), I still see my APs on these different 3 channels, and still it works fine. But maybe the channel change is what triggers the bug. As you see, this is a very crowded place, with other networks using the same channels. This is probably not an ideal setup, but it's great to stress-test the drivers. ;-) Regards -- 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
