Bug#600589: hostapd+bridge doesn't work if hostapd is not run as a daemon in squeeze
So basically, if I do bridge first, then run hostapd as a daemon, it used to work, but with a newer kernel it doesn't, because the bridge needs wlan0 to be in master mode already, which is the job of hostapd. If I do hostapd first via /etc/network/interfaces, then the bridge from the same file, then everything starts up without an error, but I can't do WPA, only after I restart hostapd. I found a workaround for the first case: iwconfig wlan0 mode master doesn't work, but pre-up iw dev wlan0 set type __ap does the job. It sets the card to master mode, then the bridge can be set up, then hostapd starts as a daemon and everything is working fine again. So now the real problem remains, the second case: if hostapd is run from /etc/network/interfaces and I set up a bridge in the same file, then hostapd either doesn't receive EAPOL responses or sends the EAPOL requests to the wrong place and I get EAPOL timeouts in the syslog. Bottom line: no WPA. Check this interfaces file: iface eth0 inet manual iface wlan0 inet manual hostapd /etc/hostapd/hostapd.conf iface br0 inet static bridge-ports eth0 wlan0 I'm guessing what it does is this: bring up eth0, then run hostapd in the pre-up stage, then bring up wlan0, then bring up the bridge. The problem could be that hostapd doesn't see the bridge when it starts up, or some property of the bridge or wlan0 changes after it started up. I grabbed myself a hostapd source code, so if you could give some pointers where to look, I'd be glad to help. How do I debug where it sends EAPOL requests? How do I debug where it expects EAPOL responses from? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600589: hostapd+bridge doesn't work if hostapd is not run as a daemon in squeeze
Package: hostapd Version: 0.6.10-2 I'm using a very common setup: I want to bridge eth0 + wlan0 (b43 wireless card). When I run hostapd as a daemon, it works fine. But when I run it from /etc/network/interfaces with the hostapd stanza, it doesn't work. Symptoms: in the syslog I see that there's an association and a few seconds later a deauthenticated due to a local deauth request message. With an increased log level I see an EAPOL-key timeout message. If I do ifdown wlan0 then ifup wlan0 then it starts working. Why it matters: I upgraded to a 2.6.35 custom kernel. When the networking is being set up, I get a not supported error, it can't add wlan0 to the bridge. I read that it happens because with newer kernels, the wifi adapter needs to be in master mode already. I can't do that with a pre-up iwconfig wlan0 mode master line because it says Set Mode (8B06) : SET failed on device wlan0 ; Invalid argument. The only way I know to put the card into master mode is if I run hostapd. I suspect one might say that custom kernels are not supported, but running hostapd in non-daemon mode sure is. With a .32 kernel the easy workaround is to run it as a daemon mode, but it doesn't apply with .35, and it should be fixed sooner or later. It seems to me that hostapd only works if it is run after the bridge is set up. My old config worked because networking was set up before hostapd was run, the bridge was already working when hostapd started. With the new kernel, I can't do the bridge first because of the not supported error. So hostapd is run first, it puts the card into master mode, then the bridge is brought up, and it doesn't work, then I can restart hostapd with ifdown-ifup, and then it works, because it starts after the bridge. If there was a way to put the card into master mode without hostapd, then I could run hostapd as a daemon with the newer kernel, too, however the bug would still be there. But I can't setup master mode with iwconfig, how does hostapd do it anyway? And why doesn't it work if it is started before the bridge is created? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
