On Mon, 2005-05-02 at 21:43 +0200, Tim Warberg wrote: > Hi, > > Scanning the archive it doesn't look like anyone is actively working > on this? If not, I'd like to offer my help. I don't have much
I've thought a lot about this in the past, and had email conversations with wpa_supplicant's author about integration with NM. But I'm not working on it at the moment. > As I see it first task is to chance WPA_Supplicant into a library. I I'd advocate using the control socket to WPA supplicant rather than making it a library though. It would be easier to simply drop in a new wpa_supplicant and to track upstream, and Jouni hasn't been very receptive to the idea of making a library out of wpa_supplicant. Given that and the fact that I don't want to maintain a fork of wpa_supplicant, I think using a control socket is the best way to go. I'm currently doing work to make the activation/connection process much cleaner and more state-based. That would facilitate adding wpa_supplicant into the mix much more easily than the current code. That should be done quite soon. > WPA_Supplicant already have a mode where SSID scanning and association > is controlled by user and i think this is a good base for > NetworkManager integration. Also for now i think it would be a good > idea to let wpa_supplicant configure hardware for WPA using it's > drivers at least until WPA is completely implemented through Wireless > Extension and kernel modules support this. Yes, this had been more or less my idea. Basically, wpa_supplicant is too smart in its default mode, and what we need is a "connect to this access point on this interface with this passphrase", and nothing more. We do not want wpa_supplicant to do its own scanning, its own config-file parsing, or anything else. Users should not have to edit the wpa_supplicant config file, since that information is stored in the user session by the info-daemon in NetworkManager's world. We need wpa_supplicant in a "slave" mode. Jouni has said that approach is acceptable, I think somebody just needs to fix up the patches for it. Once that's completed, a "wpa_manager" needs to be made in NetworkManager source code. There are already managers for VPN, DHCP, and Named, so adding another one for WPA shouldn't be that bad. We might even let wpa_supplicant take care of WEP as well and rip that code out of NM. In any case, we'll need to add a few more connection states to the wireless connection code in NM to allow for wpa_supplicant integration, but that shouldn't be too hard. So I think the first step is to get wpa_supplicant to become the "slave" and add command-line options to turn off everything it normally does (scanning, automatic association, reading the config file, etc). Thanks for the interest! Dan _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
