Hi! > Stefan, could you please review this patch and make a second round of > comments? This kind of input is very valuable. This patch is based on > Christopher's work, so you'll get extra cookies if you could also point > which of your previous comments are still valid and which one are > obsoleted. I'll do a similar check on my side but this way we'll reduce > chances to miss one.
(individual issues marked with dashed lines) Sure thing, I'm just going through it. Something related and important (for me at least) first: with Solid running as a background process all the time, I think there's something important we can achieve in wireless networks, and whose non-existance pissed me and my research project off more than once. Gory details follow: -------------------------------------------------------------- Imagine you are in a place where administratively different, i.e. different IP subnets, WLAN networks are present BUT both of them have the same SSID (either by accident: someone onpacking his box and using some insane default SSID "netgear" or whatever, or on purpose: a roaming service that offers his customers the same SSID wherever they are). One of those roaming services is eduroam, http://www.eduroam.org. , you find this SSID pretty much all over the world at universities and research centres. Problem: when the two cells with different IP subnets are in your vicinity, you automatically get connectivity problems. Why? Upon first connection, you get a DHCP IP address with a default gateway. Now your client decides to roam to the other AP, which is a ISO/OSI layer 2 operation, it won't tell layer 3 and above but the default router you have configured and the IP address you have aren't valid any more: no connectivity. Your device typically won't bother to ask for a new IP via DHCP since "nothing happened" from layer 3's POV. With a bit of luck, your driver will hop back to your original AP and things will run again, but there will always be intermittent problems when it hops around.Unfortunately, there's no easy way to detect this (with IPv4). Even if the AP you connected to is a different one, it *might* belong to the same IP subnet. The only way around this is to actively test reachability of the gateway upon change of AP MAC (i.e. ping the gateway) and ask for a new DHCP address if it's not there. This can only be done by a clever daemon, IMO. Which is where Solid comes in :-) BTW, IPv6 will (as always) save the world: you get an automatic notification of subnet and router change because routers send Router Advertisement messages. But we can't wait for decades until IPv6 is the default for client device connections. This functionality is not a big thing (after all, just a ping) but is lacking pretty much everywhere. It would move us ahead of MS, OS X etc. -------------------------------------------------------------------------- Now, for the diff: +namespace Solid +{ +namespace Net +{ + +class Network : public QObject +{ +Q_OBJECT + public: + Network( Ifaces::Network *, QObject * parent ); + virtual ~Network(); + // TODO ask Thiago whether to use QHostAddress or KIPAddress for these + virtual QString ipV4Address(); + // virtual QString ipV6Address(); I've had this very discussion with Thiago ages ago when I started to port KWiFiManager to KDE4 and got IPv6 addresses in. The outcome was to use KNetworkInterface::address() and iterate over it, i.e. KNetwork::KNetworkInterface interface ( interface_name ); QList<KNetwork::KSocketAddress> addrinfo = interface.address(); for (QList<KNetwork::KSocketAddress>::iterator it = addrinfo.begin(); it != addrinfo.end(); it++) ip_addresses << (*it).asInet().ipAddress().toString(); (ip_addresses being a QStringList) There's one thing to consider here: this gives you the IP address without scope identifier. This is fine for KWiFiManager and what I wanted, but to get a unique, usable IP address you may have to have it's scope. This is the case in IPv6 link-local addresses, i.e.: fe80::cafe:babe is NOT a valid address, but fe80::cafe:babe%eth2 is. If you want the scope in, use nodeName() instead of ipAddress(). There was one open issue with this though: the scope was (back then) not given in pretty-print "eth2" but as the kernel's internal interface number, which made an output of, say, fe80::cafe:babe%3. Thiago wanted to clean that up, IIRC, but I don't know what happened to it. I was happy without scope ids as well. Oh, and my earlier comment still is valid in this regard: QStringList ...addresses, instead of QString ...address; -------------------------------------------------------------------------- + enum OperationMode { Adhoc, Managed }; See my comment about Master and Repeater. Unassociated went away. Why? I thought that is a valid state... -------------------------------------------------------------------------- + enum Capabilities { WEP = 0x1, WPA = 0x2, WPA2 = 0x4, PSK = 0x8, IEEE8021X = 0x10, WEP40 = 0x20, WEP104 = 0x40, TKIP = 0x80, CCMP = 0x100 }; There's pretty much everything I asked for in there. But I'm reconsidering mentioning some WEP strengths explicitly, while others are just WEP. I'd rather go for WEP only, and a function to query the length. Just to avoid confusion. My WLAN card for example reports the following key sizes: eth1 3 key sizes : 40, 104, 256bits So, let's play with numbers a little bit. 40 means 5 ASCII characters, which is usually advertised as 64 Bit keys (adding the 24 bit Initialisation Vector). 104 matches the pretty-print 128 Bit encryption, but what about 256? Looks like a round number, but you'd have to add 24 Bit IV to get how key sizes are normally advertised. So my card can do "280 bit encryption"? Freaky. I'll stop whining about my NIC now and just give one small advice: don't confuse users with key lengths whenever possible. Nobody outside of techspeak understands that 40=64 and 104=128. And that 256 is either 232+24 IV or really 256+24 IV depending on what your vendor writes on his box. And for the framework: I'd say WEP as a generic enum name would be fine, plus a function to retrieve the actual length. Whether length on wire (input key + IV) or configured length (just input key) needs to be documented, of course. -------------------------------------------------------------------------- + /** + * List of access points making up the network, + * or ad hoc network nodes + */ + virtual MacAddressList bssList() const; Um. This list is inherently incomplete, and thereby worthless. You can only add those MACs that you _see_ belonging to the same network. There may well be other APs that make up the same network but your client can not see. Same goes for Ad-Hoc, here this is commonly called the "hidden station problem". I'd suggest to just drop this function. -------------------------------------------------------------------------- + signals: + virtual void signalStrengthChanged( int ); Fine, just keep in mind that the strength reported by the card is _almost never_ constant, even if you don't move. So this signal will basically almost always be emitted when you poll the device info. -------------------------------------------------------------------------- I didn't see outOfRange() in the diff. If it's still in the code, see my remarks on its reliability. > From here, I'm planning to work on a revised patch that would be suitable > for a merge, even if still incomplete (since encryption class, fixes for > stefan upcoming comments, and some of the work Christopher has probably > done in his own branch will be missing). This way we'll have a sync point > to work in a more coordinated fashion and we'll be able to put all this in > the repository soon. Having it in the repository would be great! > you'll get extra cookies if you could also point which of your previous > comments are still valid I expect my cookies to be delivered at aKademy :-) Greetings, Stefan -- This mail is guaranteed to be virus free because it was sent from a computer running Linux. -- The K Desktop Environment - Stefan Winter - Areas of Activity: kdenetwork/wifi (KWiFiManager) kde-i18n/de (German translation)
pgpYLrCzeXI2v.pgp
Description: PGP signature
_______________________________________________ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel