Enabling IPv6 Privacy Addresses

At the last UDS, we once again discussed the state of IPv6 support in Ubuntu. We're in the process of making Ubuntu really rock with IPv6, and this comes with decisions and hard work.

One of these decisions was to enable IPv6 Privacy Extensions by default. In other words, rather than having an IPv6 address that is derived directly from your network device's MAC address, you'll now have that, but supplemented with time-based temporary addresses, randomly created, used to establish outgoing connections to systems. This leads to higher privacy; because it makes it harder for an eavesdropper to identify whether different addresses really refer to the same node (that's because the *prefix*, which network you come from, would change, but never the last part of the address, unless using privext). How all of this works is described in more details in RFC 4941.


And leading to this, the hard work. We've recently enabled IPv6 privacy extensions through a new file shipped by procps: /etc/sysctl.d/10-ipv6-privacy.conf. Sysctls are parsed early on in the boot process, but perhaps not early enough; which lead to an issue: on some systems, one would see some interfaces with privext enabled, and some others without. This appears to be because some interfaces (eth0 on my system) are initialized early enough in the boot process that it comes up before the sysctl settings are applied.

With this, another issue: there are three types of sysctl settings for ipv6: default, all, and per-interface entries. According to kernel documentation and help strings; default is meant as the ... default for future interfaces that would get created. At least, that's how I get it. Per-interface entries are obvious: you're just changing the setting for that particular interface. But what about all?

Well, it turns out net.ipv6.conf.all.anything doesn't really do anything, except for forwarding and disable_ipv6. These two options are already handled specially by kernel code. The particular setting that interested me was use_tempaddr though, and isn't being propagated (to the per-interface entries) or use globally to enable privacy addresses on all interfaces; which is something you'll likely want if you are looking to enable privacy extensions at all. Take this example: if you're using a mobile system, you might have wired and wireless connected at the same time, and may want to get up, unplug wired, and move around to a different spot, with or without suspending. While NetworkManager will in time allow toggling privacy extensions per connection, you shouldn't need to manually change this for a default install, on a typical, mobile worker day.

So I started writing my first ever kernel patch: having the net.ipv6.conf.all.use_tempaddr sysctl propagate its value to all the other interfaces already present on the system when the value is changed. It's currently being reviewed before I work towards having it included in the kernel proper. Reviews for that patch are welcome on the kernel-team mailing list.

I've now tested that this solves the issue of applying that particular sysctl at boot time; much like it appears to be expected to work by just about everyone if I'm to believe research I've done on the web on that subject. If there are brave souls wanting to test this, head over to my NM PPA. You'll need to be running Precise, and the package you'll want is linux 3.2.0-4.11~mtrudel2. Since this is a custom hacked up kernel package (but I tried hard to follow the Kernel Team's procedures), standard warnings of caution and the usual "if your system gets broken you get to keep both pieces" apply... but I'm running that package too ;)

Ubuntu Global Jam event in Montreal

With the Ubuntu Global Jam fast approaching, the Ubuntu-Quebec community is once again organizing an event to get together, find, track down and fix bugs, in Montreal (and inviting anyone interested in helping out to join us). The event will take place Saturday and Sunday, September 3 & 4, 2011, starting around 9 am.

Many thanks to komputes for doing the work of organizing the event and getting everything ready.

This time, our local Global Jam event will be hosted at the Canonical offices here in Montreal! Huge thanks to management for allowing us to use the office.

So if you're in or around Montreal, come join the local Ubuntu-Qc members and let's make Oneiric really rock! Just so we know what to expect, please make sure you register your presence on the LoCo directory event page. You can also watch our wiki page for more information.



Canonical Canada Limited
4200, boulevard Saint-Laurent
Suite 1200 (12e étage)
Montréal, QC
H2W 2R2
Canada





Avec le Global Jam qui arrive à grand pas, l'équipe Ubuntu-Québec récidive et organise une fois de plus un événement à Montréal et invite ses membres (et tous les intéressés!) à se réunir pour trouver, rapporter et régler des bogues. L'événement se tiendra les Samedi et Dimanche, 3 et 4 septembre 2011, à partir de 9 heures.

Un gros merci va à komputes pour le travail d'organisation de l'événement.

De plus, on tient à remercier Canonical pour avoir accepté d'héberger l'événement!

Si vous êtes dans la région de Montréal, vous êtes donc invités à vous joindre aux membres d'Ubuntu-Qc et nous aider à rendre la version 11.10, Oneiric Ocelot, vraiment parfaite!

Pour nous permettre de savoir combien de personnes sont attendues, n'oubliez pas de signifier votre présence sur la page à cet effet sur le LoCo directory. Vous pouvez également obtenir plus d'information sur notre page wiki.

Voir ci-haut pour l'adresse ;)

Hacking on usb-modeswitch, part 1

Lately I've been spending time porting the usb_modeswitch_dispatcher tcl script from the usb-modeswitch package to C.

While being a great exercise at both my knowledge of Tcl (almost non-existent) and my knowledge of C; it's also been very interesting so far to look at how things were being done to "switch" USB devices from a storage mode into modem mode.

One of the problems I'm hitting now is balancing between performance and disk space usage. In an attempt to cut down on installed space, usb_modeswitch data has been all compressed into one tarball, comprising 162 small text files with the necessary vendor and product IDs expected before, after switching and the magic message to do the actual switch (see Debian bug 578024 for the rationale for compressing files). Having a compressed tarball is great to save space, but would tend to cause delays at boot time when the file needs to be uncompressed (perhaps multiple times) during boot-up. On the other hand, separate files take more space, which is especially a problem for those who don't need usb-modeswitch on their systems.

I'm now working on quantifying the performance impact between compressed and uncompressed, as well as trying to figure out the actual size impact between both options for the Live CD. Theoretically, there should be little difference or even higher space usage with the compressed tarball on the LiveCD (because you can't really compressed something already compressed). I'll find out and post results here. As for the performance impact, there may not be much to look through the compressed tarball and extract one file from it, but every little bit of gain can help.

Jamming in Montreal

I'll shamelessly copy Jorge's post here to present the Montreal jam:

We're doing some unity testing this weekend. We were about 11 at some point yesterday, and we're 7 this afternoon.

Sadly, we didn't happen to have our own Jason to answer user questions, so I did the best I could ;)

Global Jam in Montréal

So we're doing it again!

It's obviously getting a bit on the late side to announce this, but I only got the confirmation for our location this weekend -- after work or when I had a second, I wrote the Ubuntu-Quebec mailing list invitation, dented about the event, and created the LoCo directory entry for this event already.

So once again, people wanting to help improve Natty Narwhal or who would like to know more about bugs, triaging, fixing bugs, testing the new release or even writing documentation for applications, and living around Montreal, Qc, don't hesitate to come join us at SUPInfo Montréal this weekend. The closest subway station is McGill on the green line, then about 3 minutes walking time ;)

We're holding our sessions on *both* Saturday and Sunday, from 11am to 5pm on each day.

SUPInfo Montréal
752 Sherbrooke West
Montreal, Quebec



Agrandir le plan

Idea #27250: Auto eth0 isn't very user friendly. Many people wont know what it is.

The Problem

In case you didn't already figure it out, the title refers to a quite popular idea on Ubuntu Brainstorm. It also refers to a bug report against NetworkManager in Launchpad: bug #386900.

This is one issue I'd particularly like to solve soon. Although it most likely won't change for Natty (given that we're in Feature Freeze, and UI Freeze incessantly), I believe the question truly can be brought to a concensus and fixed early in the Oneiric cycle (and actually be made available upstream for everyone's benefit).

I think much of the issues coming from this bug report stem from diverging expectations of people who just care about their wired connection working and likely don't need to change it all that often, and people who actively use NetworkManager's connection profiles to achieve various things.

First, some background:

Why "Auto eth0" ?

The name "Auto eth0" comes from... well, the fact that it's a connection that was created automatically by NetworkManager with the simplest default settings (that is, just use DHCP to set an IP address), and the fact that it was created for the interface eth0. As such, people with multiple wired network cards would then get one "Auto XXXX" profile for each wired card. This profile should take care of 90% of all use cases, since most people will just want their system to be plugged in, their home router to hand over an IP address and be able to get online.

What's this with profiles ?

I just mentioned that the connection names shown are profiles. This is actually very important to me and quite a lot of people, because there are often cases where one would want to use specific network settings when at work and while at home. In other words, one could use "Auto eth0" at home with a simple setup, and benefit from a "At work" profile which sets a static IP address, or different DNS search strings (what would let your computer access "planet", instead of "planet.ubuntu.com" in Firefox, for instance).

Why so many issues ?

I guess this all falls apart when you consider that most people probably won't use alternate profiles for wired connections. DHCP tends to get most things right from the start, which make profiles not very useful unless you want to do very specific things with your connection.

Add to this the fact that not everyone knows that eth0 is what Linux calls your first wired network card (instead of say "Local Area Connection" as I believe it is on Windows), and you have a nice little mess to untangle.

Fixing all of this

I can't say I have all the answers. It's still unclear to me how much information is absolutely required, and I'm well aware that we can't really please everyone.

However, I've added a proposal to the brainstorm idea (Solution #7). It goes like this:

I'm suggesting the name of the profile to be something like "Default". It should not be tied to any particular adapter.
This way, any new connection use that profile which will have default settings to use DHCP and the usual (as Auto eth0 is set). All adapters could share it, so adding a new interface to a computer would still just "work".

For notifications, I suggest the following changes:

- The title should mention "Wired network", and probably the same of the interface (eth0 in most cases).
- The text of the notification should say:

Connection established, using profile "Default"

or whatever profile in use.

Furthermore, perhaps items in the network menu shouldn't list the full details of the network card (it's full name from udev as it does now). Instead, the interface name would be sufficient. I expect people who use multiple cards to know what eth0 and eth1 mean and refer to.

Lastly, drop the "Auto" from user-created wireless network profiles too. Since they are created by the user and carry the name of the wireless network, "Auto" is both unnecessary, and possibly incorrect (since people can change the settings after creating it).

I'd very much like anyone with an opinion on this to vote on Ubuntu Brainstorm for the idea they prefer, and comment with why my suggestion breaks things for them if it does. I certainly could have forgotten things. Comments on this blog are welcome too ;)

This weekend's GeekFest in Montreal

We had a table at this weekend's GeekFest geek festival in Montreal. It was awesome! Tons of people, and even better, tons of interest about Ubuntu and our LoCo team.

We gave out CDs, stickers, some extra FSF stickers I had in my backpack, and generally told people all they wanted to know about Ubuntu, gaming on Ubuntu (we had a demo of World of Goo running on one of the laptops for a good part of Sunday), and the Ubuntu Quebec LoCo team. It was very interesting to hear people tell us they already knew about Ubuntu or used it at home, at work, etc; yet still didn't know about the local community team and the help resources we offer.

One of the things we focused on was how Ubuntu Quebec has a mailing list and forum to provide help, announce events and just generally discuss things, as well as our IRC channel on Freenode (#ubuntu-qc, for those who don't know!). Lots of people were surprised to hear of a user group for Ubuntu but very interested by it. I printed and gave out nearly 40 business cards with contact information for the LoCo team.

I am very happy to have been helped by two very active members of the team: Christian Parent (Mobidoy) and Philippe Gauthier (deuxpi), and joined on Sunday by Eric Beaurivage (sipherdee), another LoCo team member. Without them, we certainly couldn't have been able to speak to so many people, and we definitely wouldn't have had any time to visit the other kiosks (can't just stay sitting... if you hold a kiosk in a conference, just got to go see the other things!).

Christian always has very cool ideas, this weekend it was to show his new laptop sticker (a mouse pad glued to the laptop).

Some other interesting aspects:

To our right was the kiosk of devLAB, a project to start programming contests, identify new technologies, etc... Did I get this all right? Sure hope so. The great thing too is that they were interested by our Global Jam ideas, so there may be collaboration on that aspect to come for this cycle's Global Jam event in Montreal. That still needs to be discussed on the mailing list.

We met with someone from Foonzo Café, a new café in Montreal near Peel metro which runs all their systems on Ubuntu! They have some 80 seated places, so we may consider holding the Montreal release party there for Natty. Check how the discussion unfolds for this on our mailing list.

And last but not least, we met with Carlos and his brother who started "Carlito's Contraptions". They work on Nao the robot to develop applications, have it do stuff... While Nao doesn't exactly run Ubuntu (it's really a stripped down Linux with the bare minimum), their development systems are Ubuntu. They were nice enough to allow us to take action shots of Nao with a Ubuntu logo sticker. First it was on a GeekFest pin attached to Nao with sticky-tack, then they put another sticker directly on Nao's right arm. Rock on guys!

Take a look at all the pictures on my Picasa Album: "GeekFestMtl 2011".

How to contribute to NetworkManager (or nm-applet)

Since NetworkManager (and all of the attached parts; VPN plugins, clients, backend...) is such a complex system, we're always looking for people to help out in whichever way they can.

One of the things I'd like to focus on this cycle (even if this announcement should have come long ago), is test cases and generally getting a good grasp of what works and what doesn't with NM, the clients, or plugins. Test cases are useful for us to know that things are performing as they should and even more important where development snapshots are involved, given the "in flux" nature of the code we're providing users. It's not that it's unstable code really (in fact, it's clearly not... 0.8 is now a stable branch that got tons of bug fixes, and seems rock solid if I believe the type and number of reports we get). Still, I'm interested to know about failures. That's partly why I wrote a number of test cases on the Desktop Testing Team tracker. There's a need for more though, and that's where the help of the community comes in.

If you know of some things that are important to you in NetworkManager, nm-applet, or the VPN plugins, write test cases for them! It will help everyone make sure those remain working, iron out the small annoying bugs, and just improve on the overall usefulness of NetworkManager.

Obviously, test cases and testing isn't the only place you can help. Are you annoyed at some little thing that works, but you'd love for it to go one step further in providing an amazing experience? Then we need you.

It's also very much the way I started contributing to Ubuntu, dealing with small annoyances which would make my life easier in using the desktop every day... And it was as simple and providing support for saving group or user password for the VPNC plugin.

I can already think of a few more of these small things, such as hiding the SIM PIN when prompted for it (since it's a password)...

I've started identifying small (but important!) bugs like this in Launchpad. As for other projects, look for the 'bitesize' tag. Here's an example.
They may not all be tagged bitesize, but if there's something that almost works for you and you want to take a look at fixing it, jump in! We'll all be glad you did. The same principle applies to many of the bugs marked as Wishlist, which are good ideas, maybe some need more discussion upstream, but they are all ready to be worked on (and have varying degrees of difficulty).

If you're looking to work on NM, the first thing you may want to look at is the wiki at http://live.gnome.org/NetworkManager. It's generally also a good idea to subscribe to the mailing list (see the previous link), so you can discuss changes with the community at large. Finally, there's truly no place more useful than the DebuggingTips page even for non-technical users. It's where you can poke NetworkManager to tell you exactly what goes on. In. Details.

In the cases where changes can be reasonably integrated into Ubuntu and/or Debian directly, feel free to submit merge requests and patches. This includes helping out fixing issues in the growing indicator patch for the applet :)

Finally if you're just curious and want to help out, you should know that there is a lot of work being done at the moment to simplify NM in various ways; all of which to in time become version 0.9. If you want to know more about the plans for NM 0.9, it's here: http://live.gnome.org/NetworkManager/ApiSimplify

When I'm connected I'm always happy to answer questions and help out in any way possible, both on NM and general desktop-ish stuff. You can reach me on #ubuntu-desktop or #nm on Freenode. I'm cyphermox.

Natty nm-applet improvements

As those running Natty have undoubtedly noticed (and it has been noted on the Ayatana mailing list), we currently have a stop-gap measure (until we get connman and indicator-network magic!) for an indicator for network connections being nm-applet with a big ugly patch to make it work as an indicator.

In light of the discussion I'm referring to above, as well as a number of bugs that have been reported against network-manager-applet, I've been working on fixing these issues, including making the animations work again, re-adding icons for wireless signal strength and fixing the icons when connected to VPNs.

Most of this was coming from the fact that icons could not be dynamically composited by nm-applet when using libappindicator as it used to be doing. However, it's just about ready to all be live again:

All I'm waiting for is review of a merge request to provide the new icons needed. :)

Now, there is still a number of things that need to be fixed in the indicator patch and in the look and feel of nm-applet as an indicator. While this is still meant to remain a bridge until we can switch to connman and indicator-network, I'm looking forward to getting new ideas and to know about the issues you see in nm-applet's look right now. Jump in on the ayatana list and give us your thoughts!