Public bug reported:
I have a xenial (4.4.0-24-generic) machine that loses ipv6 connectivity
every time I reboot the gateway it uses.
br0 is a bridge which has eth0.2 as its only member, with (currently) 6 "scope
global temporary deprecated dynamic" (privacy) addresses, and:
inet6 2601:282:8100:3500:24c:40ff:fe1a:c570/64 scope global mngtmpaddr
dynamic
valid_lft 300sec preferred_lft 120sec
The tcpdump trace on against eth0.2 of the broken machine:
http://paste.ubuntu.com/18170606/ (fe80::1 is the gateway)
http://paste.ubuntu.com/18173670/ is the output of lspci -vvn on one of
the (quad) interfaces on the machine.
Setting the bridge to promisc and turning it back off works around the
issue. Tcpdump on the underlying eth0.2 does not.
On another (yakkety) box, running 4-4-0.14-generic, I also see the
problem: that interface is also br0, with eth0 (untagged) as its only
member.
All of the above leads me to believe that the kernel is not managing to
correctly set up (at least some?) of the multicast addresses it needs to
listen to on the bridge.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: Incomplete
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1597806
Title:
ipv6 neighbor discovery broken (on a bridge)
Status in linux package in Ubuntu:
Incomplete
Bug description:
I have a xenial (4.4.0-24-generic) machine that loses ipv6
connectivity every time I reboot the gateway it uses.
br0 is a bridge which has eth0.2 as its only member, with (currently) 6
"scope global temporary deprecated dynamic" (privacy) addresses, and:
inet6 2601:282:8100:3500:24c:40ff:fe1a:c570/64 scope global mngtmpaddr
dynamic
valid_lft 300sec preferred_lft 120sec
The tcpdump trace on against eth0.2 of the broken machine:
http://paste.ubuntu.com/18170606/ (fe80::1 is the gateway)
http://paste.ubuntu.com/18173670/ is the output of lspci -vvn on one
of the (quad) interfaces on the machine.
Setting the bridge to promisc and turning it back off works around the
issue. Tcpdump on the underlying eth0.2 does not.
On another (yakkety) box, running 4-4-0.14-generic, I also see the
problem: that interface is also br0, with eth0 (untagged) as its only
member.
All of the above leads me to believe that the kernel is not managing
to correctly set up (at least some?) of the multicast addresses it
needs to listen to on the bridge.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1597806/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
