| Time |
Nick |
Message |
| 16:17 |
meeting |
Meeting started Sun Jun 5 16:17:34 2011 UTC. The chair is garycmartin. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 16:17 |
|
Useful Commands: #action #agreed #help #info #idea #link #topic #endmeeting |
| 16:18 |
garycmartin |
Just so we have an easy log for other to look through :) |
| 16:18 |
silbe |
+1 |
| 16:18 |
garycmartin |
silbe: Can I fire some general questions your way? |
| 16:20 |
|
#topic Neighbourhood design changes related to new NetworkManager api |
| 16:20 |
silbe |
garycmartin: go ahead |
| 16:21 |
garycmartin |
#info discussing Saschas email today Subject: [DESIGN] NetworkManager / Neighborhood design changes |
| 16:22 |
silbe |
#link http://lists.sugarlabs.org/arc[…]-June/031679.html |
| 16:23 |
garycmartin |
silbe: OK, so lots of details in your email. First thought, are we trying to allow multiple network connections at a single time (e.g. cabled ethernet connection while simultaneously connected to an AP)? |
| 16:24 |
silbe |
garycmartin: if NM allows it, we do - both with the current and the new design. |
| 16:24 |
|
and in fact it does allow it - plugging in an ethernet cable will activate the wired connection in parallel with the wireless one, but take away the default route from it |
| 16:25 |
garycmartin |
silbe: I know networking stacks can support all kinds/quantities of connections, but the Sugar UI does not allow it (for very sane reasons of buddy visibility) |
| 16:27 |
silbe |
garycmartin: that's something we'll need to work on in the long term, independent of network connectivity. Even the automatic changes between Salut (link-local) and Jabber (school server) can be very confusing. |
| 16:29 |
garycmartin |
silbe: the UI design complexity goes through the roof if we try and support multiple simultaneous networks. Multiple connected APs in you device frame? What use would that be to activity collaboration they have no way of directing traffic to a specific network. |
| 16:30 |
silbe |
garycmartin: what I didn't include in the current mail either is support for "sharing" the internet connection with others, which will create a special ad-hoc connection that others can join and use for internet connectivity. Dextrose already supports this, but I'd like to discuss the design at a later time. There are enough topics to discuss for today. |
| 16:32 |
|
garycmartin: don't conflate connectivity with collaboration. The latter requires the former, but that's about it. |
| 16:32 |
garycmartin |
silbe: "sharing" a network connection to others has good specific real world uses, I agree that's worth exposing to a Sugar user. |
| 16:33 |
silbe |
garycmartin: The purpose of NetworkManager is to manage all this complexity. We only need to provide a UI for it. |
| 16:33 |
garycmartin |
silbe: We should only expose what is useful to Sugar users. |
| 16:33 |
silbe |
garycmartin: NM should know when it's OK to have two connections active in parallel and when it should take down the existing one if another one is activated. |
| 16:35 |
garycmartin |
silbe: you have a requirement listed as "Ability to activate a specific connection if multiple connections are available for a device / access point" |
| 16:35 |
silbe |
garycmartin: it's pretty normal on my laptops to have two connections active: a wireless and a wired one. I can unplug the cable and still continue to use the network. When I sit down and need more bandwidth, I plug in the cable again. |
| 16:35 |
|
garycmartin: ah, maybe that one is phrased confusingly |
| 16:36 |
|
garycmartin: What I meant was that if there are different settings for the same SSID, the user can choose which one to use right now. |
| 16:38 |
|
garycmartin: The reason we need this at all is that there are a lot of APs that come preconfigured with the *same* SSID. If I use my XO at two different houses (e.g. at my family and at a friends), the SSID will be the same but the credentials won't match. |
| 16:39 |
garycmartin |
silbe: so if one AP allows WPA and WEP authentication at the same time, and the user has logged in with both at some point in the past, they get to chose which of the two to use when they click the AP icon next time to connect? |
| 16:40 |
silbe |
garycmartin: if they explicitly added a second setting for the same SSID, then yes, they can choose between the two. |
| 16:41 |
garycmartin |
silbe: so are we not using the BSSID internally for uniqueness, so that even if two APs are named with the same SSID they are distinct in the UI (separate AP icons even if they have the same name)? |
| 16:43 |
silbe |
garycmartin: we don't do that in the UI because the purpose of having an SSID is to allow roaming (between multiple APs, i.e. between differen BSSIDs) |
| 16:44 |
garycmartin |
silbe: yep, fair point. |
| 16:44 |
silbe |
garycmartin: good point, though - we should only list connections with a matching BSSID if it's fixed. |
| 16:46 |
garycmartin |
silbe: 'only list connections with a matching BSSID if it's fixed' so that's not the example you game above right (where you have an AP at home called "foobar" and an AP at work also called "foobar" but each with different authentication details)? |
| 16:47 |
|
s/game/gave/ |
| 16:52 |
silbe |
garycmartin: if the user chose to restrict each of the two connections to the respective BSSID, Sugar will only show a single connection at each place and auto-activation will work fine. |
| 16:53 |
|
garycmartin: if the user chose to leave roaming enabled, the connection(s) will show at both places |
| 16:56 |
garycmartin |
silbe: So.. If I click an AP icon with an SSID "foobar" and I have already authenticated with an SSID "foobar" (and it doesn't have authentication details for it's BSSID), it should first try the stored authentication details (attempt at roaming), if that fails *and* the BSSID is different, it should prompt the user to enter new authentication details (new connection stored against the unique BSSID). If it failes *and* the BSSID is the same the |
| 16:56 |
|
is an error (the AP may have had it's authentication details changed) and the user needs to be prompted to enter new authentication details for it. |
| 16:56 |
silbe |
garycmartin: I hope nobody sets up a multi-AP network (i.e. one with roaming) using the default SSID. Unfortunately experience shows that someone in charge will be stupid enough to do that, so we need to cope with that (since the user can't do anything about it). :-/ |
| 16:57 |
garycmartin |
silbe: OK let me try another req you note (just to get some coverage). |
| 16:58 |
|
#topic Ability to prevent automatic reconnections for a device (either via using the Disconnect() call for the device or disabling the entire hardware class); preferably happens by default |
| 16:59 |
silbe |
garycmartin: we might do that (prompt the user to configure a new connection if the credentials and the BSSID mismatch). So far I would have went for the simpler route of letting it just fail as usual. The user can then add the new connection manually. |
| 17:00 |
|
garycmartin: that's something we already do. I remember that not doing so was a PITA in the past. |
| 17:01 |
|
cjl_afk is now known as cjl |
| 17:01 |
garycmartin |
silbe: This one has a clear/neat UI exposure to my eye. The palette for an AP should have an entry for something like "Forget this favourite network", the credentials could then be removed so NM doesn't try to reconnect. |
| 17:02 |
silbe |
garycmartin: this would be nice to have as well, but is a different issue. |
| 17:02 |
garycmartin |
silbe: currently there's that CP hack for deleting all credentials. |
| 17:03 |
silbe |
garycmartin: what I meant is the ability to tell NM to stop all automatic connection attempts |
| 17:04 |
garycmartin |
silbe: So you meant to tell NM don't use any AP, or don't use any Ethernet? |
| 17:05 |
silbe |
garycmartin: exactly. At least not until manually instructed otherwise. |
| 17:05 |
garycmartin |
silbe: isn't that covered by your next req "Easy access to powering down a device class"? |
| 17:06 |
silbe |
garycmartin: it can be covered by that, but can also just work the way it currently does (i.e. choosing Disconnect will stop all automatic connection attempts) |
| 17:07 |
|
garycmartin: https://bugs.sugarlabs.org/ticket/1802 |
| 17:09 |
|
garycmartin: if we agree about the need to expose rfkill / disable wifi/wwan/wimax in the Frame, we don't need to worry about the "stop all automatic connection attempts" one. |
| 17:09 |
garycmartin |
silbe: so that is fixed now? Mesh still auto-connects if you disconnect from it I thoungh. |
| 17:10 |
|
s/thoungh/thought |
| 17:10 |
silbe |
garycmartin: hmm, maybe. TBH I planned to "accidentally" drop mesh support. ;) |
| 17:10 |
garycmartin |
;) |
| 17:11 |
silbe |
Dextrose has been disabling it for a while and I'm not aware of anyone using it (with Sugar). Ad-hoc networks are the better solution for now. |
| 17:13 |
|
a country-wide mesh composed of laptops sounds cool, but in practice I doubt it'll work anytime soon. Hybrid solutions with local APs that mesh between themselves seem to work fine, but those don't run Sugar. |
| 17:13 |
|
the APs don't run Sugar I mean |
| 17:13 |
garycmartin |
re "rfkill / disable wifi/wwan/wimax in the Frame" that would be OK I think as long as there is only one device icon for each. So no two AP device icons because you want to have connections to both at once ;) |
| 17:15 |
silbe |
garycmartin: the Frame would show one icon per physical device (plus maybe one for additional ad-hoc networks, but let's discuss that next time). If you happen to have two wifi adapters, it would show both. |
| 17:16 |
garycmartin |
silbe: re "rfkill / disable wifi/wwan/wimax in the Frame" the UI complication might be how do you obviously re-enable it. Right now we seem to have something similar (not sure of the technicalities) set in the CP Network module. |
| 17:18 |
silbe |
garycmartin: My assumption was that NM still advertises the wireless device; we just can't use it. So we'd continue to show the Frame device icon, turning "Disable wireless networking" into "Enable wireless networking". |
| 17:18 |
garycmartin |
perhaps a disabled device stays in the frame with an uncoloured white icon and a palette to re-activate. |
| 17:18 |
silbe |
garycmartin: I should check that assumption, though. |
| 17:18 |
garycmartin |
OK. |
| 17:18 |
|
silbe: next? |
| 17:19 |
silbe |
check, Frame device stays on "nmcli nm wifi off". |
| 17:19 |
garycmartin |
#topic Ability to restrict a connection to a single AP (BSSID) |
| 17:19 |
silbe |
with NM 0.8 that is - I don't run NM 0.9 yet (for obvious reasons) |
| 17:19 |
|
CanoeBerry has quit IRC |
| 17:20 |
garycmartin |
Is this something for a deployment to control what networks laptops are connected to, or something you see for regular users? |
| 17:20 |
silbe |
garycmartin: there's two reasons for this. One is the use case mentioned above where the SSID is the same for different networks. |
| 17:21 |
|
garycmartin: the other reason is that allowing roaming causes periodic scans for APs that a) drain power and b) have a performance impact. |
| 17:24 |
garycmartin |
silbe: So roaming is on by default? |
| 17:24 |
|
(at the moment) |
| 17:26 |
silbe |
garycmartin: it's enabled by default and we don't expose a way to disable it, yep. |
| 17:26 |
|
or to phrase it better: we don't support disabling it. |
| 17:28 |
garycmartin |
silbe: so if we get to make our own custom authentication dialogue this time, this could be something like a check box when entering the credentials, "disable roaming for this network", or perhaps "only connect to this BSSID". Sorry for the horrible wording but you get the idea I hope? |
| 17:28 |
silbe |
garycmartin: that's about how I imagined it to work, yup. Just an additional checkbox on the credentials dialog. |
| 17:29 |
garycmartin |
OK, reasonable with some word smithing. |
| 17:30 |
|
silbe: Let me skip your 'Nice to have', I think I had an automatic solution for that one up above, maybe? |
| 17:32 |
|
(using the BSSID to look for credentials after SSID credentials fail) |
| 17:33 |
|
(and prompting for new credentials if the BSSID is unknown) |
| 17:33 |
silbe |
garycmartin: it would be wireless-specific (we need the same ability for modems etc.) and I'm not sure whether it'd work in all cases in practice. But people can still use nm-connection-editor, so it's not that important. |
| 17:34 |
garycmartin |
OK. next topic :) |
| 17:34 |
|
#topic Suggested design changes |
| 17:38 |
|
silbe: "AP palette" can we not avoid needing to list extra connections for the same SSID (and avoid needing to manually add another). By using some of the above SSID/BSSID tricks? So the user just clicks the AP icon and in the background it tries credentials for the BSSID if it has them and then tries SSID if it has them, and then prompts for credentials automatically? |
| 17:39 |
silbe |
garycmartin: as mentioned above, we unfortunately can't rely on BSSID-locking to be sufficient. |
| 17:40 |
garycmartin |
silbe: you mean in the case of modems? |
| 17:42 |
silbe |
garycmartin: no. Imagine the school using a set of APs with default SSID and roaming, and some other party using the same AP with the same default SSID. You'll want roaming to be enabled for the first network, but there are still two different networks that need different settings. |
| 17:44 |
|
I refuse to think about two different schools both using the setup as outlined above. ;) |
| 17:45 |
|
garycmartin: however we still have the option of keeping the UI the same for the up-to-one-connection case and also exposing the additional complexity if there really are several connections configured for the same AP. |
| 17:45 |
garycmartin |
trying to get his head around it. |
| 17:46 |
silbe |
s/also/only |
| 17:47 |
|
garycmartin: it'll make your head hurt. The problem is that SSIDs are supposed to be unique to a network, but in practice aren't. |
| 17:48 |
|
things are slowly getting better as AP vendors have realised their mistake and start shipping with a random part in the SSID, but it's just a four-digit hex number, so given the number of AP sales there's still a good chance you'll encounter a different network that has the same SSID. :-/ |
| 17:49 |
garycmartin |
silbe: can there be a number of credentials stored for the same SSID and just have NM work it's way through, and prompt for yet more credentials if they all fail. With the credential dialogue having the "disable roaming for this network", or "only connect to this BSSID" check box as mentioned above? |
| 17:59 |
|
thinking a tick box with "Allow roaming for this network" is the best wording I can think of so far. The question is should it default to on or off ;) |
| 18:02 |
silbe |
garycmartin: it might be possible to hack that on the Sugar side (something I'd like to avoid - I'd rather get *rid* of existing custom code like for the ad-hoc networks). While we're covering most cases now, it's not really generic. The question is whether we should trade the genericity for slightly (IMO) reduced UI complexity. Remember that we only need to increase UI complexity for those cases that are complex in reality. |
| 18:06 |
garycmartin |
silbe: can we automatically detect that complexity and only expose new controls in such cases? Even just adding palette menu entries for manual options drastically increases user cognitive load. |
| 18:07 |
silbe |
garycmartin: "Allow roaming for this network" sounds good. The default should probably be ticked as that's what we've done so far. Unticking it will prevent connectivity if roaming is available, while ticking it will "only" improve battery life and network performance. |
| 18:07 |
garycmartin |
Sounds, sensible. |
| 18:08 |
silbe |
garycmartin: we can simply choose not to add the option for adding new connections, or maybe make it dependent on a Control Panel setting. |
| 18:09 |
|
garycmartin: something like the "Expert user mode" or "Show advanced settings" option that some applications have |
| 18:09 |
|
"Allow complex network configurations" |
| 18:10 |
garycmartin |
silbe: Hmmm, not a fan, often the rocky road to UI nightmare land ;) |
| 18:11 |
silbe |
garycmartin: fair point. OTOH I fear we're trading "no ceiling" for "low floor". |
| 18:12 |
|
though TBH I wouldn't aim for "no ceiling" w.r.t. to offering in-Sugar connection editing anyways. Just the ability to use whatever connection got configured some other way. |
| 18:12 |
garycmartin |
silbe: also a fair point, but if we just hide stuff in expert mode, we likely don't make the effort to solve the hard problems of making it work for "low floor" |
| 18:13 |
|
silbe: You ok for time? Shall we move onto next? |
| 18:14 |
silbe |
garycmartin: I don't think it's worth the effort to make it lower floor. We're dealing with misconfigurations; the right (but not always possible) solution is to educate the operators. |
| 18:15 |
|
garycmartin: sure, as long as it's still fine with you. The sooner we cover all of it and agree on a design the better. |
| 18:16 |
garycmartin |
#topic Wireless device palette |
| 18:20 |
|
silbe: "Connect to hidden network" option is all good for me. Given that we will always need to show a wireless device icon in the frame so the UI for hidden SSIDs can be accessed. I think the AP icon only shows in device frame when you first connect to one (think it's worked differently, and with different bugs in the past remember a time when there were duplicates you couldn't get rid of with empty palettes)? |
| 18:22 |
silbe |
garycmartin: not sure I understand. The wireless device icon should always be shown in the Frame. If we're neither connected nor trying to connect, it's just a light-grey circle on the dark-grey Frame background. |
| 18:23 |
|
garycmartin: it also currently has an empty palette in that state. Something we should fix in the process. |
| 18:24 |
|
The primary palette should contain some indication that it's a wireless device. |
| 18:25 |
garycmartin |
silbe: Ah maybe the empty palette it what I'm thinking of, I'll check on a current XO-1 os21 build just to make sure later. |
| 18:25 |
|
silbe: +1 |
| 18:26 |
|
silbe: For "Disable all wireless devices" option is this actually for powering down the HW, or just to have NM ignore it. Just wondering how this relates to the current CP network/power settings (e.g. would we plan to drop the CP settings and 'move' the concept to the device frame icon). |
| 18:31 |
silbe |
garycmartin: It should power down the device, but at least for NM 0.8 it does not yet. I've seen rfkill mentioned together with NM 0.9, so it might already be implemented. Or we might need to tweak something on the kernel side to make it work on XOs; I don't know yet. |
| 18:35 |
garycmartin |
silbe: OK. Hmmm, so if I set the current CP Network module to turn off wireless radio power, the frame wireless icon should vanish (goes to try)? |
| 18:36 |
|
lucian has quit IRC |
| 18:37 |
silbe |
garycmartin: good question; I'll check |
| 18:37 |
garycmartin |
silbe: grey circle, with a blank empty palette. |
| 18:38 |
silbe |
garycmartin: yup :) |
| 18:38 |
|
note that it doesn't actually power down the device either |
| 18:39 |
garycmartin |
hmmm, unfortunately when you pop radio power back on again, it goes into a mesh search first. My AP still isn't showing in neighbourhood.... |
| 18:39 |
silbe |
so it's probably the same functionality that I'd like to expose in the Frame |
| 18:39 |
|
lucian <lucian!~lucian 78-86-217-168.zone2.bethere.co.uk> has joined #sugar-meeting |
| 18:40 |
garycmartin |
....and there it is (AP), unfortunately the mesh cycle has completed and the XO is now on Mesh 1. |
| 18:40 |
silbe |
garycmartin: one of the reasons I'd like to a) get rid of mesh support entirely and b) move the ad-hoc auto-connection code to NetworkManager. |
| 18:41 |
garycmartin |
...using the mesh disconnect item from the frame device makes the frame mesh icon vanish! Interesting ;) |
| 18:41 |
silbe |
hu? |
| 18:41 |
|
sounds like a bug |
| 18:41 |
|
what version of Sugar is this? |
| 18:42 |
|
not that I care too much ;) |
| 18:43 |
garycmartin |
yep. Ok after a delay the mesh device icon has now re-appeared (should never have gone away). And the AP device icon is now coloured as per my network, but not connected, oh joy. |
| 18:43 |
|
I'm testing on an XO-1 with os21, reports Sugar as 0.92.1 |
| 18:44 |
silbe |
interesting. so maybe some of the recent weirdness wasn't my NM support refactor attempts... |
| 18:45 |
garycmartin |
Mesh is now in a cycle where the mesh device icon appears, pulses for a bit, and then vanishes again (always trying to connect to Mesh Network 1 and none of the others). |
| 18:46 |
|
goes to click his AP icon to see if it'll manually re-connect there. |
| 18:46 |
silbe |
garycmartin: if you can reliably reproduce a situation where the device icon in the Frame and NetworkManager get out of sync, please file a ticket, including output of nm-tool and full syslogs (/var/log/messages on Fedora I guess). |
| 18:46 |
|
garycmartin: same with any other weirdness of course |
| 18:46 |
garycmartin |
:) |
| 18:47 |
|
Connected fine to my AP when I clicked, no more mesh device attempts appearing in the Frame. |
| 18:48 |
|
OK, back on topic. |
| 18:48 |
silbe |
I'd like us to reengineer most parts of the NM client code for 0.94 (it's been "extended" one too many times), but we still need to support 0.92... |
| 18:48 |
|
ok, let's discuss future design again. |
| 18:49 |
garycmartin |
silbe: for "GSM = Modem device palette (frame)" I've only seen screenshots of the current GSM support and the CP settings module, and have no devices I could test with anyway. As I remember there is only one page of configuration settings, so if you have two separate GSM modems with different configuration needs and/or different mobile operator connection details (more likely), you currently need to re-edit the settings each time you switch. |
| 18:51 |
silbe |
garycmartin: that's my understanding as well and I don't have any device to test with yet either |
| 18:53 |
garycmartin |
Hmmm. It's beginning to dawn on me that we may want to use the CP as the UI/location for many of these new dialogues/credential input pages. I'm remembering how Eben was often mentioning how he wanted things like device frame icons to link to specific CP modules. |
| 18:54 |
silbe |
Makes sense. |
| 18:56 |
|
this will be "fun" to implement ;) |
| 18:56 |
garycmartin |
always seemed a sound idea, and perhaps raising a CP AP module, (or Modem module) directly for might be the way to implement the extra UI needs. |
| 19:00 |
silbe |
garycmartin: we could show a generic connection list in the CP; if we trigger adding a new configuration (for an as-of-yet unknown AP) we simply pre-fill the SSID. |
| 19:01 |
|
garycmartin: not clear on the complete design yet (esp. adding / editing connections), but I'm sure we'll come up with something workable. |
| 19:01 |
|
garycmartin: just for reference, you could take a look at nm-connection-editor. |
| 19:04 |
|
garycmartin has quit IRC |
| 19:10 |
|
garycmartin <garycmartin!~garycmart78.150.254.219> has joined #sugar-meeting |
| 19:10 |
garycmartin |
silbe: sorry network fell over I think. |
| 19:11 |
|
silbe: Well I think I'll need to wrap up now anyway hopefully the logs will help clarify some points and get the ball rolling (need more folks eye balls before making any real decisions). |
| 19:13 |
|
silbe: I'll reply to your email later and link to the meeting logs here, hopefully will get some more feedback offline. |
| 19:14 |
silbe |
garycmartin: ok, thanks! Should we try to do some summary already so the others only need to chime in whether they have better ideas? |
| 19:15 |
|
(re-reading what you wrote I guess the answer is "no, not yet") |
| 19:16 |
garycmartin |
silbe: What would be good to pull together is a page with screen shots of the current related UIs so we are all on the same page as where we are now and where we want to be. |
| 19:18 |
|
silbe: I'll try to write more in email reply than just a link to the meeting logs, so folks have an idea where our discussion went. |
| 19:19 |
silbe |
garycmartin: ok, I'll try to collect some screenshots. Maybe tch or m_anish can do the ones for the GSM device... |
| 19:19 |
garycmartin |
silbe: OK have to go, thanks for helping explain your email details! |
| 19:19 |
silbe |
garycmartin: looking forward to your mail. |
| 19:19 |
garycmartin |
#endmeeting |
| 19:19 |
meeting |
Meeting ended Sun Jun 5 19:19:48 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot. (v 0.1.4) |
| 19:19 |
|
Minutes: http://meeting.sugarlabs.org/s[…]-05T16:17:34.html |
| 19:19 |
|
Log: http://meeting.sugarlabs.org/s[…]11-06-05T16:17:34 |