Sync ndppd 0.2.5-2 (universe) from Debian unstable (main)

[Jean-Michel Vourgère]

Please sync ndppd 0.2.5-2 (universe) from Debian unstable (main)

Changelog entries since current yakkety version 0.2.4-1:

ndppd (0.2.5-2) unstable; urgency=medium

  * Drop ndppd-dbg package.

 -- Jean-Michel Vourgère <email address hidden> Thu, 21 Apr 2016 03:07:21 +0200

ndppd (0.2.5-1) unstable; urgency=medium

  * New upstream version:
    - Fixed FTBFS with GCC 6. (Closes: #811756)
    - Fixed need to have interface in promiscuous mode.
  * Enabled all compilation hardening.
  * Switched to automatic debug symbols system. ndppd-dbg is now a
    transitionnal package.
  * d/control: Switched Vcs-Git to a secure URL.
  * Bumped policy to 3.9.8: No change required.

 -- Jean-Michel Vourgère <email address hidden> Mon, 18 Apr 2016 22:33:13 +0200

[Jean-Michel Vourgère (jmv-deb)]

Hi

The killer bugfix is that ndppd 0.2.4 needs the interface to be in promisc mode for ndppd to work. This means the package is badly broken.

If you are reluctant to take this version, someone should at least backport the fix:
https://github.com/DanielAdolfsson/ndppd/commit/cb23cdbeac158b9e93425fa22fe89235f08cef7b
This commit is not really minimal, since it also add some logging. But it is the nearest thing I could find.

That killer bug is documented there:
https://github.com/DanielAdolfsson/ndppd/issues/13

--
nirgal@d.o

[Daniel Holbach (dholbach)]

I synced the package for the 16.10 release. Since the archive for 'yakkety' isn't open yet, it's sitting in the queue for the archive admins: https://launchpad.net/ubuntu/yakkety/+queue?queue_state=1&queue_text=

To get this into xenial (16.04), we will need to follow https://wiki.ubuntu.com/StableReleaseUpdates - could you provide a test-case for the broken vs fixed package?

[Michael Terry (mterry)]

I'm unsubscribing ubuntu-sponsors until there is an SRU patch here to sponsor. But please re-subscribe them when there is! Seems like a good fix. Thanks.

[Marco (m-klm)]

The bug breaks any reasonable use of ndppd if the initial description is correct, it certainly breaks the setup I'm currently evaluating. I'm using a VM to test a networking setup for an unrelated project, thus it's more complicated than it'd be on real hardware.

My configuration uses ndppd to establish multiple IPv6 subnets in place of the usual /64 ISP assignment for LXD containers, while the ISP doesn't actually delegate the network to my host.

The VirtualBox VM environment is set up as follows:
- 1 ethernet adapter configured as a bridge with my physical nic, there's a DHCP server on the same network
- 1 ethernet adapter on a host only network, ip fc00:1234::ffff:ffff:ffff:ffff/64

The VM itself is configured as:
- Ubuntu 16.04 server x64
- The bridged nic (enp0s3) is configured to use dhcp and practically only used for apt
- The host only nic (enp0s8) is simulating the actual network of interest
- The nic veth1234 is connecting to the LXD container (p2p, set up by LXD)
- net.ipv6.conf.all.forwarding=1 in /etc/sysctl.conf
- LXD, bridging disabled
- ndppd installed
/etc/network/interfaces:
auto lo
iface lo inet loopback

auto enp0s3
iface enp0s3 inet dhcp

auto enp0s8
iface enp0s8 inet6 static
        address fc00:1234::1/127

        post-up /sbin/ip -6 route add fc00:1234::ffff:ffff:ffff:ffff dev enp0s8
        pre-down /sbin/ip -6 route del fc00:1234::ffff:ffff:ffff:ffff dev enp0s8

allow-hotplug veth1234
iface veth1234 inet6 static
        address fc00:1234::5:ffff/112
/etc/ndppd.conf:
route-ttl 30000

proxy enp0s8 {
 router yes
 timeout 500
 ttl 30000

 rule fc00:1234::1/64 {
  auto
 }
}

The LXD container is configured as:
- name test
- Image source images:ubuntu/xenial/amd64
- default nic device removed
- new nic device: lxc config device add test veth0 nic nictype=p2p name=veth0 host_name=veth1234
/etc/network/interfaces:
auto lo
iface lo inet loopback

auto veth0
iface veth0 inet6 static
 address fc00:1234::5:1/112
 gateway fc00:1234::5:ffff
 dns-nameserver 2001:4860:4860::8888 2001:4860:4860::8844

With Xenial's ndppd 0.2.4 it won't be possible to ping the LXD container from the host, only from the VM or LXD container):
$ ping6 fc00:1234::5:1
PING fc00:1234::5:1(fc00:1234::5:1) 56 data bytes
From fc00:1234::ffff:ffff:ffff:ffff icmp_seq=1 Destination unreachable: Address unreachable

Installing the ndppd 0.2.5 package from the Yakkety repo on the VM fixes it:
$ ping6 fc00:1234::5:1
PING fc00:1234::5:1(fc00:1234::5:1) 56 data bytes
64 bytes from fc00:1234::5:1: icmp_seq=1 ttl=63 time=0.815 ms

By observing the traffic in Wireshark it can be seen that the VM host only nic receives neighbor solicitation requests, but nothing responds - ndppd doesn't pick them up.

The regression risk should be zero as the 16.04 package appears to be unusable in its current form.