OK, one more report on this bug. It's BACK. And the reason, since the kernel hasn't been updated, must
be the other updates just issued to dhcp. Once again, I can plug an external device into the machine (Realtek) and connect, but the internal card doesn't work. It claims to see the device, and scans, and tries to connect. But never gets an IP address. But this time, it's not the ath5k driver, but the ath9k driver in use, since I upgrade the card. :) It was working before the dhcp update, and still works with some other APs, just not one in particular that I am often near. There is one additional factor now. Another external device can also connect, but does something wrong that confuses the AP and leaves it sending a continuous stream of uPNP data. This is a Ralink device. Connecting to the same AP with the Realtek device does not cause this problem. Monitoring the internal card while trying to get an IP address also shows this continuous stream of uPNP data. So: USB external device with Realtek rtl8187 chipset - works perfectly all the time USB external device with Ralink RT2870 chipset - works but has a strange side-effect on certain APs internal card with either AR2413 or AR9223 chipset - works sometimes, but doesn't work with certain APs Note that both of the problem devices are "n" devices while the Realtek device is "g" only. So, how does the kernel driver interact with the dhcp system when connecting? Would there be any relevance to what kernel driver is in use at the dhcp level? Or is this strictly something to do with dhcp and the difference between "n" and "g" modes? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1344458388.92291.yahoomail...@web126102.mail.ne1.yahoo.com
