On Wed, 2005-12-07 at 12:35 -0500, Robert Love wrote: > On Wed, 2005-12-07 at 12:32 -0500, Dan Williams wrote: > > > Right, I'll land some API breaking patches I've got lying around then to > > start converging with wireless-tools constants. > > Great. > > After these API changes, what is next wrt WPA support?
Part of the convergence with wireless-tools is to better support the WPA stuff so that we have a clear mapping between the parameters we use for auth, encryption algorithm, and WPA to wireless-tools and wpa_supplicant. Immediately after this, we need to determine the capabilities of the drivers, through two methods: 1) Use the enc_capa field in the iw_range info for the driver to determine WPA capabilities. Not many drivers support this yet. 2) If that fails, figure out what calls wpa_supplicant makes to detect WPA capability and do that in NetworkManager Next, we need to do a more intelligent parsing of the WPA and RSN IE fields that come in beacon packets from access points (some of which is already present) to determine which access points have WPA and WPA2 capability, and which algorithms they support. Once we get capabilities down correctly, we need to make the applets understand these extended capabilities, so that they can provide correct user feedback, and prevent users from trying WPA on a non-WPA capable card, and from trying WPA with a non-WPA access point. To provide the best experience, we need to do this as close to the user as possible, ie in the applets. Once we've got all this information, and made the API changes, we can then write out the correct conf files for wpa_supplicant. Next, we need to connect to wpa_supplicant's socket for a particular interface, and monitor its association status to determine when we've successfully connected, and when the card is disconnected. That's a lot more complicated than just listening to netlink. This is where a DBUS-enabled wpa_supplicant would come in quite handy. We could also just use wpa_supplicant for all connections, even WEP and unencrypted connections. This is compelling because it removes quite a bit of code from NetworkManager's device activation process, but it also introduces regressions which we'd have to fix in wpa_supplicant (some WEP issues with airo driver for example). A case of two steps forward, much pain for a month. I've got some of these changes locally, and a few bits are already in NM. Anyone is welcome to step up if they've got some time and/or patches. Dan _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
