Yes, that make sense. DHCPINFORM wouldn't limited by "static", and seems Windows likes using it.
Would apply the patch. Thanks. --Sheng On Mon, Feb 24, 2014 at 10:53 PM, Joris van Lieshout <jvanliesh...@schubergphilis.com> wrote: > Hi Sheng, > > Based on your feedback I did some testing and it appears that the issue is > not with offering addresses but with dhcp-options. The static option indeed > prevents addresses being leased to unknown macs but it does not prevent other > dhcp-options, like dns servers, to be handed out. So far I have not been able > to find any supporting documentation on this behavior but perhaps this > explanation is sufficient. > > What happens is that dhcp client on the other side of the bridge (physical > Lan) don't get addresses from dnsmasq on the RVM but do get dhcp-option 6 > from the dnsmasq on the RVM. > > This is a bit of (scrutinized) logging where "dhcp-ignore=tag:!known" has > been disabled (so here non ACS hosts are getting dns server settings from the > RVM): > Feb 25 00:00:00 dnsmasq-dhcp[5017]: DHCPINFORM(eth0) 10.xxx.xxx.104 > xx:xx:xx:xx:xx:xx > Feb 25 00:00:00 dnsmasq-dhcp[5017]: DHCPACK(eth0) 10.xxx.xxx.104 > xx:xx:xx:xx:xx:xx LAPTOP001 > > And here with "dhcp-ignore=tag:!known" enabled: > Feb 25 00:00:00 dnsmasq-dhcp[5079]: DHCPINFORM(eth0) 10.xxxx.xxxx.104 > xx:xx:xx:xx:xx:xx ignored > > In both cases the dhcp-range option is set to by ACS: > dhcp-range=10.xxx.xxx.1,static > > Kind regards, > Joris van Lieshout > > -----Original Message----- > From: Sheng Yang [mailto:sh...@yasker.org] > Sent: maandag 24 februari 2014 23:30 > To: Joris van Lieshout > Cc: daan Hoogland; Hugo Trippaers; cloudstack > Subject: Re: Review Request 18310: dnsmasq fix for bridged networks > > Yes, it would provide extra failsafe. > > But the issue is if there is anything wrong, this patch may or may not > prevent it. So I think it's necessary to identify the root cause > first. > > The dhcp-range option already specified as "static" which means: > > <quote> > The optional <mode> keyword may be static which tells dnsmasq to > enable DHCP for the network specified, but not to dynamically allocate > IP addresses: only hosts which have static addresses given via > dhcp-host or from /etc/ethers will be served. A static-only subnet > with address all zeros may be used as a "catch-all" address to enable > replies to all Information-request packets on a subnet which is > provided with stateless DHCPv6, ie --dhcp=range=::,static > </quote> > > So it should already served the purpose. > > --Sheng > > On Sat, Feb 22, 2014 at 9:28 AM, Joris van Lieshout > <jvanliesh...@schubergphilis.com> wrote: >> Hi Sheng, >> >> First of thanks you for reviewing my first attempt to contribute :) and >> sorry for my late response. I want to gadder a bit more info because I've >> seen it hand out adresses. Besides that this setting should at least provide >> an extra failsafe. >> >> Regards, Joris >> >> Sent from my iPhone >> >> On 21 feb. 2014, at 20:00, "Sheng Yang" <sh...@yasker.org> wrote: >> >> Hi Joris, >> >> This patch hasn't been applied yet, sorry for my second thought. >> >> Could you comment on it? >> >> --Sheng >> >> >> On Thu, Feb 20, 2014 at 10:29 AM, Sheng Yang <sh...@yasker.org> wrote: >>> >>> This is an automatically generated e-mail. To reply, visit: >>> https://reviews.apache.org/r/18310/ >>> >>> On February 20th, 2014, 6:17 p.m. UTC, Sheng Yang wrote: >>> >>> Looks good to me. >>> >>> Also I've confirmed that even with this option, the MAC would show in >>> dnsmasq.log, which is necessary for debug. >>> >>> Applied to MASTER. Thanks! >>> >>> On February 20th, 2014, 6:28 p.m. UTC, Sheng Yang wrote: >>> >>> One moment, on a second thought, even with current setup, dnsmasq won't >>> hand out IP to unknown host. So why this option is needed? >>> >>> And the log would show "DHCPDISCOVER(eth0) 02:01:3a:d9:00:02 no address >>> available" instead of "DHCPDISCOVER(eth0) 02:01:3a:d9:00:02 ignored" with >>> the option. >>> >>> Is there anything I missed? >>> >>> And the patch hasn't been applied yet... >>> >>> >>> - Sheng >>> >>> >>> On February 20th, 2014, 2:01 p.m. UTC, Joris van Lieshout wrote: >>> >>> Review request for cloudstack, daan Hoogland, Hugo Trippaers, and Sheng >>> Yang. >>> By Joris van Lieshout. >>> >>> Updated Feb. 20, 2014, 2:01 p.m. >>> >>> Repository: cloudstack-git >>> >>> Description >>> >>> When a ACS network is bridged to another non-ACS network (for instance >>> using a NSX Bridge) this will prevent dnsmasq from responding to requests >>> from the other network that have traversed the bridge. >>> >>> Testing >>> >>> We have been running this fix on our own version of the 4.2 and 3.0 SVM >>> for a couple months with success. >>> >>> Diffs >>> >>> systemvm/patches/debian/config/etc/dnsmasq.conf.tmpl (07c5902) >>> >>> View Diff >> >>
