Thanks, Stefan! I checked the file, which states that it is "generated by the /lib/udev/write_net_rules program, probably run by the persistent-net-generator.rules rules file," and there is a line for the madwifi ath_pci driver that sets the wireless card to ath0. In addition, there's a line for the ath5k driver that sets it to wlan1. Ndiswrapper, which I used while attempting to solve the problem with the Airlink card, sets it to wlan0.
I removed the line for the ath_pci driver. Hopefully that will prevent this problem from happening again. The ath_pci driver was blacklisted though, so I don't know why that rule would try to run, as the module wasn't loading, unless all the rules are run regardless of whether a driver is loaded or not. Given that the rule was written in the file before the ath5k rule, that would explain why it took precedence over it. I imagine that the ath5k driver was originally naming the device wlan0, before I installed ndiswrapper, which took over the name. That might also explain why ndiswrapper didn't work either. And it would explain why the ath5k driver finally did work. With ndiswrapper using the name wlan0, the ath5k driver chose wlan1, which had no conflicts. During my research into this problem, I saw other people mention that udev was renaming wlan0 to ath0, but no one seemed to think it was a problem, so I didn't either. Apparently it was. Thanks, Autumn -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org