[Kde-hardware-devel] Welcome & Wifi interface

Sun Aug 6 06:17:00 CEST 2006

I've also been hacking on a version of the NM api as a Solid module.  What I 
would like to do is get Christopher's new code up as well so we can merge it 
all together (I'll have a word with the NM team about IPV6 too) and get 
something into SVN and usable soon.  

I've mailed the diff earlier to Kévin, can't post it from this computer (I am 
off on my holidays for a week).  Kévin, can you mail it here for me?  

Regards

Will

On Saturday 05 August 2006 23:34, Christopher Blauvelt wrote:
> 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

-- 
Will Stephenson
IRC: Bille