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