[Kde-hardware-devel] Wifi interface (revised patch in)

[Stefan Winter]

Hi,

> > Added a comment for this one. It can probably get simplified a lot (or
> > simply disappear) thanks to the Encryption classes. It also addresses
> > Christopher's comment regarding the fact that it's pretty much tied to
> > NetworkManager, and I'd dislike to have something that backend specific
> > in the libs.
>
> I am unsure what to do here.  NM returns a set of capabilities describing
> what the network is capable of, but I'm not sure how it obtains these. 
> It's not inconceivable that a network supports more than one
> authentification protocol so I would like to keep the enum.  The other

That's even pretty normal for WPA. A single SSID can handle WPA1 and WPA2 
simultaneously without problems, and offer TKIP and AES at the same time. 
Well, the "enterprise" class APs at least. So you'd get four different ways 
of connecting to the same AP. Plus, the network card itself will undoubtedly 
have a variety of possible capabilities on its side.

> > Well, I think you missed the point here (hence why I ignored your
> > comment). It's here to allow us to determine that two networks with the
> > same ESSID but different APs are probably different (think about the
> > "netgear" SSID). Two networks (same ssid, different aps) could then be
> > merged if we know (for example we asked the user) that they're really the
> > same network.
>
> Right.

Still, how do you find out if two APs with the same SSID are the same layer 3 
network? As I said earlier, asking the user won't work, IMO.

> I'm against simplification of this, although the signal is frequently
> updated and its value is basically bullshit anyway, it should be left to
> the Solid-using app to determine how to handle the signal and its value.

I second that. On one hand, making it less fine-grained will make it look  
more "stable", and that's why KWiFiManager for example also uses those bar 
graphs (that's why I initially thought it's fine).
But OTOH, what I did in KWiFiManager isn't the greatest of all wisdom. Every 
backend should be able to decide for itself what granularity it wants to use, 
maybe (hopefully!) someone can come up with something better than me.

And for the signal strength being bullshit: YES. I hate it. Most drivers don't 
report anything sensible, I tried to counter that with the "alternate 
strength caluclation". Most cards deliver the signal vs. noise strength more 
accurately than the artificial "quality" reading, so calculating quality for 
yourself as (signal level) - (noise level) is the better option at times.

> Dublin has just as many coffee/cookie/muffin shops as any other city
> outside of north Korea, I'm sure you'll be able to find some.

You'll have to explain that North Korea thing in Dublin :-) Don't they grow 
coffee there, and can't bake cookies?

Greetings,

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/20060816/b5457f82/attachment.pgp