Re: [Dnsmasq-discuss] Announce: release candidate dnsmasq-2.60rc1
On 29/02/12 03:18, Preston Crow wrote: I hit a Makefile issue (that wasn't there in dnsmasq-2.60test10): # pmake way to learn path of Makefile TOP != echo `pwd`/ # GNU make way to learn path of Makefile TOP ?= $(shell pwd) This leads to: Makefile:38: *** missing separator. Stop. Apparently it doesn't like the first TOP line. I might be building it wrong. I'm using Gentoo Linux, and I copied and tweaked the ebuild that I used for test10, which was copied and tweaked from the ebuild for the previous release. Sigh. Writing portable makefiles is a thankless task. I tested this on Gnu-make and BSD make. What flavour/version on make are you using. Related question: BSD people. Would you care if I gave up the fight and required GNU-make to build dnsmasq? Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] dhcpv6 @ rc1
Hi, Simon In latest 60rc1, it seems need to use enable-ra along with dhcp-range=ipv6,ipv6,. Without it default link local gateway can't be assigned to clients, because it's always done via RA. About dhcp-range, prefix6::, ra-only syntax, According sources, preffered and valid lifetime can be set with ra-only token, but not mentioned in sample conf, a bit confusing Next thing is dnsv6 option, it works a bit abnormally (comparing with v4) Suppose we need to assign several dns servers, where one is dnsmasq itself. With dhcpv4 it could be done with dhcp-option=44,dns1,0.0.0.0 But following for dhcpv6 passes [::] in reply message, instead of interface global/link local address dhcp-option=option6,dns-server,[dns1],[dns2],[::] As for dnsv6 without dhcpv6, list can be passed via RA RDNSS option, see RFC 6106. Windows clients don't support it, and, according technet, will never do. However, there's 3rd party win32 daemons, which can be used, like rdnssd-win32 *nix also has support in 3rd party standalone daemons. Best Regards, Vladislav Grishenko ICQ: 303357 MSN: themi...@mail.ru Skype: the.miron ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Re : Announce: release candidate dnsmasq-2.60rc1
Hi Simon. [...] # pmake way to learn path of Makefile TOP != echo `pwd`/ # GNU make way to learn path of Makefile TOP ?= $(shell pwd) This leads to: Makefile:38: *** missing separator. Stop. Apparently it doesn't like the first TOP line. [...] I'm using Gentoo Linux [...] Sigh. Writing portable makefiles is a thankless task. I tested this on Gnu-make and BSD make. What flavour/version on make are you using. Related question: BSD people. Would you care if I gave up the fight and required GNU-make to build dnsmasq? :D Being a Gentoo user as well, I know ebuilds can tweak the makefile before running it. It just needs a permanent convention with the ebuild maintainer. I hence think it's not necessary to give up the makefile syntax for GNU on BSD. Anyway thank you very much for your job, Simon. I've been using dnsmasq for years now and still will for a long time to come. Vincent ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCP over 2 NICs
Hallo, Oliver, Du meintest am 28.02.12: dnsmasq finds the right interface with the static address automaticly. If you write interface=.. you discard the use of the others. Simply delete the interface=.. line and your dnsmasq should run fine. Doesn't help - sorry. One detail: with the interface=lo lines mailing with Thunderbird (from the clients) works. Without it: no mailing. Viele Gruesse! Helmut ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] localise-queries not working correctly
Just to be sure, check that the netmasks are right on the two interfaces on networks 172.16.0.0/16 and 10.0.0.0/8 Ok I've made a test right now and even querying TO 172.16.12.1 dnsmasq replies with both ip addresses # host hotspot 172.16.12.1 Using domain server: Name: 172.16.12.1 Address: 172.16.12.1#53 Aliases: hotspot has address 10.11.11.99 hotspot has address 172.16.12.1 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCP over 2 NICs
Hallo Helmut! On 29 Feb 2012 11:14:00 +0100, Helmut Hullen wrote: [..] Additional experiments: the system needs interface=lo interface=eth0 interface=eth1 Otherwise mailing with Thunderbird (over eth0) doesn't work, getting a DHCP IP address (for the eth0 net) doesn't work. Im not sure, what your intention is for the use of dnsmasq. What do you want to acchieve? How many computers are in your network? What is the error from thunderbird? Is it an IP-error or an DNS-error? How is your routing table? What stands in /etc/resolv.conf? Regards, Oliver ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCP over 2 NICs
Hi Helmut, It looks like you dont need the dns-functionality of dnsmasq. So maybe you would feel more comfortable with the original dhcp-server (version 3), where the configuration language is more explizit as in dnsmasq (@dnsmasq-develoopers: your program is great, Im using it excessivly, especially the script triggering, but in this special case the alternative dhcpd could be the better decision). Especially you can determine the interface explicitly in conjunction with the range. Hth Oliver ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Announce: release candidate dnsmasq-2.60rc1
On 29/02/12 08:05, Vladislav Grishenko wrote: Same hit here, but due TOP variable is already exported from up-level Makefile I have source tree with packages and one general Makefile: src/dnsmasq/... src/Makefile export TOP := $(shell pwd) dnsmasq: $(MAKE) -C $@ So, had to change it to $(MAKE) -C $@ TOP=$(TOP)/$@. p.s Debian, GNU Make 3.81 Best Regards, Vladislav Grishenko Ah thanks for that clue. You've prompted me to tidy up the makefile and put all the internal variables in lower-case, as they should be. I hope that will solve the problems. Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] setting pxe-bootoption via script?
Hi list, Im using dnsmasq for a long time, esp. for networkbooting of thin clients. So i sent the gpxelinux.0 binary which chainloaded the menu-options for booting, i.e. sanboot via iscsi-target. Is it possible setting the iscsi-target-option via (lua-,bash-)script dynamicly, i.e. depending on the mac-address? Tfh! Oliver ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] localise-queries not working correctly
On 29/02/12 09:01, Lorenzo Milesi wrote: Just to be sure, check that the netmasks are right on the two interfaces on networks 172.16.0.0/16 and 10.0.0.0/8 Ok I've made a test right now and even querying TO 172.16.12.1 dnsmasq replies with both ip addresses # host hotspot 172.16.12.1 Using domain server: Name: 172.16.12.1 Address: 172.16.12.1#53 Aliases: hotspot has address 10.11.11.99 hotspot has address 172.16.12.1 Strange. I just checked, and it's working here. What dnsmasq version are you using? Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] setting pxe-bootoption via script?
On 29/02/12 13:00, r...@mglug.de wrote: Hi list, Im using dnsmasq for a long time, esp. for networkbooting of thin clients. So i sent the gpxelinux.0 binary which chainloaded the menu-options for booting, i.e. sanboot via iscsi-target. Is it possible setting the iscsi-target-option via (lua-,bash-)script dynamicly, i.e. depending on the mac-address? No, no information is passed back from the script to the main dnsmasq process, so it can't affect what is send to the client. If you want to select which options to use based on matching the MAC address, that's possible using --dhcp-mac to match (with wildcards) and set a tag. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] localise-queries not working correctly
I just checked, and it's working here. What dnsmasq version are you using? Dnsmasq version 2.35 I'm still on debian 4 on this host. thanks! ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] localise-queries not working correctly
I posted about similar behavior with subnets carved from the class A 10.*.*.* several days ago: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2012q1/005525.html In my case I am using 2.59 and dnsmasq returns all addresses in 10.0.0.0/8 when queried from itself to any of its interfaces in 10.*.*.* even though the interfaces themselves are all /16. Queries from hosts other than the dnsmasq host to any of these /16 interfaces return the correct results. jbh On Wed, Feb 29, 2012 at 6:47 AM, Lorenzo Milesi max...@ufficyo.com wrote: I just checked, and it's working here. What dnsmasq version are you using? Dnsmasq version 2.35 I'm still on debian 4 on this host. thanks! ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] localise-queries not working correctly
On 29/02/12 13:57, John Hanks wrote: I posted about similar behavior with subnets carved from the class A 10.*.*.* several days ago: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2012q1/005525.html In my case I am using 2.59 and dnsmasq returns all addresses in 10.0.0.0/8 when queried from itself to any of its interfaces in 10.*.*.* even though the interfaces themselves are all /16. Queries from hosts other than the dnsmasq host to any of these /16 interfaces return the correct results. jbh On Wed, Feb 29, 2012 at 6:47 AM, Lorenzo Milesimax...@ufficyo.com wrote: I just checked, and it's working here. What dnsmasq version are you using? Dnsmasq version 2.35 I'm still on debian 4 on this host. thanks! ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss OK, I think I just found an interesting problem that could be affecting this. I don't have the time to wade through the descriptions you've both posted of your systems, and there may not be enough information anyway, so I'll try and explain what's going on and you can judge if it's applicable. the algorithm for localisation is get set of answers S if (any member if S is in the subnet of the interface the query was sent to) then return (only members of S which are in the subnet) The wrinkle is that to determine the subnet, you need a netmask, and the netmask dnsmasq is using is the netmask of the interface the query was received on, not the one it was send to. So, for instance I have a set of /24s 192.168.x.y on my central server, and the central server's name has an address 192.168.x.1 on each subnet. Sending queries to the central server at 192.168.1.1 returns the single address for the server - OK. But running the same query to the same address on the server gets all the addreses. That's because the query is routed over the lo interface which has netmask 255.0.0.0. Doing the subnet tests above with netmask 255.0.0.0 yields all the addresses, since they are all in 192.x.y.z (Actually, reading Lorenzo's description, I think this exactly what he's seeing, I;'m not sure about John.) Fixing this problem will be, erm, interesting. Am I on the right lines here? Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] 2.60rc2
Doesn't build with HAVE_BROKEN_RTC Trivial fix attached Best Regards, Vladislav Grishenko -Original Message- From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Simon Kelley Sent: Thursday, March 01, 2012 2:30 AM To: dnsmasq discussion list Subject: [Dnsmasq-discuss] 2.60rc2 A fruitful day moving towards a release. This addresses: * Makefile problems on Gentoo. Preston, I'd be especially grateful if you could see if this works better. * Documentation improvements for RA. * Substitute local address for [::] DHCPv6 options, like DHCPv4. * Lorenzo and John's --localise-queries bug. http://www.thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq- 2.60rc2.tar.gz Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss 0001-Fix-HAVE_BROKEN_RTC-build.patch Description: Binary data ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] 2.60rc2
On 29/02/12 21:56, Preston Crow wrote: Yup. RC4 is good with the ebuild. I would be surprised if the same issue didn't hit everyone building from source on Linux. I was just working on RC2 when I received this email, so good timing. The wrinkle is that it worked fine on gmake 3.81 and only broke on 3.82. Debian is still using 3.81, hence I'd not seen the problem. Fix is the traditional makefile one of fiddling with whitespace ;-) Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] 2.60rc2
Sorry, really missed it. Thanks Best Regards, Vladislav Grishenko -Original Message- From: Simon Kelley [mailto:si...@thekelleys.org.uk] Sent: Thursday, March 01, 2012 3:49 AM To: Vladislav Grishenko Cc: 'dnsmasq discussion list' Subject: Re: [Dnsmasq-discuss] 2.60rc2 On 29/02/12 21:30, Vladislav Grishenko wrote: Doesn't build with HAVE_BROKEN_RTC Trivial fix attached Many Thanks. You missed rc3 by one minute, so there's now http://www.thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq- 2.60rc4.tar.gz which has this fix, and an adjustment to the nasty Makefile-portability hack to make it work with GNU-make 3.82. That should fix the Gentoo problems. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dhcpv6 duid gen
Little additions: Allowing to specify from options would be useful too, eg. for multiple dnsmasq instances Per RFC3315 A DHCP client that generates a DUID-LLT using this (using sort of time source) mechanism MUST provide an administrative interface that replaces the existing DUID with a newly-generated DUID-LLT. This leads to a much more longer client renew, possibly authoritative option could be used to avoid it, can't say now is it per RFC. Not allowed for server, but RECONFIGURE implementation could be handy, including cases of changing options. Best Regards, Vladislav Grishenko -Original Message- From: Vladislav Grishenko [mailto:themi...@mail.ru] Sent: Thursday, March 01, 2012 5:07 AM To: dnsmasq-discuss@lists.thekelleys.org.uk Cc: Simon Kelley (si...@thekelleys.org.uk) Subject: dhcpv6 duid gen Hi, Simon Currenly 2.60 uses first interface and its hw type as (time) link-layer duid source with exceptions of loopback and ppp. RFC3315 says The hardware type MUST be a valid hardware type assigned by the IANA, as described in RFC 826, which describes only 48bit-long ethernet addresses. So, if there's any kind non-ethernet interfaces in system, which has first index, dnsmasq duid generation is obviously wrong. Example - 6to4 tunnel interfaces sit0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-4D-62-00-00-00-00-00- 00-00-00 NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) So, instead of checking device flags, it's better to check against encap type and allow only etherieee802, like dhcp6s/wide-dhcpv6 do. Allowing to specify from options would be useful too, eg. for multiple dnsmasq instances, Also, HAVE_BROKEN_RTC has issue, duid length and allocation should be equal to maclen+4, not maclen+8, because time bits are not used. Seems it's not a good idea to use LLT duid type now even with RTC machines, because if lease file is lost and dnsmasq restarted, it will get new duid and will ignore any renew requests completely. This leads to a much more longer client renew, possibly authoritative option could be used to avoid it, can't say now is it per RFC. Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] 2.60rc4 bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 29.02.2012 22:56, schrieb Preston Crow: Yup. RC4 is good with the ebuild. I would be surprised if the same issue didn't hit everyone building from source on Linux. I was just working on RC2 when I received this email, so good timing. I'd vote HOLD YOUR HORSES on RC4. There's a bug in radv.c line 67 (or rather line 57) in that you declare the wrong type for len. You need socklen_t, but use size_t, which aren't synonyms (this is on FreeBSD 9-STABLE amd64 with clang - because it gives clearer error messages than gcc -, but I checked against POSIX 2008 and Ubuntu 11.04): - --- clang -O2 -pipe -fno-strict-aliasing - -DLOCALEDIR='/tmp/dnsmasq-2.60.r4_1/share/locale' - -DVERSION='2.60rc4' -I/usr/local/include-c radv.c radv.c:67:67: warning: incompatible pointer types passing 'size_t *' (aka 'unsigned long *') to parameter of type 'socklen_t *' (aka 'unsigned int *') [-Wincompatible-pointer-types] getsockopt(fd, IPPROTO_IPV6, IPV6_UNICAST_HOPS, hop_limit, len) || ^~~~ /usr/include/sys/socket.h:612:72: note: passing argument to parameter here int getsockopt(int, int, int, void * __restrict, socklen_t * __restrict); ^ - --- cc -O2 -pipe -fno-strict-aliasing - -DLOCALEDIR='/tmp/dnsmasq-2.60.r4_1/share/locale' - -DVERSION='2.60rc4' -I/usr/local/include-c radv.c radv.c: In function 'ra_init': radv.c:67: warning: passing argument 5 of 'getsockopt' from incompatible pointer type - --- SYNOPSIS #include sys/types.h #include sys/socket.h int getsockopt(int s, int level, int optname, void * restrict optval, socklen_t * restrict optlen); ... - --- Also, when building with clang, there are some more warnings about unused results in expressions. I haven't investigated these. If you want to discard results, cast to void (possibly inside some macro): rfc1035.c:322:9: warning: expression result unused [-Wunused-value] if (!ADD_RDLEN(header, ansp, plen, len)) ^~ rfc1035.c:28:42: note: expanded from: (!CHECK_LEN(header, pp, plen, len) ? 0 : (long)((pp) += (len)), 1) ^ rfc1035.c:361:12: warning: expression result unused [-Wunused-value] if (!ADD_RDLEN(header, ansp, plen, rdlen)) ^~~~ rfc1035.c:28:42: note: expanded from: (!CHECK_LEN(header, pp, plen, len) ? 0 : (long)((pp) += (len)), 1) ^ rfc1035.c:494:12: warning: expression result unused [-Wunused-value] if (!ADD_RDLEN(header, ansp, plen, rdlen)) ^~~~ rfc1035.c:28:42: note: expanded from: (!CHECK_LEN(header, pp, plen, len) ? 0 : (long)((pp) += (len)), 1) ^ rfc1035.c:716:12: warning: expression result unused [-Wunused-value] if (!ADD_RDLEN(header, p, qlen, rdlen)) ^ rfc1035.c:28:42: note: expanded from: (!CHECK_LEN(header, pp, plen, len) ? 0 : (long)((pp) += (len)), 1) ^ rfc1035.c:763:17: warning: expression result unused [-Wunused-value] else if (!ADD_RDLEN(header, p, qlen, rdlen)) ^ rfc1035.c:28:42: note: expanded from: (!CHECK_LEN(header, pp, plen, len) ? 0 : (long)((pp) += (len)), 1) ^ rfc1035.c:1173:12: warning: expression result unused [-Wunused-value] if (!ADD_RDLEN(header, p, qlen, rdlen)) ^ rfc1035.c:28:42: note: expanded from: (!CHECK_LEN(header, pp, plen, len) ? 0 : (long)((pp) += (len)), 1) ^ It is probably safe to leave the unused-value warnings unfixed for 2.60, but the pointer size bug definitely needs fixing before the 2.60 release. Best regards Matthias -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk9OtMQACgkQvmGDOQUufZX/LQCZAVbeQcfJTbczo7rhwguZIXFW C5UAnjvT6B1ceRLh0FQnyf6ffA5XSe27 =qSBj -END PGP SIGNATURE- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] 2.60rc4 bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 01.03.2012 00:29, schrieb Matthias Andree: Am 29.02.2012 22:56, schrieb Preston Crow: Yup. RC4 is good with the ebuild. I would be surprised if the same issue didn't hit everyone building from source on Linux. I was just working on RC2 when I received this email, so good timing. I'd vote HOLD YOUR HORSES on RC4. There's a bug in radv.c line 67 (or rather line 57) in that you declare the wrong type for len. You need socklen_t, but use size_t, which aren't synonyms (this is on FreeBSD 9-STABLE amd64 with clang - because it gives clearer error messages than gcc -, but I checked against POSIX 2008 and Ubuntu 11.04): Sorry Preston, the you isn't directed at you personally, and I didn't mean to point naked fingers at dressed people as the German saying goes, but pinpoint the bug as precisely as I deem useful right before a release. No offense intended. Best regards Matthias -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk9OubIACgkQvmGDOQUufZVi3ACg6tHVfKNLskO9/njaFrY1rl7C vLoAn0RsBgBCKLQDmJAV/MSoAwAlgDOe =bcaz -END PGP SIGNATURE- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] 2.60rc4 bug
And in case anyone was wondering, I've had no issues with the fix for slow start times with a large hosts files with distinct IP addresses. In other words, all the release candidates have looked good with effectively instant start times. My test: /etc/init.d/dnsmasq restart ; host google.com I get a full and proper response on the hostname lookup, so the start time is faster than the shell overhead. Very nice. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Announce: release candidate dnsmasq-2.60rc1
On Tue, Feb 28, 2012 at 08:05:41PM +, Simon Kelley wrote: The DHCPv6 code is looking pretty good now (thanks all testers). So good, in fact, that I think it's time to start moving gently towards a release. I've just created 2.60rc1, available at Just a thought ... having added DHCPv6, perhaps this warrants a major release, i.e., 3.0? :) -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject: ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Announce: release candidate dnsmasq-2.60rc1
Dnia 2012-02-29, o godz. 18:30:57 /dev/rob0 r...@gmx.co.uk napisał(a): On Tue, Feb 28, 2012 at 08:05:41PM +, Simon Kelley wrote: The DHCPv6 code is looking pretty good now (thanks all testers). So good, in fact, that I think it's time to start moving gently towards a release. I've just created 2.60rc1, available at Just a thought ... having added DHCPv6, perhaps this warrants a major release, i.e., 3.0? :) .0 is always broken - better 3.1 ;-) git, lua. And Linux-3. I would vote for major=3 too! The only reason not to do it is when Simon thinks about something really revolutionary. -- jasiu ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
