[Kde-hardware-devel] Wifi interface

[Stefan Winter]

Hi!

> 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.

That's great to hear. I'm aware that Solid is too abstract to actually do the 
tests. But we could foresee a slot testConnectivity() that is connected to a 
signal which is emitted when the AP MAC changes.
Whatever the backend wants to do to test the connectivity and take 
countermeasures if connectivity isn't there is then the backend's own 
business.

> 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?

No, you are quite right. IPv4 and IPv6 are independent of each other (_native_ 
IPv6 that is, if it's a tunneled connection, IPv6 over IPv4, it is completely 
dependent on IPv4). The only thing I wanted to say is: IPv6 routing will 
automatically recover from a changed AP condition, whereas in IPv4 we must 
trigger something manually. As a consequence, if a network offers both IPv4 
and IPv6 connectivity, the IPv4 routing part will break down, but the user 
will still be able to use IPv6. It's just that IPv6 connectivity doesn't do a 
lot for you ATM, so we really should care about IPv4 routing anyway.

For IPv6 over IPv4: the IPv6 traffic is tunneled in a IPv4 connection. When 
the IPv4 connectivity gets lost, the tunnel breaks and your IPv6 connectivity 
is down as well.

[... scope id's ...]

> 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.

The numbers are sufficient for everything "under the hood". If you ever want 
to present information to the user, it should better be the user-space 
pretty-print string. 

> 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.

Me too, and one of the patches floating around added it again. Perfect.

> 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.

Ah, ok. I was confused by the description
/**
 * List of access points making up the network,
 * or ad hoc network nodes
 */

So it's not a list of APs making up the network, but a list making your RF 
vicinity. (A "network" correlates to an SSID). I'd suggest a description like

/**
 * List of access points and ad hoc nodes visible to the card
 */

>  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 :)

This classification sound familiar to me ;-) That's perfectly okay then.

> 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.

Everybody uses WEP-128. The other key lengths are either total crap because 
crackable in no time (64) or total crap because uninteroperable (192, 256, 
you name it).

WPA and WPA2 OTOH are a good thing. In my job, I'm extensively using 
WPAx-Enterprise and it pretty much rocks.

Stefan

-- 
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/20060809/45cf66d0/attachment.pgp