| 2018-05-15 08:27:44 |
Matt Rae |
bug |
|
|
added bug |
| 2018-05-15 08:36:45 |
Matt Rae |
description |
When booting with ipv6.disable=1, vxlan will fail to initialize with the error "vxlan: Cannot bind port 4789, err=-97" which is EAFNOSUPPORT.
Expected result is that vxlan tunnels work when ipv6 is disabled.
Description: Ubuntu 16.04.4 LTS
Release: 16.04
linux-image-4.4.0-124-generic
bug is fixed in RHEL in https://bugzilla.redhat.com/show_bug.cgi?id=1445054 |
When booting with ipv6.disable=1, vxlan will fail to initialize with the error "vxlan: Cannot bind port 4789, err=-97" which is EAFNOSUPPORT.
Expected result is that vxlan tunnels work when ipv6 is disabled.
Description: Ubuntu 16.04.4 LTS
Release: 16.04
linux-image-4.4.0-124-generic
bug is fixed in RHEL in https://bugzilla.redhat.com/show_bug.cgi?id=1445054
Steps to reproduce:
Deploy two identical 14.04 nodes with the following configuration:
Add the following to /etc/default/grub then run 'sudo update-grub'
GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1"
Reboot both nodes
sudo reboot
Set up a tunnel using the following commands on each node modifying remote_ip to be the ip of the other node. modify veth0 ip to be subnet using the tunnel 10.10.10.x/24
ovs-vsctl del-port br-int vx1
ovs-vsctl del-port br-int veth1
ip link del veth0
ovs-vsctl add-port br-int vx1 -- set interface vx1 type=vxlan options:remote_ip=192.168.122.161
# remote_ip should be the ip of the other node
ip link add type veth
ip link set veth0 up
ip link set veth1 up
ovs-vsctl add-port br-int veth1
ip addr add 10.10.10.2/24 dev veth0 # on the second node use 10.10.10.3/24
Expected result is once the tunnel is configured on each side, you should be able to ping the ip of veth0 on the remote side while ipv6 is disabled.
ping 10.10.10.2 or 10.10.10.3, whichever is the remote side. |
|
| 2018-05-15 08:37:30 |
Matt Rae |
description |
When booting with ipv6.disable=1, vxlan will fail to initialize with the error "vxlan: Cannot bind port 4789, err=-97" which is EAFNOSUPPORT.
Expected result is that vxlan tunnels work when ipv6 is disabled.
Description: Ubuntu 16.04.4 LTS
Release: 16.04
linux-image-4.4.0-124-generic
bug is fixed in RHEL in https://bugzilla.redhat.com/show_bug.cgi?id=1445054
Steps to reproduce:
Deploy two identical 14.04 nodes with the following configuration:
Add the following to /etc/default/grub then run 'sudo update-grub'
GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1"
Reboot both nodes
sudo reboot
Set up a tunnel using the following commands on each node modifying remote_ip to be the ip of the other node. modify veth0 ip to be subnet using the tunnel 10.10.10.x/24
ovs-vsctl del-port br-int vx1
ovs-vsctl del-port br-int veth1
ip link del veth0
ovs-vsctl add-port br-int vx1 -- set interface vx1 type=vxlan options:remote_ip=192.168.122.161
# remote_ip should be the ip of the other node
ip link add type veth
ip link set veth0 up
ip link set veth1 up
ovs-vsctl add-port br-int veth1
ip addr add 10.10.10.2/24 dev veth0 # on the second node use 10.10.10.3/24
Expected result is once the tunnel is configured on each side, you should be able to ping the ip of veth0 on the remote side while ipv6 is disabled.
ping 10.10.10.2 or 10.10.10.3, whichever is the remote side. |
When booting with ipv6.disable=1, vxlan tunnels will fail to initialize with the error "vxlan: Cannot bind port 4789, err=-97" which is EAFNOSUPPORT.
Expected result is that vxlan tunnels work when ipv6 is disabled.
Description: Ubuntu 16.04.4 LTS
Release: 16.04
linux-image-4.4.0-124-generic
bug is fixed in RHEL in https://bugzilla.redhat.com/show_bug.cgi?id=1445054
Steps to reproduce:
Deploy two identical 14.04 nodes with the following configuration:
Add the following to /etc/default/grub then run 'sudo update-grub'
GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1"
Reboot both nodes
sudo reboot
Set up a tunnel using the following commands on each node modifying remote_ip to be the ip of the other node. modify veth0 ip to be subnet using the tunnel 10.10.10.x/24
ovs-vsctl del-port br-int vx1
ovs-vsctl del-port br-int veth1
ip link del veth0
ovs-vsctl add-port br-int vx1 -- set interface vx1 type=vxlan options:remote_ip=192.168.122.161
# remote_ip should be the ip of the other node
ip link add type veth
ip link set veth0 up
ip link set veth1 up
ovs-vsctl add-port br-int veth1
ip addr add 10.10.10.2/24 dev veth0 # on the second node use 10.10.10.3/24
Expected result is once the tunnel is configured on each side, you should be able to ping the ip of veth0 on the remote side while ipv6 is disabled.
ping 10.10.10.2 or 10.10.10.3, whichever is the remote side. |
|
| 2018-05-15 11:53:37 |
Matt Rae |
attachment added |
|
0001-vxlan-correctly-handle-ipv6.disable-module-parameter.patch https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1771301/+attachment/5139772/+files/0001-vxlan-correctly-handle-ipv6.disable-module-parameter.patch |
|
| 2018-05-15 12:25:13 |
Ubuntu Foundations Team Bug Bot |
tags |
|
patch |
|
| 2018-05-15 12:25:15 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Joseph Salisbury |
| 2018-05-15 14:51:12 |
Ubuntu Kernel Bot |
linux (Ubuntu): status |
New |
Incomplete |
|
| 2018-05-15 14:51:13 |
Ubuntu Kernel Bot |
tags |
patch |
patch xenial |
|
| 2018-05-16 18:34:34 |
Joseph Salisbury |
linux (Ubuntu): status |
Incomplete |
Triaged |
|
| 2018-05-16 18:34:36 |
Joseph Salisbury |
linux (Ubuntu): importance |
Undecided |
Medium |
|
| 2018-05-16 18:34:42 |
Joseph Salisbury |
nominated for series |
|
Ubuntu Xenial |
|
| 2018-05-16 18:34:42 |
Joseph Salisbury |
bug task added |
|
linux (Ubuntu Xenial) |
|
| 2018-05-16 18:34:47 |
Joseph Salisbury |
linux (Ubuntu Xenial): importance |
Undecided |
Medium |
|
| 2018-05-16 18:34:51 |
Joseph Salisbury |
linux (Ubuntu Xenial): status |
New |
Triaged |
|
| 2018-05-16 18:35:01 |
Joseph Salisbury |
tags |
patch xenial |
kernel-da-key patch xenial |
|
| 2018-05-23 12:03:51 |
Eric Desrochers |
linux (Ubuntu): status |
Triaged |
Fix Released |
|
| 2018-05-23 12:03:54 |
Eric Desrochers |
linux (Ubuntu Xenial): status |
Triaged |
In Progress |
|
| 2018-05-23 12:03:56 |
Eric Desrochers |
linux (Ubuntu Xenial): assignee |
|
Eric Desrochers (slashd) |
|
| 2018-05-23 12:51:34 |
Eric Desrochers |
description |
When booting with ipv6.disable=1, vxlan tunnels will fail to initialize with the error "vxlan: Cannot bind port 4789, err=-97" which is EAFNOSUPPORT.
Expected result is that vxlan tunnels work when ipv6 is disabled.
Description: Ubuntu 16.04.4 LTS
Release: 16.04
linux-image-4.4.0-124-generic
bug is fixed in RHEL in https://bugzilla.redhat.com/show_bug.cgi?id=1445054
Steps to reproduce:
Deploy two identical 14.04 nodes with the following configuration:
Add the following to /etc/default/grub then run 'sudo update-grub'
GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1"
Reboot both nodes
sudo reboot
Set up a tunnel using the following commands on each node modifying remote_ip to be the ip of the other node. modify veth0 ip to be subnet using the tunnel 10.10.10.x/24
ovs-vsctl del-port br-int vx1
ovs-vsctl del-port br-int veth1
ip link del veth0
ovs-vsctl add-port br-int vx1 -- set interface vx1 type=vxlan options:remote_ip=192.168.122.161
# remote_ip should be the ip of the other node
ip link add type veth
ip link set veth0 up
ip link set veth1 up
ovs-vsctl add-port br-int veth1
ip addr add 10.10.10.2/24 dev veth0 # on the second node use 10.10.10.3/24
Expected result is once the tunnel is configured on each side, you should be able to ping the ip of veth0 on the remote side while ipv6 is disabled.
ping 10.10.10.2 or 10.10.10.3, whichever is the remote side. |
[Impact]
When booting with ipv6.disable=1, vxlan tunnels will fail to initialize with the error "vxlan: Cannot bind port 4789, err=-97" which is EAFNOSUPPORT.
Expected result is that vxlan tunnels work when ipv6 is disabled.
# Tested on :
Description: Ubuntu 16.04.4 LTS
Release: 16.04
Kernel : linux-image-4.4.0-124-generic
[Test Case]
Deploy two identical 14.04 nodes with the following configuration:
Add the following to /etc/default/grub then run 'sudo update-grub'
GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1"
Reboot both nodes
sudo reboot
Set up a tunnel using the following commands on each node modifying remote_ip to be the ip of the other node. modify veth0 ip to be subnet using the tunnel 10.10.10.x/24
ovs-vsctl del-port br-int vx1
ovs-vsctl del-port br-int veth1
ip link del veth0
ovs-vsctl add-port br-int vx1 -- set interface vx1 type=vxlan options:remote_ip=192.168.122.161
# remote_ip should be the ip of the other node
ip link add type veth
ip link set veth0 up
ip link set veth1 up
ovs-vsctl add-port br-int veth1
ip addr add 10.10.10.2/24 dev veth0 # on the second node use 10.10.10.3/24
Expected result is once the tunnel is configured on each side, you should be able to ping the ip of veth0 on the remote side while ipv6 is disabled.
ping 10.10.10.2 or 10.10.10.3, whichever is the remote side.
[Regression Potential]
Regression Potential = Low.
This has been tested by more than one person (pre-SRU) and the patch provide the expected behaviour for this particular bug.
[Other Info]
* Upstream commit:
https://github.com/torvalds/linux/commit/d074bf9600443403aa24fbc12c1f18eadc90f5aa
* RHEL bug equivalent :
https://bugzilla.redhat.com/show_bug.cgi?id=1445054
[Original Description]
When booting with ipv6.disable=1, vxlan tunnels will fail to initialize with the error "vxlan: Cannot bind port 4789, err=-97" which is EAFNOSUPPORT.
Expected result is that vxlan tunnels work when ipv6 is disabled.
Description: Ubuntu 16.04.4 LTS
Release: 16.04
linux-image-4.4.0-124-generic
bug is fixed in RHEL in https://bugzilla.redhat.com/show_bug.cgi?id=1445054
Steps to reproduce:
Deploy two identical 14.04 nodes with the following configuration:
Add the following to /etc/default/grub then run 'sudo update-grub'
GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1"
Reboot both nodes
sudo reboot
Set up a tunnel using the following commands on each node modifying remote_ip to be the ip of the other node. modify veth0 ip to be subnet using the tunnel 10.10.10.x/24
ovs-vsctl del-port br-int vx1
ovs-vsctl del-port br-int veth1
ip link del veth0
ovs-vsctl add-port br-int vx1 -- set interface vx1 type=vxlan options:remote_ip=192.168.122.161
# remote_ip should be the ip of the other node
ip link add type veth
ip link set veth0 up
ip link set veth1 up
ovs-vsctl add-port br-int veth1
ip addr add 10.10.10.2/24 dev veth0 # on the second node use 10.10.10.3/24
Expected result is once the tunnel is configured on each side, you should be able to ping the ip of veth0 on the remote side while ipv6 is disabled.
ping 10.10.10.2 or 10.10.10.3, whichever is the remote side. |
|
| 2018-06-07 05:12:31 |
Juerg Haefliger |
linux (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2018-06-13 11:03:50 |
Brad Figg |
tags |
kernel-da-key patch xenial |
kernel-da-key patch verification-needed-xenial xenial |
|
| 2018-06-15 12:25:05 |
Eric Desrochers |
tags |
kernel-da-key patch verification-needed-xenial xenial |
kernel-da-key patch verification-done-xenial xenial |
|
| 2018-07-02 08:29:08 |
Launchpad Janitor |
linux (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2018-07-02 08:29:08 |
Launchpad Janitor |
cve linked |
|
2018-3639 |
|
| 2018-07-02 08:29:08 |
Launchpad Janitor |
cve linked |
|
2018-3665 |
|
| 2018-07-02 08:29:08 |
Launchpad Janitor |
cve linked |
|
2018-7755 |
|
