<div>
<div>Stefan,</div>
<div>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.</div>
<div> </div>
<div>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?
</div>
<div> </div>
<div></div>
<div><span class="q">>There's one thing to consider here: this gives you the IP address without<br>>scope identifier. This is fine for KWiFiManager and what I wanted, but to get<br>>a unique, usable IP address you may have to have it's scope. This is the case
<br>>in IPv6 link-local addresses, i.e.: fe80::cafe:babe is NOT a valid address,<br>>but fe80::cafe:babe%eth2 is.<br>>If you want the scope in, use nodeName() instead of ipAddress(). There was one<br>>open issue with this though: the scope was (back then) not given in
<br>>pretty-print "eth2" but as the kernel's internal interface number, which made<br>>an output of, say, fe80::cafe:babe%3.<br>>Thiago wanted to clean that up, IIRC, but I don't know what happened to it. I
<br>>was happy without scope ids as well.<br></span></div>
<div>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.<br> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>>+ signals:</div>
<div><span class="q"><br>>+ virtual void signalStrengthChanged( int );<br>><br>>Fine, just keep in mind that the strength reported by the card is _almost<br>>never_ constant, even if you don't move. So this signal will basically
<br>>almost always be emitted when you poll the device info.</span></div>
<div></div>
<div>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 :)</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>Ervin, I've applied the suggestions for the last submittal and will mail those to you later today.</div>
<div> </div>
<div>Chris<br> </div>
<div></div>
<div><span class="e" id="q_10cef7e21d9d6287_5"><span class="gmail_quote">On 8/6/06, <b class="gmail_sendername">Stefan Winter</b> <<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:swinter@kde.org" target="_blank">
swinter@kde.org</a>> wrote:</span> </span></div>
<div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"></blockquote></div>
<div><span class="e" id="q_10cef7e21d9d6287_7">Hi!<br><br>> Stefan, could you please review this patch and make a second round of<br>> comments? This kind of input is very valuable. This patch is based on <br>> Christopher's work, so you'll get extra cookies if you could also point
<br>> which of your previous comments are still valid and which one are<br>> obsoleted. I'll do a similar check on my side but this way we'll reduce <br>> chances to miss one.<br><br>(individual issues marked with dashed lines)
<br><br>Sure thing, I'm just going through it. Something related and important (for me<br>at least) first: with Solid running as a background process all the time, I <br>think there's something important we can achieve in wireless networks, and
<br>whose non-existance pissed me and my research project off more than once.<br>Gory details follow:<br><br>-------------------------------------------------------------- <br><br>Imagine you are in a place where administratively different,
i.e. different<br>IP subnets, WLAN networks are present BUT both of them have the same SSID<br>(either by accident: someone onpacking his box and using some insane default <br>SSID "netgear" or whatever, or on purpose: a roaming service that offers his
<br>customers the same SSID wherever they are). One of those roaming services is<br>eduroam, <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.eduroam.org/" target="_blank">http://www.eduroam.org
</a>. , you find this SSID pretty much all over<br>the world at universities and research centres.<br><br>Problem: when the two cells with different IP subnets are in your vicinity,<br>you automatically get connectivity problems. Why? Upon first connection, you
<br>get a DHCP IP address with a default gateway. Now your client decides to roam<br>to the other AP, which is a ISO/OSI layer 2 operation, it won't tell layer 3<br>and above but the default router you have configured and the IP address you
<br>have aren't valid any more: no connectivity. Your device typically won't<br>bother to ask for a new IP via DHCP since "nothing happened" from layer 3's<br>POV. With a bit of luck, your driver will hop back to your original AP and
<br>things will run again, but there will always be intermittent problems when it<br>hops around.Unfortunately, there's no easy way to detect this (with IPv4).<br>Even if the AP you connected to is a different one, it *might* belong to the
<br>same IP subnet. The only way around this is to actively test reachability of<br>the gateway upon change of AP MAC (i.e. ping the gateway) and ask for a new<br>DHCP address if it's not there. This can only be done by a clever daemon,
<br>IMO. Which is where Solid comes in :-)<br><br>BTW, IPv6 will (as always) save the world: you get an automatic notification<br>of subnet and router change because routers send Router Advertisement<br>messages. But we can't wait for decades until IPv6 is the default for client
<br>device connections.<br>This functionality is not a big thing (after all, just a ping) but is lacking<br>pretty much everywhere. It would move us ahead of MS, OS X etc.<br><br>--------------------------------------------------------------------------
<br><br>Now, for the diff:<br><br>+namespace Solid<br>+{<br>+namespace Net<br>+{<br>+<br>+class Network : public QObject<br>+{<br>+Q_OBJECT<br>+ public:<br>+ Network( Ifaces::Network *, QObject * parent );<br>+ virtual ~Network();
<br>+ // TODO ask Thiago whether to use QHostAddress or KIPAddress for<br>these<br>+ virtual QString ipV4Address();<br>+ // virtual QString ipV6Address();<br><br>I've had this very discussion with Thiago ages ago when I started to port
<br>KWiFiManager to KDE4 and got IPv6 addresses in. The outcome was to<br>use KNetworkInterface::address() and iterate over it, i.e.<br><br>KNetwork::KNetworkInterface interface ( interface_name );<br>QList<KNetwork::KSocketAddress> addrinfo =
interface.address();<br>for (QList<KNetwork::KSocketAddress>::iterator it = addrinfo.begin(); it !=<br>addrinfo.end(); it++)<br> ip_addresses << (*it).asInet().ipAddress().toString();<br><br>(ip_addresses being a QStringList)
<br><br>There's one thing to consider here: this gives you the IP address without<br>scope identifier. This is fine for KWiFiManager and what I wanted, but to get<br>a unique, usable IP address you may have to have it's scope. This is the case
<br>in IPv6 link-local addresses, i.e.: fe80::cafe:babe is NOT a valid address,<br>but fe80::cafe:babe%eth2 is.<br>If you want the scope in, use nodeName() instead of ipAddress(). There was one<br>open issue with this though: the scope was (back then) not given in
<br>pretty-print "eth2" but as the kernel's internal interface number, which made<br>an output of, say, fe80::cafe:babe%3.<br>Thiago wanted to clean that up, IIRC, but I don't know what happened to it. I<br>was happy without scope ids as well.
<br><br>Oh, and my earlier comment still is valid in this regard:<br>QStringList ...addresses, instead of QString ...address;<br><br>--------------------------------------------------------------------------<br><br>+ enum OperationMode { Adhoc, Managed };
<br><br>See my comment about Master and Repeater. Unassociated went away. Why? I<br>thought that is a valid state...<br><br>--------------------------------------------------------------------------<br><br>+ enum Capabilities { WEP = 0x1, WPA = 0x2, WPA2 = 0x4, PSK = 0x8,
<br>IEEE8021X = 0x10, WEP40 = 0x20, WEP104 = 0x40, TKIP = 0x80, CCMP = 0x100 };<br><br>There's pretty much everything I asked for in there. But I'm reconsidering<br>mentioning some WEP strengths explicitly, while others are just WEP. I'd
<br>rather go for WEP only, and a function to query the length. Just to avoid<br>confusion.<br>My WLAN card for example reports the following key sizes:<br><br>eth1 3 key sizes : 40, 104, 256bits<br><br>So, let's play with numbers a little bit. 40 means 5 ASCII characters, which
<br>is usually advertised as 64 Bit keys (adding the 24 bit Initialisation<br>Vector). 104 matches the pretty-print 128 Bit encryption, but what about 256?<br>Looks like a round number, but you'd have to add 24 Bit IV to get how key
<br>sizes are normally advertised. So my card can do "280 bit encryption"?<br>Freaky.<br>I'll stop whining about my NIC now and just give one small advice: don't<br>confuse users with key lengths whenever possible. Nobody outside of techspeak
<br>understands that 40=64 and 104=128. And that 256 is either 232+24 IV or<br>really 256+24 IV depending on what your vendor writes on his box.<br>And for the framework: I'd say WEP as a generic enum name would be fine, plus
<br>a function to retrieve the actual length. Whether length on wire (input key +<br>IV) or configured length (just input key) needs to be documented, of course.<br><br>--------------------------------------------------------------------------
<br><br>+ /**<br>+ * List of access points making up the network,<br>+ * or ad hoc network nodes<br>+ */<br>+ virtual MacAddressList bssList() const;<br><br>Um. This list is inherently incomplete, and thereby worthless. You can only
<br>add those MACs that you _see_ belonging to the same network. There may well<br>be other APs that make up the same network but your client can not see. Same<br>goes for Ad-Hoc, here this is commonly called the "hidden station problem".
<br>I'd suggest to just drop this function.<br><br>--------------------------------------------------------------------------<br><br>+ signals:<br>+ virtual void signalStrengthChanged( int );<br><br>Fine, just keep in mind that the strength reported by the card is _almost
<br>never_ constant, even if you don't move. So this signal will basically<br>almost always be emitted when you poll the device info.<br><br>--------------------------------------------------------------------------<br><br>
I didn't see outOfRange() in the diff. If it's still in the code, see my<br>remarks on its reliability.<br><br>> From here, I'm planning to work on a revised patch that would be suitable<br>> for a merge, even if still incomplete (since encryption class, fixes for
<br>> stefan upcoming comments, and some of the work Christopher has probably<br>> done in his own branch will be missing). This way we'll have a sync point<br>> to work in a more coordinated fashion and we'll be able to put all this in
<br>> the repository soon.<br><br>Having it in the repository would be great!<br><br>> you'll get extra cookies if you could also point which of your previous<br>> comments are still valid<br><br>I expect my cookies to be delivered at aKademy :-)
<br><br>Greetings,<br><br>Stefan<br><br>--<br>This mail is guaranteed to be virus free because it was sent from a computer<br>running Linux.<br><br>--<br>The K Desktop Environment<br>- Stefan Winter -<br>Areas of Activity:
<br>kdenetwork/wifi (KWiFiManager)<br>kde-i18n/de (German translation)<br><br><br></span></div>
<div>_______________________________________________<br>Kde-hardware-devel mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:Kde-hardware-devel@kde.org" target="_blank">Kde-hardware-devel@kde.org
</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="https://mail.kde.org/mailman/listinfo/kde-hardware-devel" target="_blank">https://mail.kde.org/mailman/listinfo/kde-hardware-devel</a><br><br><br><br>
<blockquote></blockquote></div><br><br clear="all"><br>-- <br>War(n) - God's way of teaching Americans geography. </div><br clear="all"><br>-- <br>War(n) - God's way of teaching Americans geography.