lxc-net should attempt to use ip before ifconfig, not vice-versa

Bug #1424143 reported by Steve Beattie
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
lxc (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

The lxc-net script in /usr/lib/$archtriplet/lxc/lxc-net attempts to use ifconfig first and then falls back to trying to use ip(8) in the ifup() and ifdown() shell functions. This behavior should be reversed, as ip has been preferred over ifconfig for several years now.

As an example of why, lxc-net breaks the network setup within virtualbox guests. After starting lxc-net, the route table looks like:

  ubuntu@vivid-i386:~$ route -n
  Kernel IP routing table
  Destination Gateway Genmask Flags Metric Ref Use Iface
  0.0.0.0 10.0.2.2 0.0.0.0 UG 1024 0 0 eth0
  10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lxcbr0
  10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
  169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0

This is despite the following settings in /etc/default/lxc-net:

  LXC_BRIDGE="lxcbr0"
  LXC_ADDR="10.0.3.1"
  LXC_NETMASK="255.255.255.0"
  LXC_NETWORK="10.0.3.0/24"

Switching the order in ifup and ifdown to try using ip first results in the correct netmask being applied:

  ubuntu@vivid-i386:~$ route -n
  Kernel IP routing table
  Destination Gateway Genmask Flags Metric Ref Use Iface
  0.0.0.0 10.0.2.2 0.0.0.0 UG 1024 0 0 eth0
  10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
  10.0.3.0 0.0.0.0 255.255.255.0 U 0 0 0 lxcbr0
  169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0

Looking at sh -x output when running lxc-net manually, it *looks* like ifconfig is being invoked correctly, so I don't know why it's getting the netmask wrong:

+ use_iptables_lock=-w
+ iptables -w -L -n
+ [ -d /sys/class/net/lxcbr0 ]
+ brctl addbr lxcbr0
+ echo 1
+ [ ! -d /run/lxc ]
+ ifup lxcbr0 10.0.3.1 255.255.255.0
+ which ifconfig
+ [ 0 = 0 ]
+ ifconfig lxcbr0 10.0.3.1 netmask 255.255.255.0 up
+ return

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: lxc 1.1.0-0ubuntu1
ProcVersionSignature: Ubuntu 3.18.0-13.14-generic 3.18.5
Uname: Linux 3.18.0-13-generic i686
ApportVersion: 2.16.1-0ubuntu2
Architecture: i386
Date: Sat Feb 21 00:13:27 2015
InstallationDate: Installed on 2014-12-12 (70 days ago)
InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Alpha i386 (20141212)
ProcEnviron:
 TERM=screen
 SHELL=/bin/bash
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 XDG_RUNTIME_DIR=<set>
SourcePackage: lxc
UpgradeStatus: No upgrade log present (probably fresh install)
defaults.conf:
 lxc.network.type = veth
 lxc.network.link = lxcbr0
 lxc.network.flags = up
 lxc.network.hwaddr = 00:16:3e:xx:xx:xx
modified.conffile..etc.default.lxc: [modified]
mtime.conffile..etc.default.lxc: 2015-02-20T18:15:56.552501

Revision history for this message
Steve Beattie (sbeattie) wrote :
Revision history for this message
Steve Beattie (sbeattie) wrote :

Here's the complete sh -xe output from running lxc-net start:

ubuntu@vivid-i386:~$ sudo sh -xe /usr/lib/i386-linux-gnu/lxc/lxc-net start
+ distrosysconfdir=/etc/default
+ localstatedir=/var
+ varrun=/run/lxc
+ USE_LXC_BRIDGE=true
+ LXC_BRIDGE=lxcbr0
+ LXC_ADDR=10.0.3.1
+ LXC_NETMASK=255.255.255.0
+ LXC_NETWORK=10.0.3.0/24
+ LXC_DHCP_RANGE=10.0.3.2,10.0.3.254
+ LXC_DHCP_MAX=253
+ LXC_DHCP_CONFILE=
+ LXC_DOMAIN=
+ [ ! -f /etc/default/lxc ]
+ . /etc/default/lxc
+ MIRROR=http://ubuntu-mirror.nxnw.org/ubuntu
+ LXC_AUTO=true
+ USE_LXC_BRIDGE=false
+ [ -f /etc/default/lxc-net ]
+ . /etc/default/lxc-net
+ USE_LXC_BRIDGE=true
+ LXC_BRIDGE=lxcbr0
+ LXC_ADDR=10.0.3.1
+ LXC_NETMASK=255.255.255.0
+ LXC_NETWORK=10.0.3.0/24
+ LXC_DHCP_RANGE=10.0.3.2,10.0.3.254
+ LXC_DHCP_MAX=253
+ LXC_SHUTDOWN_TIMEOUT=120
+ [ -d /var/lock/subsys ]
+ lockdir=/var/lock/subsys
+ start
+ [ ! -f /var/lock/subsys/lxc-net ]
+ [ xtrue = xtrue ]
+ use_iptables_lock=-w
+ iptables -w -L -n
+ [ -d /sys/class/net/lxcbr0 ]
+ brctl addbr lxcbr0
+ echo 1
+ [ ! -d /run/lxc ]
+ ifup lxcbr0 10.0.3.1 255.255.255.0
+ which ifconfig
+ [ 0 = 0 ]
+ ifconfig lxcbr0 10.0.3.1 netmask 255.255.255.0 up
+ return
+ iptables -w -I INPUT -i lxcbr0 -p udp --dport 67 -j ACCEPT
+ iptables -w -I INPUT -i lxcbr0 -p tcp --dport 67 -j ACCEPT
+ iptables -w -I INPUT -i lxcbr0 -p udp --dport 53 -j ACCEPT
+ iptables -w -I INPUT -i lxcbr0 -p tcp --dport 53 -j ACCEPT
+ iptables -w -I FORWARD -i lxcbr0 -j ACCEPT
+ iptables -w -I FORWARD -o lxcbr0 -j ACCEPT
+ iptables -w -t nat -A POSTROUTING -s 10.0.3.0/24 ! -d 10.0.3.0/24 -j MASQUERADE
+ iptables -w -t mangle -A POSTROUTING -o lxcbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
+ LXC_DOMAIN_ARG=
+ [ -n ]
+ getent passwd lxc-dnsmasq
+ break
+ dnsmasq -u lxc-dnsmasq --strict-order --bind-interfaces --pid-file=/run/lxc/dnsmasq.pid --conf-file= --listen-address 10.0.3.1 --dhcp-range 10.0.3.2,10.0.3.254 --dhcp-lease-max=253 --dhcp-no-override --except-interface=lo --interface=lxcbr0 --dhcp-leasefile=/var/lib/misc/dnsmasq.lxcbr0.leases --dhcp-authoritative
+ touch /run/lxc/network_up
+ touch /var/lock/subsys/lxc-net
+ exit 0

Revision history for this message
Steve Beattie (sbeattie) wrote :

And here's the patch to the lxc-net script to prefer ip(8) over ifconfig.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "lxc-net-prefer_ip.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Thank you for the patch. Would you mind posting it with a Signed-off-by to <email address hidden>?

(If you prefer I can post it)

Changed in lxc (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Changed in lxc (Ubuntu):
status: Triaged → Fix Committed
Changed in lxc (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.