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

[Will Stephenson]

On Wednesday 09 August 2006 11:38, Kevin Ottens said:
> > -------------------------------------------------------------------------
> >-
> >
> > +        enum Capabilities { WEP = 0x1, WPA = 0x2, WPA2 = 0x4, PSK = 0x8,
> > IEEE8021X = 0x10, WEP40 = 0x20, WEP104 = 0x40, TKIP = 0x80, CCMP = 0x100
> > }; [...]
>
> 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 problem I have is that I 
currently use Encryption mainly to pass auth credentials for a given system 
to NM, not descriptively.  But a network could contain a list of 
supportedEncryptions() instead of these capabilities...

> > -------------------------------------------------------------------------
> >-
> >
> > +        /**
> > +         * 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.
>
> 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.

> > -------------------------------------------------------------------------
> >-
> >
> > +    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.
>
> Yep and that's fine IMHO.

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 didn't see outOfRange() in the diff. If it's still in the code, see my
> > remarks on its reliability.
>
> No it's not there anymore.
>
> > Having it in the repository would be great!
>
> I'd like to commit it soon, the problem is that the Encryption and
> NetworkManager classes are missing. So maybe it'd be nice to wait for Will
> first.

Back from holidays and working on it again.

> Sure! <mental_note>Bring cookies for Stefan.</mental_note>
> That said you know that it'll probably be easier to find beer than cookies
> in Dublin. ;-)

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. 

Will