[Kde-hardware-devel] Wifi interface
Stefan Winter
swinter at kde.org
Sun Aug 6 17:34:19 CEST 2006
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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20060806/75429d32/attachment.pgp
More information about the Kde-hardware-devel
mailing list