On Thu, Nov 8, 2012 at 7:08 AM, Gene Czarcinski <gene@xxxxxxxxx> wrote: > On 11/07/2012 04:23 PM, Doug Goldstein wrote: >> >> On Wed, Nov 7, 2012 at 3:05 PM, Gene Czarcinski <gene@xxxxxxxxx> wrote: >>> >>> I have a working patch to have dnsmasq support RA instead of radvd. >>> However, something has come up and it will be a week to ten days before I >>> can get it in shape to submit. >>> >>> The current patch has three variables added to the _virNetworkObj >>> structure: >>> dnsmasqRA flag and both major and minor values for the dnsmasq's version. >>> >>> I use "dnsmasq --version" and then parse out the major/minor version >>> values. >>> If major>2, then dnamsqFA=1. If major=2 and minor>=63, then dnsmasqRA=1. >>> For all other cases, dnsmasqRA=0. >>> >>> Code is added to the radvd functions which checks dnsmasqRA and exits if >>> it >>> is 1. >>> >>> Code is added to the dnsmasq configuration file if dnsmasqRa=1. If >>> dhcp-range or dhcp-hosts is specified for IPv6, then enable-ra is added >>> for >>> stateful (dhcpv6). Otherwise, a special >>> "dhcp-range=<ipv6-subnet-address>,ra-only" so that the ManagedFlag will >>> be >>> off in the RA packets for stateless operation. >>> >>> OK, how does that sound? Everyone comfortable with that? >>> >>> Another thing is that I plan to add a test such that if the radvd >>> executable >>> is not valid, the dnsmasqRA=1. >>> >>> As I was doing this, I also looked through the libvirt.spec file. My, >>> what a >>> wonderful example of wizardly that is. Anyway, I thought some updates >>> may >>> be in ortder: >>> >>> - increase the minimum version for dnsmasq from 2.41 to 2.48. >>> >>> - why is radvd required for rpmbuild? >>> >>> - in light of my patch, make radvd an optional runtime requirement. I am >>> not >>> a spec file expert by any means but there must be a way to not require >>> radvd >>> if dnsmasq >- 2.63. >>> >>> Comments? >>> >>> Gene >> >> >> I'm still not thrilled that you're pushing forward with requiring 2.63 >> + a few patches backported from 2.64 into 2.63 and only checking >> against 2.63. > > I assume you are talking about dhcpv6 and not radvd. Thus, your concerns > are related to, if dnsmasq's version => 2.63, then use dnsmasq to support > both statefull (ManagedFlag on) and stateless (ManagedFlag off) IPv6. > > DHCPv6 does work in dnsmasq-2.63 but not very well with respect to libvirt. > Libvirt plus my patch to add interface= will allow one DHCPv6 dnsmasq. With > the two patches, everything works as it should. > > If you do not specify any dhcp-range= or dhcp-host= parameters, then it does > not matter and everything works as it should. If you do specify them, then > you will (at best) get some indication with a message to syslog and, at > worst, nothing happens and DHCPv6 requests are ignored. > > The good news is that I have gotten the attention of dnsmasq's Fedora > maintainer and he is looking into it. I expect an update for Fedora "real > soon now" and, since Simon said that dnsmasq-2.64 should be available "real > soon now," that 2.64 be added to F18 updates sooner rather than later. > > There are currently NO checks as far as the DHCPv6 implementing code. If > you specify dhcp-range or dhcp-host, the parameters will be passed to > dnsmasq. I could add a check, and if the dnsmasq is earlier than 2.63, to > fail dnsmasq startup. I could also issue a warning message is dnsmasq is > 2.63. I have not done that because, if you do NOT specify dhcp-range and/or > dhcp-host, nothing will happen and things work as they do now. > > I noticed that your email has @gentoo,org. I had a fleeting look at gentoo > a bunch of years ago. I do not know what problems result in your concern. > > Gene > I hardly see what me having any involvement in Gentoo has anything to do with this short of saying Gentoo isn't for everyone, just as Debian, Ubuntu, Fedora, or SuSE aren't for everyone and Gentoo wasn't your cup of tea. My point is if you're going to add a check for 2.63 but really require 2.63 + 3 patches that Fedora has backported into their 2.63 version which was your original proposal, this would cause lots of headaches for every other distro out there unless they backported those very same patches into 2.63. So better to wait for 2.64 and go forward from there. libvirt works on and targets many more systems than Fedora. -- Doug Goldstein -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list