| Message ID | 51C85919.7090704@ionic.de |
|---|---|
| State | Not Applicable |
| Headers | show |
* On 24.06.2013 04:35 PM, Mihai Moldovan wrote: > [...] > It's getting stranger: the very same setup works fine with kernel version 3.0.2, > but stopped working in-between. IIRC, about the time, when hostapd stopped > creating a monitor interface and using that for AP mode. At the very same time, > TX status support has been implemented in mac80211 by Johannes Berg (commit > a729cff8ad5120d0d5172ec28a3843d1cb458f79). > > After reverting his commit, I was able to use hostapd on 3.5.x - with a monitor > interface being used, so I suspect the kernel being broken in this respect. > > I haven't been able to revert the commit on top of 3.9.6 due to more > sophisticated merge conflicts. > > [...] > > Commit 73a3c6ffca0c0292289c4fc598402b4227c85faf by nbd disables monitor usage > when detecting TX status support... I have crafted a trivial patch to enable > monitor mode unconditionally for me: > > [...] > > With this patch, my notebook is able to authenticate. So... what's the real > culprit? :) I've been pestering Ben off-list and gained some new insights. He's using AR9380 cards extensively in his setups and I haven't seen any bug reports yet, so tried to replicate his setup. I tested my hostapd configuration with the exact kernel and hostapd he's employing, to find out that STAs still weren't able to connect. But there's one interesting and fatal difference in our hostapd configurations: I am using hostapd's internal authenticator (for WPA/WPA2), while he is relying on an external one. As everything is working for him, but I have to workaround my issue by forcing hostapd to create a monitor interface and our setups were identical (but in the very machine, though both have been "normal" x86_64 machines), could the internal authenticator be the root cause? Mihai
On 07/14/2013 11:46 AM, Mihai Moldovan wrote: > * On 24.06.2013 04:35 PM, Mihai Moldovan wrote: >> [...] >> It's getting stranger: the very same setup works fine with kernel version 3.0.2, >> but stopped working in-between. IIRC, about the time, when hostapd stopped >> creating a monitor interface and using that for AP mode. At the very same time, >> TX status support has been implemented in mac80211 by Johannes Berg (commit >> a729cff8ad5120d0d5172ec28a3843d1cb458f79). >> >> After reverting his commit, I was able to use hostapd on 3.5.x - with a monitor >> interface being used, so I suspect the kernel being broken in this respect. >> >> I haven't been able to revert the commit on top of 3.9.6 due to more >> sophisticated merge conflicts. >> >> [...] >> >> Commit 73a3c6ffca0c0292289c4fc598402b4227c85faf by nbd disables monitor usage >> when detecting TX status support... I have crafted a trivial patch to enable >> monitor mode unconditionally for me: >> >> [...] >> >> With this patch, my notebook is able to authenticate. So... what's the real >> culprit? :) > > I've been pestering Ben off-list and gained some new insights. > > He's using AR9380 cards extensively in his setups and I haven't seen any bug > reports yet, so tried to replicate his setup. > > I tested my hostapd configuration with the exact kernel and hostapd he's > employing, to find out that STAs still weren't able to connect. > > But there's one interesting and fatal difference in our hostapd configurations: > I am using hostapd's internal authenticator (for WPA/WPA2), while he is relying > on an external one. > > As everything is working for him, but I have to workaround my issue by forcing > hostapd to create a monitor interface and our setups were identical (but in the > very machine, though both have been "normal" x86_64 machines), could the > internal authenticator be the root cause? Can you just test with my exact configuration file that I sent previously? We are not actually using any external authenticator, at least for the bulk of our testing. For that matter, have you tried setting up a non-authenticated configuration? Thanks, Ben
* On 15.07.2013 02:33 AM, Ben Greear wrote: > Can you just test with my exact configuration file that I sent previously? We > are not > actually using any external authenticator, at least for the bulk of our testing. > > For that matter, have you tried setting up a non-authenticated configuration? Tested just that. Took your config and only modified it to include bridge=br0 and use wifi1 instead of vap0. This network is unencrypted and my STA can connect. :) Thus, I added/changed the following lines: bridge=br0 #eap_server=0 #ieee8021x=0 wpa=2 wpa_passphrase=nurimdunkelnlaesstsichgutmunkeln wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP And that's working, too! No monitor interface, but WPA2 encrypted and actually working. So it's gotta be *some other* option I have in my config... let the testing begin. Thanks just again! :) Mihai
* On 15.07.2013 03:38 AM, Mihai Moldovan wrote: > So it's gotta be *some other* option I have in my config... let the testing > begin. Got it! After checking every single option I've been using against Ben's config, turning features off and back on, I was able to isolate the WEP entries as the troublemaker. Right after commenting wep_default_key(=0) and wep_key0(=somekey), hostapd started behaving normally, even without a monitor interface. Is specifying both WPA and WEP options known to cause such problems? It did work fine in the past, but now it doesn't. If it's intended behavior and not actually a bug, hostapd should check for both options being turned on and reject the config file, instead of starting in such an unusable state. Jouni? I would never have guessed this to be the culprit. Thank you very much for pointing me in the right direction, Ben! Mihai
On Mon, Jul 15, 2013 at 04:20:47AM +0200, Mihai Moldovan wrote: > Got it! After checking every single option I've been using against Ben's config, > turning features off and back on, I was able to isolate the WEP entries as the > troublemaker. > > Right after commenting wep_default_key(=0) and wep_key0(=somekey), hostapd > started behaving normally, even without a monitor interface. > > Is specifying both WPA and WEP options known to cause such problems? It did work > fine in the past, but now it doesn't. What do you mean with working fine? What did you try to do with that wep_key0 parameter if the network was configured for WPA? I don't think WPA with static WEP would be supported. > If it's intended behavior and not actually a bug, hostapd should check for both > options being turned on and reject the config file, instead of starting in such > an unusable state. Jouni? Yes, wep_key# parameters should probably be rejected if wpa != 0. I don't think that wep_default_key=0 would have any effect on the functionality in your case, though. That said, it could also be finally time to consider removing WEP support from hostapd completely or at least do that for the default build. I don't see any other use for WEP apart from being able to run some test cases for station functionality to allow interoperability with old networks..
* On 20.07.2013 03:25 PM, Jouni Malinen wrote: > On Mon, Jul 15, 2013 at 04:20:47AM +0200, Mihai Moldovan wrote: >> Got it! After checking every single option I've been using against Ben's config, >> turning features off and back on, I was able to isolate the WEP entries as the >> troublemaker. >> >> Right after commenting wep_default_key(=0) and wep_key0(=somekey), hostapd >> started behaving normally, even without a monitor interface. >> >> Is specifying both WPA and WEP options known to cause such problems? It did work >> fine in the past, but now it doesn't. > What do you mean with working fine? What did you try to do with that > wep_key0 parameter if the network was configured for WPA? I don't think > WPA with static WEP would be supported. Those WEP parameters were leftovers from an initial WEP configuration when not all devices were yet supporting WPA. Then, I enabled WPA, but kept the WEP entries as-were (if I ever had to disable WPA again.) Hostapd came up with WPA support and ignored the defined WEP stuff. Or so I thought. > Yes, wep_key# parameters should probably be rejected if wpa != 0. I > don't think that wep_default_key=0 would have any effect on the > functionality in your case, though. Oh but it does. This bug is easily reproducible with my card (at least), a WPA configuration and: auth_algs=3 wep_default_key=0 wep_key0=123456789a Indefinitely, rejecting WEP parameters if wpa != 0 is a great idea and would fix the issue. > That said, it could also be finally time to consider removing WEP > support from hostapd completely or at least do that for the default > build. I don't see any other use for WEP apart from being able to run > some test cases for station functionality to allow interoperability with > old networks.. I guess only disabling WEP at build time wouldn't do a lot, as most distros would be turning it on anyway. I'm not sure how much old hardware is out there only supporting WEP (and thus the implications of removing WEP support), but I guess an unencrypted network is just as good as one encrypted with WEP (for that matter, users should take matters into hand and for instance setup a VPN with strong encryption to be used over the unencrypted connections only.) WEP is probably causing more trouble than it's worth. If you're up to it, start an RFC/poll on the mailing list and let especially people working with big networks comment on it. Best regards, Mihai
On 07/20/2013 06:25 AM, Jouni Malinen wrote: > On Mon, Jul 15, 2013 at 04:20:47AM +0200, Mihai Moldovan wrote: >> Got it! After checking every single option I've been using against Ben's config, >> turning features off and back on, I was able to isolate the WEP entries as the >> troublemaker. >> >> Right after commenting wep_default_key(=0) and wep_key0(=somekey), hostapd >> started behaving normally, even without a monitor interface. >> >> Is specifying both WPA and WEP options known to cause such problems? It did work >> fine in the past, but now it doesn't. > > What do you mean with working fine? What did you try to do with that > wep_key0 parameter if the network was configured for WPA? I don't think > WPA with static WEP would be supported. > >> If it's intended behavior and not actually a bug, hostapd should check for both >> options being turned on and reject the config file, instead of starting in such >> an unusable state. Jouni? > > Yes, wep_key# parameters should probably be rejected if wpa != 0. I > don't think that wep_default_key=0 would have any effect on the > functionality in your case, though. > > That said, it could also be finally time to consider removing WEP > support from hostapd completely or at least do that for the default > build. I don't see any other use for WEP apart from being able to run > some test cases for station functionality to allow interoperability with > old networks.. Well, I like the ability to run these old test cases... At the least, please don't remove the code entirely..but if you want to change the default build options that seems fine. Thanks, Ben >
diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c index f705a0c..6b44f46 100644 --- a/src/drivers/driver_nl80211.c +++ b/src/drivers/driver_nl80211.c @@ -3189,7 +3189,7 @@ static int wpa_driver_nl80211_capa(struct wpa_driver_nl80211_data *drv) * If poll command and tx status are supported, mac80211 is new enough * to have everything we need to not need monitor interfaces. */ - drv->use_monitor = !info.poll_command_supported || !info.data_tx_status; + drv->use_monitor = 1; //!info.poll_command_supported || !info.data_tx_status;