General networking stack enhancements
How can we improve the general networking / getting online experience we give users in Natty?
We should select whether to still use dhcp3 as default or move on to isc-dhcp 4, discuss upgrade to wpasupplicant 0.7, NetworkManager / ConnMan versions, etc.
Blueprint information
- Status:
- Complete
- Approver:
- Martin Pitt
- Priority:
- Medium
- Drafter:
- Mathieu Trudel-Lapierre
- Direction:
- Needs approval
- Assignee:
- Mathieu Trudel-Lapierre
- Definition:
- Approved
- Series goal:
- Accepted for natty
- Implementation:
- Implemented
- Milestone target:
- ubuntu-11.04-beta-1
- Started by
- Mathieu Trudel-Lapierre
- Completed by
- Mathieu Trudel-Lapierre
Related branches
Whiteboard
mathieu-tl: Gobby notes from the session:
= Goal =
defining the requirements to give the best network experience to users in natty.
= Aspects =
* kernel drivers (e.g. broadcom)
* more work required
* the new opensource driver is currently poor quality and requires many man months of effort, this is not likely to be done within the project for natty
* network device naming
* primarily on server people are interested in naming being stable
* people prefer to have fixed names in some cases
* udev already supplies stable names for them, but they are not necessarily sane ordering
* can we use the BIOS naming at all?
* changing the rules is problematic as preseeds may rely on the current rules
* we could use a new preseed option to select any new naming
* DHCP (v4?)
* we need this to handle IPv6, should pull this in
* ifupdown
* doesn't seem to be an updated version
* wpasupplicant (0.7 ?)
* kvalo & cyphermox
* IPv6
* much of this should already be working
* testing: will need coordinated testing across many different network environments
* network manager (0.9 ?)
* this sounds like it is something we do need
* likely to switch if it is of sufficient quality in time, but this is likely to hit in a few weeks
* likely to move to system connections by default, but with ACLs
* user switch leaves a VPN open for all other user sessions, currently no plan to resolve this, primary focus is preventing exposure of the passwords etc not the connection itself
* indicator for UI (session Thu 5pm)
* need indicator support in network manager
* there is support added to network manager to make adding this kind of bells and whistles easier
Issues:
* applications attempt to use the hostname to find IP address, this not so clear if the name points to 127.x
* use of clock for dhcp leases might be problematic (block skew is not handled which can lead to use of expired allocations)
Work items (natty-alpha-3):
[cjwatson] integrate biosdevname (linux.dell.com) for stable network device naming in installer: DONE
Work Items:
[cjwatson] sync DHCP v4 from debian, merging Ubuntu-specific changes: DONE
[mathieu-tl] get wpasupplicant 0.7 from debian SVN ready + upload: DONE
[mathieu-tl] enable test runs for network manager during build: DONE
[mathieu-tl] indicator support for network manager: DROPPED
[mathieu-tl] provide a udeb package for wpasupplicant: POSTPONED
[mathieu-tl] add wpasupplicant support for debian-installer: POSTPONED
[mathieu-tl] blog how to help with NM upstream -- writing test cases (for code), other low-hanging fruit: DONE
[mathieu-tl] document setting up a DHCP v6 server: DONE
[mathieu-tl] document configuring a DHCP v6 client: DONE
pitti, 2010-11-04:
- please add WI to merge our dhcp3 Ubuntu changes to isc-dhcp (like AppArmor profile, etc.)
- stable interface names was discussed at plumbers, will be done upstream in udev (Matt Domsch/Kay Sievers/Martin Pitt)
- "wpa-supplicant support for the installer" -> what does that mean? We already run nm-applet in the live session for wlan connection?
mathieu-tl, 2010-11-08:
- for merging dhcp3 changes into isc-dhcp, it was "included" in the first sync WI, but adjusted -- it's practically done
- from what I recall, wpa-supplicant support was rather more for d-i, so splitting into further WIs. Otherwise I agree NM pretty much takes care of it, although it could be a little better integrated into ubiquity rather than expecting users to notice a tiny icon at the top of their screen.
ion, 2010-11-19:
Could Teredo be considered? For instance, Windows™ uses an implementation of Teredo by default, resulting in IPv6 connectivity even behind IPv4-only NATs. Miredo seems to be a fire-and-
• http://
• http://
mathieu-tl, 2011-01-12:
- indicator support for network manager work item marked dropped because it's already completed and covered in another blueprint: packageselectio
- added workitems for dhcpv6 documentation
mathieu-tl, 2011-01-28:
- for Teredo / miredo, we already have miredo in the archive as a universe package, it indeed seems to work fine, and there are alternative ways to enable IPv6 tunnels readily available (and pretty well documented), so I think it's fair to say it's good as it is.
- WPA support in d-i set to POSTPONE due to issues during testing (I lack necessary hardware), and the fact that Debian is already very active in getting this support in (see http://
mathieu-tl, 2011-02-15:
- https:/