[Kde-hardware-devel] Wifi interface
Christopher Blauvelt
cblauvelt at gmail.com
Wed Aug 9 02:32:42 CEST 2006
Stefan,
I've got you on the changing AP issue. We'll have to implement a way to
ping over the address. The only issue that I see is whether or not the
backends will support it, as Solid is an abstraction layer after all.
On the issue of IP addresses, I was under the impression that interfaces
that are IPv6 can exist separately and simultaneously as the IPv4 interface
for the same device. Is this incorrect? Also, how does IPv6 over IPv4
factor into this?
>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.
I'm not quite sure about what the issue is here. Additionally, aren't just
the interface numbers not enough? You could also have usb0 for instance.
I'd like to keep unassociated, in the Mode enum because the instance where a
wifi device is active but not associated with an AP is very real.
Perhaps I was unclear about what MacAddressList is. This is meant to be the
the mac addresses of all available APs after a scan. I believe this will
help solve the changing AP problem as well.
>+ 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.
My purpose behind this was to have a qualitative signal strength such as,
Excellent, Very Good, Good, Poor, Out of Range. Which hopefully won't change
as much :)
I'll apply the sugestions on encryption. As I've said, I'm very poorly
versed in this so anything you can give me is appreciated. I usually just
stick to 128bit WEP and call it good.
Ervin, I've applied the suggestions for the last submittal and will mail
those to you later today.
Chris
On 8/6/06, Stefan Winter <swinter at kde.org> wrote:
> 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)
_______________________________________________
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.
--
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/20060809/3677761f/attachment.html
More information about the Kde-hardware-devel
mailing list