[Kde-hardware-devel] Welcome & Wifi interface

[Stefan Winter]

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)