Activity log for bug #1689854

Date Who What changed Old value New value Message
2017-05-10 16:33:11 Dan Streetman bug added bug
2017-05-10 16:33:27 Dan Streetman isc-dhcp (Ubuntu): importance Undecided Medium
2017-05-10 16:33:31 Dan Streetman isc-dhcp (Ubuntu): status New In Progress
2017-05-10 16:33:33 Dan Streetman isc-dhcp (Ubuntu): assignee Dan Streetman (ddstreet)
2017-05-10 16:33:40 Dan Streetman nominated for series Ubuntu Trusty
2017-05-10 17:04:59 Dan Streetman attachment added lp1689854-trusty.debdiff https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1689854/+attachment/4874777/+files/lp1689854-trusty.debdiff
2017-05-10 18:08:38 Dan Streetman tags sts-sru-needed
2017-05-10 18:12:59 Eric Desrochers bug task added isc-dhcp (Ubuntu Trusty)
2017-05-10 18:18:58 Eric Desrochers bug added subscriber Eric Desrochers
2017-05-10 19:24:35 Eric Desrochers isc-dhcp (Ubuntu Trusty): status New In Progress
2017-05-10 19:24:38 Eric Desrochers isc-dhcp (Ubuntu Trusty): importance Undecided Medium
2017-05-10 19:24:54 Eric Desrochers isc-dhcp (Ubuntu Trusty): assignee Dan Streetman (ddstreet)
2017-05-10 19:54:46 Eric Desrochers description [Impact] When using isc-dhcp-client on a Trusty system, with multiple interfaces configured to use DHCPv6, not all the DHCPv6 clients will receive the server responses on some of the interfaces. This results in not all DHCPv6 interfaces being configured. [Test Case] Set up a DHCPv6 server with multiple interfaces (3-4 is enough) and configure it to serve DHCPv6 on all the interfaces (as separate subnets). The server release does not matter. Set up a client system with the same number of interfaces, connected/bridged to the server interfaces. The client must be a Trusty system. Configure (with ifupdown via /etc/network/interfaces) all the interfaces to use DHCPv6, and reboot. Keep rebooting until one or more of the DHCPv6 interfaces fails to get an address; it should not take more than a few reboots. After a failure, even manual ifdown/ifup on the failed interface will not get a DHCPv6 address. [Regression Potential] As this changes how the isc-dhcp-client binds to IPv6 sockets, this could cause problems when the client tries to bind, send, or receive, with this or other operations. [Other Info] This is fixed upstream already, and the patch is included in Xenial and later releases. This patch is needed only in the Trusty release. [Impact] When using isc-dhcp-client on a Trusty system, with multiple interfaces configured to use DHCPv6, not all the DHCPv6 clients will receive the server responses on some of the interfaces. This results in not all DHCPv6 interfaces being configured. [Test Case] Set up a DHCPv6 server with multiple interfaces (3-4 is enough) and configure it to serve DHCPv6 on all the interfaces (as separate subnets). The server release does not matter. Set up a client system with the same number of interfaces, connected/bridged to the server interfaces. The client must be a Trusty system. Configure (with ifupdown via /etc/network/interfaces) all the interfaces to use DHCPv6, and reboot. Keep rebooting until one or more of the DHCPv6 interfaces fails to get an address; it should not take more than a few reboots. After a failure, even manual ifdown/ifup on the failed interface will not get a DHCPv6 address. [Regression Potential] As this changes how the isc-dhcp-client binds to IPv6 sockets, this could cause problems when the client tries to bind, send, or receive, with this or other operations. Patch is already in most recent Ubuntu version : artful --> isc-dhcp-4.3.5/RELNOTES: [ISC-Bugs #34784] zesty --> isc-dhcp-4.3.5/RELNOTES: [ISC-Bugs #34784] yakkety --> isc-dhcp-4.3.3/RELNOTES: [ISC-Bugs #34784] xenial --> isc-dhcp-4.3.3/RELNOTES: [ISC-Bugs #34784] [Other Info] This is fixed upstream already, and the patch is included in Xenial and later releases. This patch is needed only in the Trusty release.
2017-05-10 19:54:51 Eric Desrochers isc-dhcp (Ubuntu): assignee Dan Streetman (ddstreet)
2017-05-10 19:54:54 Eric Desrochers isc-dhcp (Ubuntu): status In Progress Fix Released
2017-05-10 19:55:28 Eric Desrochers description [Impact] When using isc-dhcp-client on a Trusty system, with multiple interfaces configured to use DHCPv6, not all the DHCPv6 clients will receive the server responses on some of the interfaces. This results in not all DHCPv6 interfaces being configured. [Test Case] Set up a DHCPv6 server with multiple interfaces (3-4 is enough) and configure it to serve DHCPv6 on all the interfaces (as separate subnets). The server release does not matter. Set up a client system with the same number of interfaces, connected/bridged to the server interfaces. The client must be a Trusty system. Configure (with ifupdown via /etc/network/interfaces) all the interfaces to use DHCPv6, and reboot. Keep rebooting until one or more of the DHCPv6 interfaces fails to get an address; it should not take more than a few reboots. After a failure, even manual ifdown/ifup on the failed interface will not get a DHCPv6 address. [Regression Potential] As this changes how the isc-dhcp-client binds to IPv6 sockets, this could cause problems when the client tries to bind, send, or receive, with this or other operations. Patch is already in most recent Ubuntu version : artful --> isc-dhcp-4.3.5/RELNOTES: [ISC-Bugs #34784] zesty --> isc-dhcp-4.3.5/RELNOTES: [ISC-Bugs #34784] yakkety --> isc-dhcp-4.3.3/RELNOTES: [ISC-Bugs #34784] xenial --> isc-dhcp-4.3.3/RELNOTES: [ISC-Bugs #34784] [Other Info] This is fixed upstream already, and the patch is included in Xenial and later releases. This patch is needed only in the Trusty release. [Impact] When using isc-dhcp-client on a Trusty system, with multiple interfaces configured to use DHCPv6, not all the DHCPv6 clients will receive the server responses on some of the interfaces. This results in not all DHCPv6 interfaces being configured. [Test Case] Set up a DHCPv6 server with multiple interfaces (3-4 is enough) and configure it to serve DHCPv6 on all the interfaces (as separate subnets). The server release does not matter. Set up a client system with the same number of interfaces, connected/bridged to the server interfaces. The client must be a Trusty system. Configure (with ifupdown via /etc/network/interfaces) all the interfaces to use DHCPv6, and reboot. Keep rebooting until one or more of the DHCPv6 interfaces fails to get an address; it should not take more than a few reboots. After a failure, even manual ifdown/ifup on the failed interface will not get a DHCPv6 address. [Regression Potential] As this changes how the isc-dhcp-client binds to IPv6 sockets, this could cause problems when the client tries to bind, send, or receive, with this or other operations. Patch is already in most recent Ubuntu releases : artful --> isc-dhcp-4.3.5/RELNOTES: [ISC-Bugs #34784] zesty --> isc-dhcp-4.3.5/RELNOTES: [ISC-Bugs #34784] yakkety --> isc-dhcp-4.3.3/RELNOTES: [ISC-Bugs #34784] xenial --> isc-dhcp-4.3.3/RELNOTES: [ISC-Bugs #34784] [Other Info] This is fixed upstream already, and the patch is included in Xenial and later releases. This patch is needed only in the Trusty release.
2017-05-10 20:46:03 Eric Desrochers description [Impact] When using isc-dhcp-client on a Trusty system, with multiple interfaces configured to use DHCPv6, not all the DHCPv6 clients will receive the server responses on some of the interfaces. This results in not all DHCPv6 interfaces being configured. [Test Case] Set up a DHCPv6 server with multiple interfaces (3-4 is enough) and configure it to serve DHCPv6 on all the interfaces (as separate subnets). The server release does not matter. Set up a client system with the same number of interfaces, connected/bridged to the server interfaces. The client must be a Trusty system. Configure (with ifupdown via /etc/network/interfaces) all the interfaces to use DHCPv6, and reboot. Keep rebooting until one or more of the DHCPv6 interfaces fails to get an address; it should not take more than a few reboots. After a failure, even manual ifdown/ifup on the failed interface will not get a DHCPv6 address. [Regression Potential] As this changes how the isc-dhcp-client binds to IPv6 sockets, this could cause problems when the client tries to bind, send, or receive, with this or other operations. Patch is already in most recent Ubuntu releases : artful --> isc-dhcp-4.3.5/RELNOTES: [ISC-Bugs #34784] zesty --> isc-dhcp-4.3.5/RELNOTES: [ISC-Bugs #34784] yakkety --> isc-dhcp-4.3.3/RELNOTES: [ISC-Bugs #34784] xenial --> isc-dhcp-4.3.3/RELNOTES: [ISC-Bugs #34784] [Other Info] This is fixed upstream already, and the patch is included in Xenial and later releases. This patch is needed only in the Trusty release. [Impact] When using isc-dhcp-client on a Trusty system, with multiple interfaces configured to use DHCPv6, not all the DHCPv6 clients will receive the server responses on some of the interfaces. This results in not all DHCPv6 interfaces being configured. [Test Case] Set up a DHCPv6 server with multiple interfaces (3-4 is enough) and configure it to serve DHCPv6 on all the interfaces (as separate subnets). The server release does not matter. Set up a client system with the same number of interfaces, connected/bridged to the server interfaces. The client must be a Trusty system. Configure (with ifupdown via /etc/network/interfaces) all the interfaces to use DHCPv6, and reboot. Keep rebooting until one or more of the DHCPv6 interfaces fails to get an address; it should not take more than a few reboots. After a failure, even manual ifdown/ifup on the failed interface will not get a DHCPv6 address. [Regression Potential] As this changes how the isc-dhcp-client binds to IPv6 sockets, this could cause problems when the client tries to bind, send, or receive, with this or other operations. [Other Info] This is fixed upstream already, and the patch is included in Xenial and later releases. This patch is needed only in the Trusty release. Upstream patch : https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=commit;h=4b8251a0c06b7d8706a28904fdef2414f045cc2c
2017-05-10 21:03:07 Dan Streetman attachment removed lp1689854-trusty.debdiff https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1689854/+attachment/4874777/+files/lp1689854-trusty.debdiff
2017-05-10 21:04:18 Dan Streetman attachment added lp1689854-trusty.debdiff https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1689854/+attachment/4874866/+files/lp1689854-trusty.debdiff
2017-05-11 14:37:31 Eric Desrochers description [Impact] When using isc-dhcp-client on a Trusty system, with multiple interfaces configured to use DHCPv6, not all the DHCPv6 clients will receive the server responses on some of the interfaces. This results in not all DHCPv6 interfaces being configured. [Test Case] Set up a DHCPv6 server with multiple interfaces (3-4 is enough) and configure it to serve DHCPv6 on all the interfaces (as separate subnets). The server release does not matter. Set up a client system with the same number of interfaces, connected/bridged to the server interfaces. The client must be a Trusty system. Configure (with ifupdown via /etc/network/interfaces) all the interfaces to use DHCPv6, and reboot. Keep rebooting until one or more of the DHCPv6 interfaces fails to get an address; it should not take more than a few reboots. After a failure, even manual ifdown/ifup on the failed interface will not get a DHCPv6 address. [Regression Potential] As this changes how the isc-dhcp-client binds to IPv6 sockets, this could cause problems when the client tries to bind, send, or receive, with this or other operations. [Other Info] This is fixed upstream already, and the patch is included in Xenial and later releases. This patch is needed only in the Trusty release. Upstream patch : https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=commit;h=4b8251a0c06b7d8706a28904fdef2414f045cc2c [Impact] When using isc-dhcp-client on a Trusty system, with multiple interfaces configured to use DHCPv6, not all the DHCPv6 clients will receive the server responses on some of the interfaces. This results in not all DHCPv6 interfaces being configured. [Test Case] Set up a DHCPv6 server with multiple interfaces (3-4 is enough) and configure it to serve DHCPv6 on all the interfaces (as separate subnets). The server release does not matter. Set up a client system with the same number of interfaces, connected/bridged to the server interfaces. The client must be a Trusty system. Configure (with ifupdown via /etc/network/interfaces) all the interfaces to use DHCPv6, and reboot. Keep rebooting until one or more of the DHCPv6 interfaces fails to get an address; it should not take more than a few reboots. After a failure, even manual ifdown/ifup on the failed interface will not get a DHCPv6 address. [Regression Potential] * As this changes how the isc-dhcp-client binds to IPv6 sockets, this could cause problems when the client tries to bind, send, or receive, with this or other operations. * This is fixed upstream already, and the patch is included in Xenial and later releases. This patch is needed only in the Trusty release. * Upstream patch : https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=commit;h=4b8251a0c06b7d8706a28904fdef2414f045cc2c [Other Info] * Reference: https://www.isc.org/community/report-bug/ ... Confidentiality It is typical for open-source projects to have an open bug database. At the moment, the ISC bug database is closed. However, we reserve the right to publish your bug report at some point in the future. Please do not include information you consider to be confidential. ...
2017-05-11 14:38:38 Eric Desrochers description [Impact] When using isc-dhcp-client on a Trusty system, with multiple interfaces configured to use DHCPv6, not all the DHCPv6 clients will receive the server responses on some of the interfaces. This results in not all DHCPv6 interfaces being configured. [Test Case] Set up a DHCPv6 server with multiple interfaces (3-4 is enough) and configure it to serve DHCPv6 on all the interfaces (as separate subnets). The server release does not matter. Set up a client system with the same number of interfaces, connected/bridged to the server interfaces. The client must be a Trusty system. Configure (with ifupdown via /etc/network/interfaces) all the interfaces to use DHCPv6, and reboot. Keep rebooting until one or more of the DHCPv6 interfaces fails to get an address; it should not take more than a few reboots. After a failure, even manual ifdown/ifup on the failed interface will not get a DHCPv6 address. [Regression Potential] * As this changes how the isc-dhcp-client binds to IPv6 sockets, this could cause problems when the client tries to bind, send, or receive, with this or other operations. * This is fixed upstream already, and the patch is included in Xenial and later releases. This patch is needed only in the Trusty release. * Upstream patch : https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=commit;h=4b8251a0c06b7d8706a28904fdef2414f045cc2c [Other Info] * Reference: https://www.isc.org/community/report-bug/ ... Confidentiality It is typical for open-source projects to have an open bug database. At the moment, the ISC bug database is closed. However, we reserve the right to publish your bug report at some point in the future. Please do not include information you consider to be confidential. ... [Impact] When using isc-dhcp-client on a Trusty system, with multiple interfaces configured to use DHCPv6, not all the DHCPv6 clients will receive the server responses on some of the interfaces. This results in not all DHCPv6 interfaces being configured. [Test Case] Set up a DHCPv6 server with multiple interfaces (3-4 is enough) and configure it to serve DHCPv6 on all the interfaces (as separate subnets). The server release does not matter. Set up a client system with the same number of interfaces, connected/bridged to the server interfaces. The client must be a Trusty system. Configure (with ifupdown via /etc/network/interfaces) all the interfaces to use DHCPv6, and reboot. Keep rebooting until one or more of the DHCPv6 interfaces fails to get an address; it should not take more than a few reboots. After a failure, even manual ifdown/ifup on the failed interface will not get a DHCPv6 address. [Regression Potential] * As this changes how the isc-dhcp-client binds to IPv6 sockets, this could cause problems when the client tries to bind, send, or receive, with this or other operations. * This is fixed upstream already, and the patch is included in Xenial and later releases. This patch is needed only in the Trusty release. * Upstream patch : https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=commit;h=4b8251a0c06b7d8706a28904fdef2414f045cc2c [Other Info] * No ISC bug URL can be provided since the ISC bug database is closed : Reference: https://www.isc.org/community/report-bug/ ... Confidentiality It is typical for open-source projects to have an open bug database. At the moment, the ISC bug database is closed. However, we reserve the right to publish your bug report at some point in the future. Please do not include information you consider to be confidential. ...
2017-05-11 14:40:49 Eric Desrochers bug added subscriber SRU Verification
2017-05-11 14:49:46 Dan Streetman attachment removed lp1689854-trusty.debdiff https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1689854/+attachment/4874866/+files/lp1689854-trusty.debdiff
2017-05-11 14:50:24 Dan Streetman attachment added lp1689854-trusty.debdiff https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1689854/+attachment/4875192/+files/lp1689854-trusty.debdiff
2017-05-11 15:25:56 Eric Desrochers description [Impact] When using isc-dhcp-client on a Trusty system, with multiple interfaces configured to use DHCPv6, not all the DHCPv6 clients will receive the server responses on some of the interfaces. This results in not all DHCPv6 interfaces being configured. [Test Case] Set up a DHCPv6 server with multiple interfaces (3-4 is enough) and configure it to serve DHCPv6 on all the interfaces (as separate subnets). The server release does not matter. Set up a client system with the same number of interfaces, connected/bridged to the server interfaces. The client must be a Trusty system. Configure (with ifupdown via /etc/network/interfaces) all the interfaces to use DHCPv6, and reboot. Keep rebooting until one or more of the DHCPv6 interfaces fails to get an address; it should not take more than a few reboots. After a failure, even manual ifdown/ifup on the failed interface will not get a DHCPv6 address. [Regression Potential] * As this changes how the isc-dhcp-client binds to IPv6 sockets, this could cause problems when the client tries to bind, send, or receive, with this or other operations. * This is fixed upstream already, and the patch is included in Xenial and later releases. This patch is needed only in the Trusty release. * Upstream patch : https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=commit;h=4b8251a0c06b7d8706a28904fdef2414f045cc2c [Other Info] * No ISC bug URL can be provided since the ISC bug database is closed : Reference: https://www.isc.org/community/report-bug/ ... Confidentiality It is typical for open-source projects to have an open bug database. At the moment, the ISC bug database is closed. However, we reserve the right to publish your bug report at some point in the future. Please do not include information you consider to be confidential. ... [Impact] When using isc-dhcp-client on a Trusty system, with multiple interfaces configured to use DHCPv6, not all the DHCPv6 clients will receive the server responses on some of the interfaces. This results in not all DHCPv6 interfaces being configured. [Test Case] Set up a DHCPv6 server with multiple interfaces (3-4 is enough) and configure it to serve DHCPv6 on all the interfaces (as separate subnets). The server release does not matter. Set up a client system with the same number of interfaces, connected/bridged to the server interfaces. The client must be a Trusty system. Configure (with ifupdown via /etc/network/interfaces) all the interfaces to use DHCPv6, and reboot. Keep rebooting until one or more of the DHCPv6 interfaces fails to get an address; it should not take more than a few reboots. After a failure, even manual ifdown/ifup on the failed interface will not get a DHCPv6 address. [Regression Potential] * As this changes how the isc-dhcp-client binds to IPv6 sockets, this could cause problems when the client tries to bind, send, or receive, with this or other operations. * This is fixed upstream already, and the patch is included in Xenial and later releases. This patch is needed only in the Trusty release. * Upstream patch : https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=commit;h=4b8251a0c06b7d8706a28904fdef2414f045cc2c [Other Info] * [ISC-Bugs #34784] Please note that no ISC bug URL can be provided since the ISC bug database is closed : Reference: https://www.isc.org/community/report-bug/ ... Confidentiality It is typical for open-source projects to have an open bug database. At the moment, the ISC bug database is closed. However, we reserve the right to publish your bug report at some point in the future. Please do not include information you consider to be confidential. ...
2017-05-11 15:26:02 Eric Desrochers tags sts-sru-needed sts-sru-done
2017-05-15 18:15:17 Łukasz Zemczak isc-dhcp (Ubuntu Trusty): status In Progress Fix Committed
2017-05-15 18:15:19 Łukasz Zemczak bug added subscriber Ubuntu Stable Release Updates Team
2017-05-15 18:15:25 Łukasz Zemczak tags sts-sru-done sts-sru-done verification-needed
2017-05-15 19:20:01 Dan Streetman tags sts-sru-done verification-needed sts-sru-done verification-done
2017-05-23 15:56:22 Launchpad Janitor isc-dhcp (Ubuntu Trusty): status Fix Committed Fix Released
2017-05-23 15:56:28 Brian Murray removed subscriber Ubuntu Stable Release Updates Team
2017-06-02 18:24:13 Eric Desrochers removed subscriber SRU Verification