Hi folks, I'm Stefan Winter, the author of KWiFiManager and the (infamous) kcmwifi. As you may have read some time ago on k-c-d I will discontinue kcmwifi, keeping only KWiFiManager-the-monitoring-app alive, and let you guys from Solid do the job for configuration handling. I have just subscribed to kde-hardware-devel because I'd still like to keep an eye on what's happening on the wifi configuration front. I encountered ervin's tarball with the initial wifi implementation on the list archives from last month and took a brief look at it. Here are some things I stumbled over...
(ifaces/wifi.h): /** * @brief retrieves the IP address. * @return A list of the address information. */ virtual QString networkAddress() const = 0; With the advent of IPv6, this is not going to be sufficient. Devices have more than one IP address (arguably, even with IPv4, but multile IPs is not usually a scenario for wireless devices with IPv4). Mobile IPv6 and whatnot may lead you to end up with a fleabag of IP addresses when you are mobile. RESOLUTION: I'd suggest a QStringList (trunk KWiFiManager already retrieves a QStringList BTW) signals: /** * This signal is emitted when the network device is out of range of the WAP. * * @param outofrange Whether the network device is out of range of the WAP. */ virtual void outOfRange( bool outofrange ) = 0; Interesting. I'm not entirely sure how this can be reliably implemented. Especially when you're close to the edge of a network, you may experience "flapping" of the interface, and emitting this signal every fraction of a second doesn't sound appealing to me. A recurring wish for kcmwifi was "execute a shutdown script when the device _leaves_ the network". My guess would be to connect to this signal and execute the script, but if there's flapping, that is not a good idea any more. (ifaces/enums.h) struct Wifi { /** * This enum type defines which method of encryption is being used. * * - None: The device doesn't use encryption * - WEP: The device uses WEP for encryption * - WPA: The device uses WPA for encryption * - WPA2: The device uses WPA2 for encryption * * TODO: There is still much to be decided here. What bitrate of WEP? What server method * for WPA, etc. */ enum EncryptionType { None, WEP, WPA, WPA2 }; That's quite true. WEP is very inconsistent. There have been many vendor extensions the WEP encryption scheme so that you can not be sure which key lengths exist ("bitrate" as a term looks strange here). I've seen WEP-64 ("ye olde"), WEP-128, WEP-192 and WEP-256, but you can never be sure what's out there. The wireless extension's new interface allows you to ask the card what lengths are supported dynamically. Which is not good for use in an enum, of course. Plus, you may want to have more fine-grained encryption types: WEP comes as a static method (you enter the key) or an authentication-server supplied key ("dynamic WEP"). Same goes for WPA and WPA2, it's just called PSK and Enterprise here. Also, the struct misses the encryption algorithms that can be used in conjunction with WPA and WPA2: you can choose between TKIP and AES in both variants. Then there's the question: how far do you want to go? If you are using dynamic/Enterprise encryption, you could also foresee a reporting mechanism on what authentication method is used (and there are lots of them). But maybe that is going _too_ far. RESOLUTION: 1) I suggest to make it WEP_64, WEP_128, WEP_192, WEP_256, WEP_OTHER in the enum, with a method to retrieve length information in case of WEP_OTHER. 2) add enum enum KeyType { None, Static, Dynamic }; 3) add enum enum WPA_Algorithm { None, TKIP, AES }; a method querying the state of the network connection should return a triplet of those enums. /** * This enum type defines the network type the device is connected. * * - Unassociated: The device is not associated with any network. * - Managed: The device is on a managed network and connected to a WAP. * - Adhoc: The device is on an ad-hoc (device-device) network. */ enum Mode {Unassociated, Managed, Adhoc}; Nice for a start, but you may want to consider that there are sophisticated setups where a card may itself act as an access point (many cheapo home linux routers equipped with a nice card and a capable driver exist). That would add the state Mode == Master to the enum. Plus, such "software" APs can use the WDS system to wirelessly connect to other APs. This is a state that the wireless extensions call Mode == Repeater. And there's also Mode == Secondary. But I NEVER figured out what that is supposed to mean or do. RESOLUTION: I suggest to add at least Master and Repeater to the enum, even if these are not used in an initial implementation. Okay, that's it for a start. Have a nice weekend! Greetings, Stefan Winter -- The K Desktop Environment - Stefan Winter - Areas of Activity: kdenetwork/wifi (KWiFiManager) kde-i18n/de (German translation) _______________________________________________ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel