[Kde-hardware-devel] Welcome & Wifi interface

[Christopher Blauvelt]

Thanks for the incite, I'll make sure to put this in there.
Chris


On 8/5/06, Stefan Winter <swinter at kde.org> wrote:
>
> 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 at kde.org
> https://mail.kde.org/mailman/listinfo/kde-hardware-devel
>



-- 
War(n) - God's way of teaching Americans geography.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20060806/127660ed/attachment.html