[Touch-packages] [Bug 1006898] Re: [SRU] dnsmasq fails at leasing issues when using vlan mode
Many thanks Chris. I just felt triggered by this closing because I remember how much pain this bug caused me while working in a data center back in the days. :) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1006898 Title: [SRU] dnsmasq fails at leasing issues when using vlan mode Status in dnsmasq package in Ubuntu: Fix Released Status in dnsmasq source package in Precise: Won't Fix Bug description: ** Issue ** There is an issue with the way nova uses dnsmasq in VLAN mode. It starts up a single copy of dnsmasq for each vlan on the network host (or on every host in multi_host mode). The problem is in the way that dnsmasq binds to an ip address and port[2]. Both copies can respond to broadcast packet, but unicast packets can only be answered by one of the copies. In nova this means that guests from only one project will get responses to their unicast dhcp renew requests. Unicast projects from guests in other projects get ignored. What happens next is different depending on the guest os. Linux generally will send a broadcast packet out after the unicast fails, and so the only effect is a small (tens of ms) hiccup while interface is reconfigured. It can be much worse than that, however. I have seen cases where Windows just gives up and ends up with a non-configured interface. This bug was first noticed by some users of openstack who rolled their own fix. Basically, on linux, if you set the SO_BINDTODEVICE socket option, it will allow different daemons to share the port and respond to unicast packets, as long as they listen on different interfaces. I managed to communicate with Simon Kelley, the maintainer of dnsmasq and he has integrated a fix[3] for the issue in the current version[1] of dnsmaq. [3] http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=9380ba70d67db6b69f817d8e318de5ba1e990b12 ** Development Fix ** This has been fixed in quantal with the newer version of dnmasq. ** Stable Fix ** I have backported the patch which fixes this issue, I have attached the debdiff and the buildlog. ** Test Case ** 1. Install openstack with vlan mode. 2. Watch instances loose their IP addresses. ** Regression Potential ** Minimal, most installations dont use this type of networking. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1006898] Re: [SRU] dnsmasq fails at leasing issues when using vlan mode
Hi Christian, I saw both, the close and your question. I'd assume that Steve is updating those in a semi-automated fashion, there is no way he could read all those bugs. Per bug status this one is marked fixed and only had a bug task open to backport to Precise. In fact the upstream commit that fixes this: commit 9380ba70d67db6b69f817d8e318de5ba1e990b12 Author: Simon Kelley Date: Mon Apr 16 14:41:56 2012 +0100 Set SO_BINDTODEVICE on DHCP sockets when doing DHCP on one interface only. Fixes OpenSTack use-case. Has landed in 2.61. And all Ubuntu release are >2.61 nowadays dnsmasq | 2.68-1 | trusty| source dnsmasq | 2.68-1 | trusty/universe | all dnsmasq | 2.68-1ubuntu0.2| trusty-security | source dnsmasq | 2.68-1ubuntu0.2| trusty-security/universe | all dnsmasq | 2.68-1ubuntu0.2| trusty-updates| source dnsmasq | 2.68-1ubuntu0.2| trusty-updates/universe | all dnsmasq | 2.75-1 | xenial| source dnsmasq | 2.75-1 | xenial/universe | all dnsmasq | 2.75-1ubuntu0.16.04.10 | xenial-security | source dnsmasq | 2.75-1ubuntu0.16.04.10 | xenial-security/universe | all dnsmasq | 2.75-1ubuntu0.16.04.10 | xenial-updates| source dnsmasq | 2.75-1ubuntu0.16.04.10 | xenial-updates/universe | all dnsmasq | 2.79-1 | bionic| source dnsmasq | 2.79-1 | bionic/universe | all dnsmasq | 2.79-1ubuntu0.4| bionic-security | source dnsmasq | 2.79-1ubuntu0.4| bionic-security/universe | all dnsmasq | 2.79-1ubuntu0.4| bionic-updates| source dnsmasq | 2.79-1ubuntu0.4| bionic-updates/universe | all dnsmasq | 2.79-1ubuntu0.5| bionic-proposed | source dnsmasq | 2.79-1ubuntu0.5| bionic-proposed/universe | all dnsmasq | 2.80-1.1ubuntu1| focal | source dnsmasq | 2.80-1.1ubuntu1| focal/universe| all dnsmasq | 2.80-1.1ubuntu1.4 | focal-security| source dnsmasq | 2.80-1.1ubuntu1.4 | focal-security/universe | all dnsmasq | 2.80-1.1ubuntu1.4 | focal-updates | source dnsmasq | 2.80-1.1ubuntu1.4 | focal-updates/universe| all dnsmasq | 2.84-1ubuntu2 | hirsute | source dnsmasq | 2.84-1ubuntu2 | hirsute/universe | all dnsmasq | 2.84-1ubuntu2.1| hirsute-security | source dnsmasq | 2.84-1ubuntu2.1| hirsute-security/universe | all dnsmasq | 2.84-1ubuntu2.1| hirsute-updates | source dnsmasq | 2.84-1ubuntu2.1| hirsute-updates/universe | all dnsmasq | 2.85-1ubuntu2 | impish| source dnsmasq | 2.85-1ubuntu2 | impish/universe | all Therefore, yes the assumption would be that it is fixed in all remaining active releases. I've not done a practical check with a full testbed setup, but code-wise it should indeed be good now. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1006898 Title: [SRU] dnsmasq fails at leasing issues when using vlan mode Status in dnsmasq package in Ubuntu: Fix Released Status in dnsmasq source package in Precise: Won't Fix Bug description: ** Issue ** There is an issue with the way nova uses dnsmasq in VLAN mode. It starts up a single copy of dnsmasq for each vlan on the network host (or on every host in multi_host mode). The problem is in the way that dnsmasq binds to an ip address and port[2]. Both copies can respond to broadcast packet, but unicast packets can only be answered by one of the copies. In nova this means that guests from only one project will get responses to their unicast dhcp renew requests. Unicast projects from guests in other projects get ignored. What happens next is different depending on the guest os. Linux generally will send a broadcast packet out after the unicast fails, and so the only effect is a small (tens of ms) hiccup while interface is reconfigured. It can be much worse than that, however. I have seen cases where Windows just gives up and ends up with a non-configured interface. This bug was first noticed by some users of openstack who rolled their own fix. Basically, on linux, if you set the SO_BINDTODEVICE socket option, it will allow different daemons to share the port and respond to unicast packets, as long as they listen on different interfaces. I managed to communicate with Simon Kelley, the maintainer of dnsmasq and he has integrated a fix[3] for the issue in the current version[1] of dnsmaq. [3]
[Touch-packages] [Bug 1006898] Re: [SRU] dnsmasq fails at leasing issues when using vlan mode
Ok that is EOL but did you verify it is not the case in the newer versions? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1006898 Title: [SRU] dnsmasq fails at leasing issues when using vlan mode Status in dnsmasq package in Ubuntu: Fix Released Status in dnsmasq source package in Precise: Won't Fix Bug description: ** Issue ** There is an issue with the way nova uses dnsmasq in VLAN mode. It starts up a single copy of dnsmasq for each vlan on the network host (or on every host in multi_host mode). The problem is in the way that dnsmasq binds to an ip address and port[2]. Both copies can respond to broadcast packet, but unicast packets can only be answered by one of the copies. In nova this means that guests from only one project will get responses to their unicast dhcp renew requests. Unicast projects from guests in other projects get ignored. What happens next is different depending on the guest os. Linux generally will send a broadcast packet out after the unicast fails, and so the only effect is a small (tens of ms) hiccup while interface is reconfigured. It can be much worse than that, however. I have seen cases where Windows just gives up and ends up with a non-configured interface. This bug was first noticed by some users of openstack who rolled their own fix. Basically, on linux, if you set the SO_BINDTODEVICE socket option, it will allow different daemons to share the port and respond to unicast packets, as long as they listen on different interfaces. I managed to communicate with Simon Kelley, the maintainer of dnsmasq and he has integrated a fix[3] for the issue in the current version[1] of dnsmaq. [3] http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=9380ba70d67db6b69f817d8e318de5ba1e990b12 ** Development Fix ** This has been fixed in quantal with the newer version of dnmasq. ** Stable Fix ** I have backported the patch which fixes this issue, I have attached the debdiff and the buildlog. ** Test Case ** 1. Install openstack with vlan mode. 2. Watch instances loose their IP addresses. ** Regression Potential ** Minimal, most installations dont use this type of networking. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1006898] Re: [SRU] dnsmasq fails at leasing issues when using vlan mode
The Precise Pangolin has reached end of life, so this bug will not be fixed for that release ** Changed in: dnsmasq (Ubuntu Precise) Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1006898 Title: [SRU] dnsmasq fails at leasing issues when using vlan mode Status in dnsmasq package in Ubuntu: Fix Released Status in dnsmasq source package in Precise: Won't Fix Bug description: ** Issue ** There is an issue with the way nova uses dnsmasq in VLAN mode. It starts up a single copy of dnsmasq for each vlan on the network host (or on every host in multi_host mode). The problem is in the way that dnsmasq binds to an ip address and port[2]. Both copies can respond to broadcast packet, but unicast packets can only be answered by one of the copies. In nova this means that guests from only one project will get responses to their unicast dhcp renew requests. Unicast projects from guests in other projects get ignored. What happens next is different depending on the guest os. Linux generally will send a broadcast packet out after the unicast fails, and so the only effect is a small (tens of ms) hiccup while interface is reconfigured. It can be much worse than that, however. I have seen cases where Windows just gives up and ends up with a non-configured interface. This bug was first noticed by some users of openstack who rolled their own fix. Basically, on linux, if you set the SO_BINDTODEVICE socket option, it will allow different daemons to share the port and respond to unicast packets, as long as they listen on different interfaces. I managed to communicate with Simon Kelley, the maintainer of dnsmasq and he has integrated a fix[3] for the issue in the current version[1] of dnsmaq. [3] http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=9380ba70d67db6b69f817d8e318de5ba1e990b12 ** Development Fix ** This has been fixed in quantal with the newer version of dnmasq. ** Stable Fix ** I have backported the patch which fixes this issue, I have attached the debdiff and the buildlog. ** Test Case ** 1. Install openstack with vlan mode. 2. Watch instances loose their IP addresses. ** Regression Potential ** Minimal, most installations dont use this type of networking. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1006898] Re: [SRU] dnsmasq fails at leasing issues when using vlan mode
** Changed in: dnsmasq (Ubuntu Precise) Assignee: Jorge Niedbalski (niedbalski) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1006898 Title: [SRU] dnsmasq fails at leasing issues when using vlan mode Status in dnsmasq package in Ubuntu: Fix Released Status in dnsmasq source package in Precise: Incomplete Bug description: ** Issue ** There is an issue with the way nova uses dnsmasq in VLAN mode. It starts up a single copy of dnsmasq for each vlan on the network host (or on every host in multi_host mode). The problem is in the way that dnsmasq binds to an ip address and port[2]. Both copies can respond to broadcast packet, but unicast packets can only be answered by one of the copies. In nova this means that guests from only one project will get responses to their unicast dhcp renew requests. Unicast projects from guests in other projects get ignored. What happens next is different depending on the guest os. Linux generally will send a broadcast packet out after the unicast fails, and so the only effect is a small (tens of ms) hiccup while interface is reconfigured. It can be much worse than that, however. I have seen cases where Windows just gives up and ends up with a non-configured interface. This bug was first noticed by some users of openstack who rolled their own fix. Basically, on linux, if you set the SO_BINDTODEVICE socket option, it will allow different daemons to share the port and respond to unicast packets, as long as they listen on different interfaces. I managed to communicate with Simon Kelley, the maintainer of dnsmasq and he has integrated a fix[3] for the issue in the current version[1] of dnsmaq. [3] http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=9380ba70d67db6b69f817d8e318de5ba1e990b12 ** Development Fix ** This has been fixed in quantal with the newer version of dnmasq. ** Stable Fix ** I have backported the patch which fixes this issue, I have attached the debdiff and the buildlog. ** Test Case ** 1. Install openstack with vlan mode. 2. Watch instances loose their IP addresses. ** Regression Potential ** Minimal, most installations dont use this type of networking. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1006898] Re: [SRU] dnsmasq fails at leasing issues when using vlan mode
Unsubscribing sponsors, please re-subscribe when you attach a working patch. Thanks! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1006898 Title: [SRU] dnsmasq fails at leasing issues when using vlan mode Status in dnsmasq package in Ubuntu: Fix Released Status in dnsmasq source package in Precise: Incomplete Bug description: ** Issue ** There is an issue with the way nova uses dnsmasq in VLAN mode. It starts up a single copy of dnsmasq for each vlan on the network host (or on every host in multi_host mode). The problem is in the way that dnsmasq binds to an ip address and port[2]. Both copies can respond to broadcast packet, but unicast packets can only be answered by one of the copies. In nova this means that guests from only one project will get responses to their unicast dhcp renew requests. Unicast projects from guests in other projects get ignored. What happens next is different depending on the guest os. Linux generally will send a broadcast packet out after the unicast fails, and so the only effect is a small (tens of ms) hiccup while interface is reconfigured. It can be much worse than that, however. I have seen cases where Windows just gives up and ends up with a non-configured interface. This bug was first noticed by some users of openstack who rolled their own fix. Basically, on linux, if you set the SO_BINDTODEVICE socket option, it will allow different daemons to share the port and respond to unicast packets, as long as they listen on different interfaces. I managed to communicate with Simon Kelley, the maintainer of dnsmasq and he has integrated a fix[3] for the issue in the current version[1] of dnsmaq. [3] http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=9380ba70d67db6b69f817d8e318de5ba1e990b12 ** Development Fix ** This has been fixed in quantal with the newer version of dnmasq. ** Stable Fix ** I have backported the patch which fixes this issue, I have attached the debdiff and the buildlog. ** Test Case ** 1. Install openstack with vlan mode. 2. Watch instances loose their IP addresses. ** Regression Potential ** Minimal, most installations dont use this type of networking. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1006898] Re: [SRU] dnsmasq fails at leasing issues when using vlan mode
Note that the patch is a no-op. The source package format is 1.0 and it doesn't call quilt explicitly. The precise package uses inline patches. I tried to apply it manually, but it doesn't fit at all.. Can you please backport the patch to the precise version and change it inline? ** Changed in: dnsmasq (Ubuntu Precise) Status: In Progress = Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1006898 Title: [SRU] dnsmasq fails at leasing issues when using vlan mode Status in dnsmasq package in Ubuntu: Fix Released Status in dnsmasq source package in Precise: Incomplete Bug description: ** Issue ** There is an issue with the way nova uses dnsmasq in VLAN mode. It starts up a single copy of dnsmasq for each vlan on the network host (or on every host in multi_host mode). The problem is in the way that dnsmasq binds to an ip address and port[2]. Both copies can respond to broadcast packet, but unicast packets can only be answered by one of the copies. In nova this means that guests from only one project will get responses to their unicast dhcp renew requests. Unicast projects from guests in other projects get ignored. What happens next is different depending on the guest os. Linux generally will send a broadcast packet out after the unicast fails, and so the only effect is a small (tens of ms) hiccup while interface is reconfigured. It can be much worse than that, however. I have seen cases where Windows just gives up and ends up with a non-configured interface. This bug was first noticed by some users of openstack who rolled their own fix. Basically, on linux, if you set the SO_BINDTODEVICE socket option, it will allow different daemons to share the port and respond to unicast packets, as long as they listen on different interfaces. I managed to communicate with Simon Kelley, the maintainer of dnsmasq and he has integrated a fix[3] for the issue in the current version[1] of dnsmaq. [3] http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=9380ba70d67db6b69f817d8e318de5ba1e990b12 ** Development Fix ** This has been fixed in quantal with the newer version of dnmasq. ** Stable Fix ** I have backported the patch which fixes this issue, I have attached the debdiff and the buildlog. ** Test Case ** 1. Install openstack with vlan mode. 2. Watch instances loose their IP addresses. ** Regression Potential ** Minimal, most installations dont use this type of networking. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1006898] Re: [SRU] dnsmasq fails at leasing issues when using vlan mode
Jorge, Chuck, can you get that update/uploaded? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1006898 Title: [SRU] dnsmasq fails at leasing issues when using vlan mode Status in dnsmasq package in Ubuntu: Fix Released Status in dnsmasq source package in Precise: Triaged Bug description: ** Issue ** There is an issue with the way nova uses dnsmasq in VLAN mode. It starts up a single copy of dnsmasq for each vlan on the network host (or on every host in multi_host mode). The problem is in the way that dnsmasq binds to an ip address and port[2]. Both copies can respond to broadcast packet, but unicast packets can only be answered by one of the copies. In nova this means that guests from only one project will get responses to their unicast dhcp renew requests. Unicast projects from guests in other projects get ignored. What happens next is different depending on the guest os. Linux generally will send a broadcast packet out after the unicast fails, and so the only effect is a small (tens of ms) hiccup while interface is reconfigured. It can be much worse than that, however. I have seen cases where Windows just gives up and ends up with a non-configured interface. This bug was first noticed by some users of openstack who rolled their own fix. Basically, on linux, if you set the SO_BINDTODEVICE socket option, it will allow different daemons to share the port and respond to unicast packets, as long as they listen on different interfaces. I managed to communicate with Simon Kelley, the maintainer of dnsmasq and he has integrated a fix[3] for the issue in the current version[1] of dnsmaq. [3] http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=9380ba70d67db6b69f817d8e318de5ba1e990b12 ** Development Fix ** This has been fixed in quantal with the newer version of dnmasq. ** Stable Fix ** I have backported the patch which fixes this issue, I have attached the debdiff and the buildlog. ** Test Case ** 1. Install openstack with vlan mode. 2. Watch instances loose their IP addresses. ** Regression Potential ** Minimal, most installations dont use this type of networking. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1006898] Re: [SRU] dnsmasq fails at leasing issues when using vlan mode
Attached patch for precise. ** Patch added: patch for precise https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+attachment/4399572/+files/lp1006898-set-so-bindtodevice-on-dhcp.patch ** Patch removed: lp1006898-set-so-bindtodevice-on-dhcp.patch https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+attachment/4363091/+files/lp1006898-set-so-bindtodevice-on-dhcp.patch ** Changed in: dnsmasq (Ubuntu Precise) Assignee: Chuck Short (zulcss) = Jorge Niedbalski (niedbalski) ** Changed in: dnsmasq (Ubuntu Precise) Status: Triaged = In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1006898 Title: [SRU] dnsmasq fails at leasing issues when using vlan mode Status in dnsmasq package in Ubuntu: Fix Released Status in dnsmasq source package in Precise: In Progress Bug description: ** Issue ** There is an issue with the way nova uses dnsmasq in VLAN mode. It starts up a single copy of dnsmasq for each vlan on the network host (or on every host in multi_host mode). The problem is in the way that dnsmasq binds to an ip address and port[2]. Both copies can respond to broadcast packet, but unicast packets can only be answered by one of the copies. In nova this means that guests from only one project will get responses to their unicast dhcp renew requests. Unicast projects from guests in other projects get ignored. What happens next is different depending on the guest os. Linux generally will send a broadcast packet out after the unicast fails, and so the only effect is a small (tens of ms) hiccup while interface is reconfigured. It can be much worse than that, however. I have seen cases where Windows just gives up and ends up with a non-configured interface. This bug was first noticed by some users of openstack who rolled their own fix. Basically, on linux, if you set the SO_BINDTODEVICE socket option, it will allow different daemons to share the port and respond to unicast packets, as long as they listen on different interfaces. I managed to communicate with Simon Kelley, the maintainer of dnsmasq and he has integrated a fix[3] for the issue in the current version[1] of dnsmaq. [3] http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=9380ba70d67db6b69f817d8e318de5ba1e990b12 ** Development Fix ** This has been fixed in quantal with the newer version of dnmasq. ** Stable Fix ** I have backported the patch which fixes this issue, I have attached the debdiff and the buildlog. ** Test Case ** 1. Install openstack with vlan mode. 2. Watch instances loose their IP addresses. ** Regression Potential ** Minimal, most installations dont use this type of networking. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1006898] Re: [SRU] dnsmasq fails at leasing issues when using vlan mode
@arges, I re-uploaded the patch, rebasing with current -updates and fixing the issue you detected. Please sponsor. Thanks. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1006898 Title: [SRU] dnsmasq fails at leasing issues when using vlan mode Status in dnsmasq package in Ubuntu: Fix Released Status in dnsmasq source package in Precise: In Progress Bug description: ** Issue ** There is an issue with the way nova uses dnsmasq in VLAN mode. It starts up a single copy of dnsmasq for each vlan on the network host (or on every host in multi_host mode). The problem is in the way that dnsmasq binds to an ip address and port[2]. Both copies can respond to broadcast packet, but unicast packets can only be answered by one of the copies. In nova this means that guests from only one project will get responses to their unicast dhcp renew requests. Unicast projects from guests in other projects get ignored. What happens next is different depending on the guest os. Linux generally will send a broadcast packet out after the unicast fails, and so the only effect is a small (tens of ms) hiccup while interface is reconfigured. It can be much worse than that, however. I have seen cases where Windows just gives up and ends up with a non-configured interface. This bug was first noticed by some users of openstack who rolled their own fix. Basically, on linux, if you set the SO_BINDTODEVICE socket option, it will allow different daemons to share the port and respond to unicast packets, as long as they listen on different interfaces. I managed to communicate with Simon Kelley, the maintainer of dnsmasq and he has integrated a fix[3] for the issue in the current version[1] of dnsmaq. [3] http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=9380ba70d67db6b69f817d8e318de5ba1e990b12 ** Development Fix ** This has been fixed in quantal with the newer version of dnmasq. ** Stable Fix ** I have backported the patch which fixes this issue, I have attached the debdiff and the buildlog. ** Test Case ** 1. Install openstack with vlan mode. 2. Watch instances loose their IP addresses. ** Regression Potential ** Minimal, most installations dont use this type of networking. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1006898] Re: [SRU] dnsmasq fails at leasing issues when using vlan mode
Jorge, can you reformat the debdiff so it just adds the debian patch and doesn't also modify the original source? Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1006898 Title: [SRU] dnsmasq fails at leasing issues when using vlan mode Status in dnsmasq package in Ubuntu: Fix Released Status in dnsmasq source package in Precise: Triaged Bug description: ** Issue ** There is an issue with the way nova uses dnsmasq in VLAN mode. It starts up a single copy of dnsmasq for each vlan on the network host (or on every host in multi_host mode). The problem is in the way that dnsmasq binds to an ip address and port[2]. Both copies can respond to broadcast packet, but unicast packets can only be answered by one of the copies. In nova this means that guests from only one project will get responses to their unicast dhcp renew requests. Unicast projects from guests in other projects get ignored. What happens next is different depending on the guest os. Linux generally will send a broadcast packet out after the unicast fails, and so the only effect is a small (tens of ms) hiccup while interface is reconfigured. It can be much worse than that, however. I have seen cases where Windows just gives up and ends up with a non-configured interface. This bug was first noticed by some users of openstack who rolled their own fix. Basically, on linux, if you set the SO_BINDTODEVICE socket option, it will allow different daemons to share the port and respond to unicast packets, as long as they listen on different interfaces. I managed to communicate with Simon Kelley, the maintainer of dnsmasq and he has integrated a fix[3] for the issue in the current version[1] of dnsmaq. [3] http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=9380ba70d67db6b69f817d8e318de5ba1e990b12 ** Development Fix ** This has been fixed in quantal with the newer version of dnmasq. ** Stable Fix ** I have backported the patch which fixes this issue, I have attached the debdiff and the buildlog. ** Test Case ** 1. Install openstack with vlan mode. 2. Watch instances loose their IP addresses. ** Regression Potential ** Minimal, most installations dont use this type of networking. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1006898] Re: [SRU] dnsmasq fails at leasing issues when using vlan mode
The attached patch, applies upstream 9380ba70d67db6b69f817d8e318de5ba1e990b12 into precise. ** Patch added: lp1006898-set-so-bindtodevice-on-dhcp.patch https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+attachment/4363091/+files/lp1006898-set-so-bindtodevice-on-dhcp.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1006898 Title: [SRU] dnsmasq fails at leasing issues when using vlan mode Status in dnsmasq package in Ubuntu: Fix Released Status in dnsmasq source package in Precise: Triaged Bug description: ** Issue ** There is an issue with the way nova uses dnsmasq in VLAN mode. It starts up a single copy of dnsmasq for each vlan on the network host (or on every host in multi_host mode). The problem is in the way that dnsmasq binds to an ip address and port[2]. Both copies can respond to broadcast packet, but unicast packets can only be answered by one of the copies. In nova this means that guests from only one project will get responses to their unicast dhcp renew requests. Unicast projects from guests in other projects get ignored. What happens next is different depending on the guest os. Linux generally will send a broadcast packet out after the unicast fails, and so the only effect is a small (tens of ms) hiccup while interface is reconfigured. It can be much worse than that, however. I have seen cases where Windows just gives up and ends up with a non-configured interface. This bug was first noticed by some users of openstack who rolled their own fix. Basically, on linux, if you set the SO_BINDTODEVICE socket option, it will allow different daemons to share the port and respond to unicast packets, as long as they listen on different interfaces. I managed to communicate with Simon Kelley, the maintainer of dnsmasq and he has integrated a fix[3] for the issue in the current version[1] of dnsmaq. [3] http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=9380ba70d67db6b69f817d8e318de5ba1e990b12 ** Development Fix ** This has been fixed in quantal with the newer version of dnmasq. ** Stable Fix ** I have backported the patch which fixes this issue, I have attached the debdiff and the buildlog. ** Test Case ** 1. Install openstack with vlan mode. 2. Watch instances loose their IP addresses. ** Regression Potential ** Minimal, most installations dont use this type of networking. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
