Network Management Microconference Notes Welcome to Linux Plumbers Conference 2014. Please use this etherpad to take notes. Microconf leaders will be giving a summary of their microconference during the Friday afternoon closing session. Please remember there is no video this year, so your notes are the only record of your microconference. Please help out and add some notes: Introduction to networkd: Tom Gundersen (no slides were used) - project started around 1 year ago - 3 concepts: net devs?, links and network files (networks) - matching rules to figure what link together, inspired by udev - supporting almost all network link interfaces (incl. bridging, bonding, mac vlan, vlan, tun, tap....) - match on architecture, namespace, ... - how to interact with networkd -- library based, integrated into an event loop -- dhcp library (based on ConnMan's implementation) -- supporting dhcp4 and dhcp6 as a client, a bit of ipv6 (more to come) -- libraries will be exported so other project can use them Q: What about wifi? If you don't want to spawn a process, how could you handle wpa_supplicant? A: ip setup is done in networkd, L2 is done outside (e.g. BlueZ). We don't want to spawn it but if wpa_supplicant is running we want some way to communicate with it. Q: What about ip address/configuration provided by L2? A: Will be picked up and used? Q: What about hotplug scenarios? A: We listen to notifications. We try to setup bridging and bonding eagerly and when devices appear we add them, if they should be added By default the bridge takes the MAC from the first alias you have. You may then get different dhcp leases every time you boot. Therefore we now assign a predictable MAC address to the bridge instead. A: Do you support multilayer setups? Q: Yes :) How do we diffentiate to ConnMan, NetworkManager? - We want to be low level. Admin shall tell us what to do. It should be deterministic what should happen. Higher level APIs could be added on top of systemd-networkd. NetworkManager Status Update: Thomas Haller (slides) - around for 10 years - 1.0 planned for Nov 2014 - Trying to keep the API stable - nmcli got really powerful and supports interactive editing, tab completion. It will also support asking for password on the cmdline in the future - nmtui is an alternative curses based client - downsizing by moving parts into plugins and libraries (device type plugins, etc) - moving away from dhclient in favor of a DHCP library - system admins do not like daemons running all the time, therefore configure-and-quit support. - in older version when you stop NM it also releases and deconfigure the configuration, and reapply settings from scratch on startup. Now it will keep configuration on shutdown and reuse it when starting up. - notices configuration changes at runtime (i.e. using iproute2 or another daemon managing its network devices like libvirt) - new libnmn library Q: IPv6 tunnel devices support? A: Not yet, patches welcome Q: Did you have a look into hooking into systemd-ask-password to get the password for the network configuration (wifi) A: No. But we have a D-bus interface...(?) ConnMan Status Update: Patrik Flykt (no slides were used) - Similar in feature to NM, with the difference, highly integrated protocol support etc (DHCP, - Connections with oFono and BlueZ. - Since it is all intergrated, smaller footprint and minimal dependencies - WiMAX support has been killed. - ConnMan tries to keep the current connection alive - Typical netbook and phone use case: tethering through a USB device - A lot of work is gone into getting DHCP working everywhere, the result went into systemd-networkd DHCP library as well - Multiple agents now supported. (An agent is for example User Interface element, any user interaction) - Embedded use cases: Session support was added and policy plugin which allows per application configuration/notification/routing setups - P2P (aka WiFi Direct) support added, minimal API, no funny unused features from the standard - wpa_supplicant got a few patches as result from WiFI Direct work - People have used P2P before but they had only one WiFi chip and knew exactly what they were doing. Traffic control for multimedia applications: Alban Crequy (slides on http://people.collabora.com/~alban/d/2014/10/plumbers2014-traffic-control-multimedia.odp ) - use case: receiving streamed multimedia contenct on a mobile network. do not let other applications use all your bandwitdth while you are listening to web radio - Allow applications to request/influence rate control - challenges: shaping ingress traffic, variable & unknown bandwidth, without modifying applications - tc exists since 2.2, rules are installed via netwlink, qdisc - a network device can only control what it sends out - inbound traffic can only limited if TCP is used - How to find out why link speed is slow on unreliable networks, and what is our actual provided bandwitdh? - Ideas (bad ideas): Use different PID or cgroups. SO_MARK (needs CAP_NET_ADMIN), SO_PRIORITY, tagging socket (wrong layer...) --> New information: You *can* now look up the origin of the data (which socket) - integration issues: multiple network interfaces Q: Requirement not to touch apps: why do you need ifb, can you not policy the inbound traffic? Why do you need to queue? A: (taking this to a offline dicussion) [let's ping them for the result] Bringing WiFi P2P connectivity to higher level via ConnMan: Tomasz Bursztyka (slides) - WiFi Direct is supposed to fix the crappy Ad-Hoc setups - D-Bus API hides the complex logic of P2P. API is still experimental - Keeps track of services provided by a peer - support: scans for Peers, one on one context, temporary groups, WPS PBC on incoming connection - coming soon: persistent group handling, complex context Q: Do I pick a service name when I want to talk to do? A: Q: It would be nice if the API exposed the device type you are pairing with. Why would you hide the primary and second level device type? A: The device type is provided by other services and the information is thus not included in the p2p API DNSSEC and split DNS using unbound and dnssec-trigger (slides) - resolv.conf is too restrictive - NM collects all the dns info from various sources and writes out resolv.conf - can be disabled and taken over by the admin - have to deal with split dns views - Marcel> EDNS is broken in lots of routers. Don't expect it to be fixed or work in the future. Use TCP, your DNS should support TCP or replace it. - Speaker> The router I have did not answer TCP requests. - Marcel> connman does the whole stack systemd-resolved : Lennart Poettering (no slides were used) - Local DNS caching resolver. Client side only. resolved is system wide, glibc is per process and forces all applications to be exposed to network. We think there should be a single daemon. resolve caches are per interface resolution can be restricted to specific interfaces, or done on all interfaces solves isses with local networks v. vpns, but you will have problems if same name is used on more networks Example: Logging into VPN allows me to resolve names on remote network but I can't resolve my local printer address. cache flushing is per interface and done on config changes of that interface We ask on all networks by default. When looking up on more interfaces either the first positive or the last negative result is returned, making cache flushing simpler on the todo list is mdns and dnssd, make avahi redundant and move into resolved, transparently with compatible api systemd socket activation will be integrated DNSSEC should be built in by default resolved integrates nicely with networkd resolv.conf compat in both ways for stuff bypassing getaddrinfo resolved is exclusively a client and never a server. if you want a server use something else Q: Can you make sure VPN DNS is only used for the resources belonging to the VPN like NetworkManager? A: Generally we ask everyone and collect the answers but... A: We should. Asynchronous wrapper around synchronous glibc APIs. Many applications use asynchronous DNS libraries and bypass the libc, we only serve them with a fallback /etc/resolv.conf conent. For async DNS use glib or such stuff. libnss_resolve.so supports nss-files as a fallback. Q: What happens when local DNS servers don't follow RFC and can't be used with DNSSEC. A: We should accept that DNSSEC won't work and not use it. We should not work around it. I'm pretty sure we don't wont to use full recursion as a fallback either. https://etherpad.fr/p/LPC2014_NetworkManagement Speaker 2: Topic 1 Speaker 2 notes.