Re: [Dnsmasq-discuss] dnsmasq using dnscrypt
dnsmasq (2.60-2 on arch 32bit) is supposed to be listening on 127.0.0.1 127.0.0.2 is a second loopback lo:1 on which dnscrypt is listening on, to not interfere with dnsmasq. I got it to work now. Instead of using the "interface" option to define the devices to listen on (seems to auto include all loopback devices, though dnsmasq couldn't have actually listened to 127.0.0.2 since it was already locked by dnscrypt ), I used the 'listen-address' option to define all the ips of my devices. leaving out 127.0.0.2 obviously. now dnsmasq stopped complaining and all my dns traffic is nicely encrypted as it should be. Cheers! Thanks anyway for your time and maybe this is helpful to someone else having similar trouble Max On 03/25/2012 10:13 PM, Simon Kelley wrote: On 24/03/12 23:03, Max wrote: Hallo, I am running dnsmasq on my router and just installed dnscrypt. It works nicely on the box it self ( I checked using dig and tcpdump). I am running dnscrypt on a second local interface lo:1 at 127.0.0.2 Adding the 127.0.0.2 to /etc/resolv.conf or /etc/dnsmasq.conf causes dnsmasq to say ignoring nameserver 127.0.0.2 - local interface I could not find any way to make it accept this one. it always continues to the second nameserver in resolv.conf. If I remove the second one I am left without a dns server. Is there any easy way to make dnsmasq NOT ignore this local nameserver? Dnsmasq is convinced that it's listening for DNS requests on 127.0.0.2. It therefore won't send requests there, because that would cause a loop, which is bad. Now something doesn't make sense here, because you say that dnscrypt is listening on 127.0.0.2 port 53, so dnsmasq can't be listening there too. Could you post you complete dnsmasq config, and maybe the output of netstat -ap and ifconfig as well, to give us some more information to work on? Cheers, Simon. ___ 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] dnsmasq 2.61test7 & RA issues
On 25/03/12 5:04 PM, Jan Seiffert wrote: 2012/3/25 Simon Kelley: On 25/03/12 14:21, Vladislav Grishenko wrote: From: Simon Kelley [snip] The 6to4 case, maybe more useful. But is 6to4 going to be used much in the real world? I'd say 6to4 is the only easy solution for end-users at the moment whose ISP doesn't allow any IPv6. If they uses some kind of CPE in router mode with dnsmasq on-board and want to use IPv6 too, it makes sense. Frankly speaking, in Russia/UA the majority ISP doesn't offer IPv6 connectivity at all. That's true in most places. Very few UK ISPs offer IPv6. Most people I know what want it use a 6in4 tunnel via a tunnel broker. I'm using Sixxs and it works very well. 6to4 has a bad reputation, partly because it comes with asymmetric routing. I think most people will not get IPv6 until their ISP offers it. Don't forget 6RD. It's basically 6to4, but with another, ISP-specific, IPv6 prefix. the ISP "Free" in France uses it to deploy IPv6 to all it's customer AFAIK. The idea is that you don't need any new HW in the backbone/BRAS/whatever, the ISP only deploys new firmware to it's CPEs (if they already can talk 6to4, it's a 150 line change to allow arb. prefixes, see http://patchwork.ozlabs.org/patch/34121/), and the "asymmetric" 6to4 Routers are under the control (and SLAG and whatnot) of the ISP, some extra boxes without ties to the other HW. 6RD does not have the asymmetric routing issues of 6to4, but it is still another poor transition mechanism that should not be used in a serious production IPv6 environments and no ISP taking IPv6 seriously will use it. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues
> From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- > discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Jan Seiffert > Sent: Monday, March 26, 2012 3:04 AM > To: dnsmasq discussion list > Subject: Re: [Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues > > 2012/3/25 Simon Kelley : > > On 25/03/12 14:21, Vladislav Grishenko wrote: > >>> From: Simon Kelley > [snip] > >>> The 6to4 case, maybe more useful. > >>> But is 6to4 going to be used much in the real world? > >> I'd say 6to4 is the only easy solution for end-users at the moment > >> whose ISP doesn't allow any IPv6. > >> If they uses some kind of CPE in router mode with dnsmasq on-board > >> and want to use IPv6 too, it makes sense. > >> Frankly speaking, in Russia/UA the majority ISP doesn't offer IPv6 > >> connectivity at all. > > > > That's true in most places. Very few UK ISPs offer IPv6. Most people I > > know what want it use a 6in4 tunnel via a tunnel broker. I'm using > > Sixxs and it works very well. 6to4 has a bad reputation, partly > > because it comes with asymmetric routing. > > > > I think most people will not get IPv6 until their ISP offers it. > > > > Don't forget 6RD. It's basically 6to4, but with another, ISP-specific, > IPv6 prefix. the ISP "Free" in France uses it to deploy IPv6 to all it's > customer > AFAIK. > The idea is that you don't need any new HW in the > backbone/BRAS/whatever, the ISP only deploys new firmware to it's CPEs (if > they already can talk 6to4, it's a 150 line change to allow arb. > prefixes, see http://patchwork.ozlabs.org/patch/34121/), and the > "asymmetric" 6to4 Routers are under the control (and SLAG and whatnot) of > the ISP, some extra boxes without ties to the other HW. Actually 6to4 is subset of 6RD with preset 2002:: prefix and 32bit of ipv4 address length. So, talking about 6to4 as more common solution with dynamic IPv4 , ISP's 6RD is assumed too. 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] dnsmasq 2.61test7 & RA issues
2012/3/25 Simon Kelley : > On 25/03/12 14:21, Vladislav Grishenko wrote: >>> From: Simon Kelley [snip] >>> The 6to4 case, maybe more useful. >>> But is 6to4 going to be used much in the real world? >> I'd say 6to4 is the only easy solution for end-users at the moment whose ISP >> doesn't allow any IPv6. >> If they uses some kind of CPE in router mode with dnsmasq on-board and want >> to use IPv6 too, it makes sense. >> Frankly speaking, in Russia/UA the majority ISP doesn't offer IPv6 >> connectivity at all. > > That's true in most places. Very few UK ISPs offer IPv6. Most people I > know what want it use a 6in4 tunnel via a tunnel broker. I'm using Sixxs > and it works very well. 6to4 has a bad reputation, partly because it > comes with asymmetric routing. > > I think most people will not get IPv6 until their ISP offers it. > Don't forget 6RD. It's basically 6to4, but with another, ISP-specific, IPv6 prefix. the ISP "Free" in France uses it to deploy IPv6 to all it's customer AFAIK. The idea is that you don't need any new HW in the backbone/BRAS/whatever, the ISP only deploys new firmware to it's CPEs (if they already can talk 6to4, it's a 150 line change to allow arb. prefixes, see http://patchwork.ozlabs.org/patch/34121/), and the "asymmetric" 6to4 Routers are under the control (and SLAG and whatnot) of the ISP, some extra boxes without ties to the other HW. [snip] > Cheers, > > Simon. > Greetings Jan -- ˙qɐɥ ʇɟnɐʞǝƃ ʎɐqǝ ıǝq ɹnʇɐʇsɐʇ ǝuıǝ ɹıɯ ɥɔı sɐp lɐɯ ǝʇzʇǝl sɐp ʇsı sɐp 'ʇɯɯɐpɹǝʌ ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq using dnscrypt
On 24/03/12 23:03, Max wrote: > Hallo, > > I am running dnsmasq on my router and just installed dnscrypt. It works > nicely on the box it self ( I checked using dig and tcpdump). I am > running dnscrypt on a second local interface lo:1 at 127.0.0.2 > Adding the 127.0.0.2 to /etc/resolv.conf or /etc/dnsmasq.conf > > causes dnsmasq to say > > ignoring nameserver 127.0.0.2 - local interface > > I could not find any way to make it accept this one. it always continues > to the second nameserver in resolv.conf. If I remove the second one I am > left without a dns server. > > Is there any easy way to make dnsmasq NOT ignore this local nameserver? > Dnsmasq is convinced that it's listening for DNS requests on 127.0.0.2. It therefore won't send requests there, because that would cause a loop, which is bad. Now something doesn't make sense here, because you say that dnscrypt is listening on 127.0.0.2 port 53, so dnsmasq can't be listening there too. Could you post you complete dnsmasq config, and maybe the output of netstat -ap and ifconfig as well, to give us some more information to work on? Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues
Sure, will look and update you ASAP Thanks Best Regards, Vladislav Grishenko > -Original Message- > From: Simon Kelley [mailto:si...@thekelleys.org.uk] > Sent: Monday, March 26, 2012 1:58 AM > To: Vladislav Grishenko > Cc: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues > > > Please could you look at 2.61test8, in the usual places now? > > I wrote a long email detailing the various orthogonal config options and which > combinations were useful, which helped my thoughts enormously, but > probably didn't make things clear for anyone else. > > Note that I've not updated the man pages or examples yet, but here are > examples of all the things that might be useful. > > > Do DHCPv6 on subnets, do router advertisements on these subnets with M > and O bits set and A bit not set, so that no SLAAC addresses used. > enable-ra > dhcp-range=1234::100, 1234::200 > dhcp-range=2345::100, 2345::200 > > As above, but for this subnet, set A bit so clients use SLAAC addresses as well > dhcp-range=1234::100, 1234::200, slaac > > > Don't do DHCPv6 on subnet, only RA. M and O bits clear, A bit set dhcp- > range=1234::, ra-only > > As above, but also use DHCPv4-derived names for SLAAC addresses dhcp- > range=1234::, ra-names. > > > Do stateless DHCPv6 and RA on subnet. clear M bit, set O and A bits dhcp- > range=1234::, ra-stateless > > As above, but also use DHCPv4 derived names dhcp-range=1234::, ra- > stateless, ra-names > > It came together quite well, I think.. > > > Cheers, > > Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues
Please could you look at 2.61test8, in the usual places now? I wrote a long email detailing the various orthogonal config options and which combinations were useful, which helped my thoughts enormously, but probably didn't make things clear for anyone else. Note that I've not updated the man pages or examples yet, but here are examples of all the things that might be useful. Do DHCPv6 on subnets, do router advertisements on these subnets with M and O bits set and A bit not set, so that no SLAAC addresses used. enable-ra dhcp-range=1234::100, 1234::200 dhcp-range=2345::100, 2345::200 As above, but for this subnet, set A bit so clients use SLAAC addresses as well dhcp-range=1234::100, 1234::200, slaac Don't do DHCPv6 on subnet, only RA. M and O bits clear, A bit set dhcp-range=1234::, ra-only As above, but also use DHCPv4-derived names for SLAAC addresses dhcp-range=1234::, ra-names. Do stateless DHCPv6 and RA on subnet. clear M bit, set O and A bits dhcp-range=1234::, ra-stateless As above, but also use DHCPv4 derived names dhcp-range=1234::, ra-stateless, ra-names It came together quite well, I think.. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Feature Request: tftp-script
Hi, What I was suggesting in my previous post was ... lets consider the following as a possible scenario ... --- snip --- tftp-script=/path/to/mytftpscript dhcp-script=/path/to/mydhcpscript dhcp6-script=/path/to/mydhcp6script dns-script=/path/to/dnsscript dns6-script=/path/to/dns6script --- snip --- [root@server ~]# ls -l /path/to/mytftpscript lrwxrwxrwx. 1 root root 3 Mar 21 00:20 /path/to/mytftpscript -> mycommonscript [root@server ~]# ls -l /path/to/mydhcpscript lrwxrwxrwx. 1 root root 3 Mar 21 00:20 /path/to/mydhcpscript -> mycommonscript [root@server ~]# ls -l /path/to/mydhcp6script lrwxrwxrwx. 1 root root 3 Mar 21 00:20 /path/to/mydhcp6script -> mycommonscript ... and so on ... The "mycommonscript" should have the necessary logic to decide which "script" is actually being called based of the value of "$0" (argv[0] in C speak) (the actual filename) Keeping it this way would allow you to separate the "$1" value for the various possibilities, and not have to worry about script breakage during adding more parameters. It becomes the script-writer's headache to cater/handle parameters as they appear (!) The very attractive part here is that the user has to maintain only a single script. Regards, Shantanu --- On Wed, 3/21/12, Simon Kelley wrote: > From: Simon Kelley > Subject: Re: [Dnsmasq-discuss] Feature Request: tftp-script > To: dnsmasq-discuss@lists.thekelleys.org.uk > Date: Wednesday, March 21, 2012, 5:35 PM > On 21/03/12 11:49, Ed W wrote: > > On 21/03/2012 09:50, Simon Kelley wrote: > >> http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.61test7.tar.gz > >> > >> > >> Has the "tftp" action implemented. At the moment > it's sent to the > >> --dhcp-script script always. I'm still tending > towards that solution, > >> but haven't made the final decision. The bulk of > the changes are done > >> anyway. > > > > Just from the point of view of longer term plans. > Recently I actually > > read the documentation on Nginx perl (I think I put in > the correct link > > below?). > > http://zzzcpan.github.com/nginx-perl/ > > > > The point of looking is simply that at first sight, > embedding a > > relatively slow scripting language looks troublesome > and a performance > > issue. However, I was quite surprised at just HOW > embedded is perl in > > what is perhaps one of the highest performing network > server software we > > have to study at the moment > > > > Lua would seem like a better bet for dnsmasq (than > perl) due to the very > > low installation size. Also performance is alleged to > be extremely high > > (for a scripting language) and the runtime is designed > with > > embeddability in mind. Nginx also allows embedded lua, > although I > > haven't studied to see if they achieve similar levels > of integration > > > > I have an application (captive portal) where it would > be quite > > interesting to "manufacture" answers under some > conditions, tweak > > answers under others, and also "cheat" on caching > timeouts in specific > > situations (if the user if offline/dialup for > example). > > > > Just trying to put ideas into your head... > > > > Ed, > > It's not quite clear if you've looked at dnsmasq-2.60+ or > not. Try > > > make COPTS=-DHAVE_LUASCRIPT > > Lua got there first. > > > There's an architectural problem with all the scripting (Lua > and > fork/exec) in dnsmasq at the moment; there's no sensible way > to get > information from the script back to dnsmasq. Events in > dnsmasq get sent > asynchronously down a pipe to a distinct the process which > then runs the > script. This achieves 1) privilege separation. 2) Script > can't block > dnsmasq - especially important when dnsmasq is a bit of a > swiss-army knife. > > There is a back-channel for errors, which could be expanded. > But there's > no sensible way at the moment to make dnsmasq wait whilst > (eg) a script > tweaks a DNS answer. > > Cheers, > > Simon. > > > > > > ___ > 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] dnsmasq 2.61test7 & RA issues
> From: Simon Kelley > Sent: Sunday, March 25, 2012 7:48 PM > > 3.Periodic RA isn't working, because alarm code goes into (dhcp || > > dhcp6) path and don't trigger RA alarms > > This code does that, I think. > > #ifdef HAVE_DHCP6 > else if (daemon->ra_contexts) > /* Not doing DHCP, so no lease system, manage alarms for > ra > >>> only */ > send_alarm(periodic_ra(now), now); #endif > >>> > >>> Yes, but it "else" condition of (damon->dhcp || daemon->dhcp6). > >>> In my case and example, damon->dhcp is enabled, so periodic_ra will > >>> not be executed as expected several times while first minute. > >> > >> In the damon->dhcp || daemon->dhcp6 case, send_alarm is called from > >> lease_update_file, since the first event in the future might be a > >> lease > > expiry, > >> or it might be an RA multicast. > > > > Got it, unfortunately under some circumstances there'll be neither > > incoming router solicitations nor immediate dhcp leases expiration to > trigger RA. > > Example: big dhcpv4 leases ~ week to not stress network, dnsmasq > > restart due reboot/etc, clients connected via 3 network switches > > dnsmasq - [switch1] - [switch2] - [switch3] - IPV6 only clients. > > If switch 2 is temporary off, dnsmasq and clients see the links up and > > therefore take no action, so RA packets could be either not > > originated/ or just lost. > > That means RA timers should work independent to other dhcp/dhcp6 > > events, especially if the last ones are quite long. > > They do. Check the code at the end of lease_update_file() > > It find the shortest of > time to next RA > time to next ICMP6 for SLAAC-confirm > time to next lease expiry > LEASE_RETRY - if the leasefile write failed. > > and sets the alarm to the time to first event. > > > > > > Only other netlink/dhcpv4 events could trigger it. Also, even if > > fixed event logic leads to DHCP leases rewrite on every RA event > > by > >> design. > >> > >> It shouldn't. There'd a check in lease_update_file of the file_dirty flag. > > > > Yep, really. Thanks for pointing out. > > > >> The 6to4 case, maybe more useful. > >> But is 6to4 going to be used much in the real world? > > I'd say 6to4 is the only easy solution for end-users at the moment > > whose ISP doesn't allow any IPv6. > > If they uses some kind of CPE in router mode with dnsmasq on-board and > > want to use IPv6 too, it makes sense. > > Frankly speaking, in Russia/UA the majority ISP doesn't offer IPv6 > > connectivity at all. > > That's true in most places. Very few UK ISPs offer IPv6. Most people I know > what want it use a 6in4 tunnel via a tunnel broker. I'm using Sixxs and it works > very well. 6to4 has a bad reputation, partly because it comes with > asymmetric routing. > > I think most people will not get IPv6 until their ISP offers it. Asymmetric routing can't be treated as bad-only, it has dual effect that makes lower RTT also possible, comparing to 6in4/gogo6/etc tunnels per countries. I'd say it's geo-dependent. Anyway, 6to4 pro and cons discussing is out of the subject, the fact is it's still more than widely used and will be used tomorrow and even the day after tomorrow. Personally I can't force users avoid to use tunnels just because it's theoretically worse than native IPv6 connections, which are just not available. Not a perfect world, yeah. > > But, there's no other easy way to get runtime clients stats including > > expiration (actually, preferred remaining) time with HAVE_BROKEN_RTC. > > With udpcpd it can be done via dumpleases or just to read & parse > > udhcpd's lease file and I was hoping for the same approach for dnsmasq. > > Leases get read by request, so triggering actual lease file write > > isn't the problem (used signal), the problem is no expiration/remaining > time. > > Use a dhcp-script. That has the the information you need in the environment > variable DNSMASQ_TIME_REMAINING. > > If you don't want to store the data persistently, then send SIGHUP to > dnsmasq and it will call the script on all existing leases with an "old" > event. Thanks, that was the documented way, Script support gives +10Kb to dnsmasq size, corresponding script binding and asymmetric of per-lease recording add more complexity. So, I was thinking just about to add another one parameter to dnsmasq leases file with remaining time. Code is shared for RTC and BROKEN_RTC, costs almost nothing to size, and for second case it would fix lease prolongation issue as well. Of course, I can use it for my purposes only, just let you know about. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues
On 25/03/12 14:21, Vladislav Grishenko wrote: >> From: Simon Kelley >> Sent: Sunday, March 25, 2012 6:17 PM > > 3.Periodic RA isn't working, because alarm code goes into (dhcp || > dhcp6) path and don't trigger RA alarms This code does that, I think. #ifdef HAVE_DHCP6 else if (daemon->ra_contexts) /* Not doing DHCP, so no lease system, manage alarms for ra >>> only */ send_alarm(periodic_ra(now), now); #endif >>> >>> Yes, but it "else" condition of (damon->dhcp || daemon->dhcp6). >>> In my case and example, damon->dhcp is enabled, so periodic_ra will >>> not be executed as expected several times while first minute. >> >> In the damon->dhcp || daemon->dhcp6 case, send_alarm is called from >> lease_update_file, since the first event in the future might be a lease > expiry, >> or it might be an RA multicast. > > Got it, unfortunately under some circumstances there'll be neither incoming > router solicitations nor immediate dhcp leases expiration to trigger RA. > Example: big dhcpv4 leases ~ week to not stress network, dnsmasq restart due > reboot/etc, clients connected via 3 network switches > dnsmasq - [switch1] - [switch2] - [switch3] - IPV6 only clients. > If switch 2 is temporary off, dnsmasq and clients see the links up and > therefore take no action, so RA packets could be either not originated/ or > just lost. > That means RA timers should work independent to other dhcp/dhcp6 events, > especially if the last ones are quite long. They do. Check the code at the end of lease_update_file() It find the shortest of time to next RA time to next ICMP6 for SLAAC-confirm time to next lease expiry LEASE_RETRY - if the leasefile write failed. and sets the alarm to the time to first event. > > Only other netlink/dhcpv4 events could trigger it. Also, even if > fixed event logic leads to DHCP leases rewrite on every RA event by >> design. >> >> It shouldn't. There'd a check in lease_update_file of the file_dirty flag. > > Yep, really. Thanks for pointing out. > >> The 6to4 case, maybe more useful. >> But is 6to4 going to be used much in the real world? > I'd say 6to4 is the only easy solution for end-users at the moment whose ISP > doesn't allow any IPv6. > If they uses some kind of CPE in router mode with dnsmasq on-board and want > to use IPv6 too, it makes sense. > Frankly speaking, in Russia/UA the majority ISP doesn't offer IPv6 > connectivity at all. That's true in most places. Very few UK ISPs offer IPv6. Most people I know what want it use a 6in4 tunnel via a tunnel broker. I'm using Sixxs and it works very well. 6to4 has a bad reputation, partly because it comes with asymmetric routing. I think most people will not get IPv6 until their ISP offers it. > >>> Don't you find this trade-off between totally inaccurate lease time >>> and almost accurate with expections - as acceptable? >> >> Yes. It would be unacceptable if the leases turned out shorter than >> promised, but this can only make the leases longer. When a client gets a >> lease, it gets a promise that the address ins available for x hours. >> Increasing the time before the lease expires can only be a problem if > there's >> a shortage of addresses, so that addresses cannot be reused. In most > cases, >> the DHCP server will be up much longer than the lease time, so the effect > is >> small. If the DHCP server goes down often, the solution is to reduce the > lease >> time. Reducing the frequency of writes to flash is important. > > Ok, that's true, it doesn't harm. > But, there's no other easy way to get runtime clients stats including > expiration (actually, preferred remaining) time with HAVE_BROKEN_RTC. > With udpcpd it can be done via dumpleases or just to read & parse udhcpd's > lease file and I was hoping for the same approach for dnsmasq. > Leases get read by request, so triggering actual lease file write isn't the > problem (used signal), the problem is no expiration/remaining time. Use a dhcp-script. That has the the information you need in the environment variable DNSMASQ_TIME_REMAINING. If you don't want to store the data persistently, then send SIGHUP to dnsmasq and it will call the script on all existing leases with an "old" event. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues
> From: Simon Kelley > Sent: Sunday, March 25, 2012 6:17 PM > >>> 3.Periodic RA isn't working, because alarm code goes into (dhcp || > >>> dhcp6) path and don't trigger RA alarms > >> > >> This code does that, I think. > >> > >> #ifdef HAVE_DHCP6 > >> else if (daemon->ra_contexts) > >>/* Not doing DHCP, so no lease system, manage alarms for > >> ra > > only */ > >> send_alarm(periodic_ra(now), now); #endif > > > > Yes, but it "else" condition of (damon->dhcp || daemon->dhcp6). > > In my case and example, damon->dhcp is enabled, so periodic_ra will > > not be executed as expected several times while first minute. > > In the damon->dhcp || daemon->dhcp6 case, send_alarm is called from > lease_update_file, since the first event in the future might be a lease expiry, > or it might be an RA multicast. Got it, unfortunately under some circumstances there'll be neither incoming router solicitations nor immediate dhcp leases expiration to trigger RA. Example: big dhcpv4 leases ~ week to not stress network, dnsmasq restart due reboot/etc, clients connected via 3 network switches dnsmasq - [switch1] - [switch2] - [switch3] - IPV6 only clients. If switch 2 is temporary off, dnsmasq and clients see the links up and therefore take no action, so RA packets could be either not originated/ or just lost. That means RA timers should work independent to other dhcp/dhcp6 events, especially if the last ones are quite long. > >>> Only other netlink/dhcpv4 events could trigger it. Also, even if > >>> fixed event logic leads to DHCP leases rewrite on every RA event by > design. > > It shouldn't. There'd a check in lease_update_file of the file_dirty flag. Yep, really. Thanks for pointing out. > The 6to4 case, maybe more useful. > But is 6to4 going to be used much in the real world? I'd say 6to4 is the only easy solution for end-users at the moment whose ISP doesn't allow any IPv6. If they uses some kind of CPE in router mode with dnsmasq on-board and want to use IPv6 too, it makes sense. Frankly speaking, in Russia/UA the majority ISP doesn't offer IPv6 connectivity at all. > > Don't you find this trade-off between totally inaccurate lease time > > and almost accurate with expections - as acceptable? > > Yes. It would be unacceptable if the leases turned out shorter than > promised, but this can only make the leases longer. When a client gets a > lease, it gets a promise that the address ins available for x hours. > Increasing the time before the lease expires can only be a problem if there's > a shortage of addresses, so that addresses cannot be reused. In most cases, > the DHCP server will be up much longer than the lease time, so the effect is > small. If the DHCP server goes down often, the solution is to reduce the lease > time. Reducing the frequency of writes to flash is important. Ok, that's true, it doesn't harm. But, there's no other easy way to get runtime clients stats including expiration (actually, preferred remaining) time with HAVE_BROKEN_RTC. With udpcpd it can be done via dumpleases or just to read & parse udhcpd's lease file and I was hoping for the same approach for dnsmasq. Leases get read by request, so triggering actual lease file write isn't the problem (used signal), the problem is no expiration/remaining time. 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] dnsmasq 2.61test7 & RA issues
On 24/03/12 15:38, Vladislav Grishenko wrote: > More than agree, I respect your position and thanks for the effort. > But, it was quite expected that RA support improvement is about to be asked > just because it exists already in sub-minimal form, > So, just a matter of time, I guess. Of course, RA is not right yet and your suggestions are good ones. > >> That said, I think SLAAC+stateless DHCPv6 is a mode I want to support, and > it >> isn't supported at the moment, you're right. > > Ok, this solution is quite common until all possible clients/hosts are > dhcpv6-statful-aware. > >> >> A way to do this is is have a "real" dhcp range, as well as the ra-only > one. The >> will solve at least some of these problems. The M+O bits will both be > set, but >> DHCPv6 requests for stateless options will be honoured. > > You mean different prefixes? Hosts should ignore RA prefix if there's > managed bit set. > Same prefix dhcp-range = 1234::1,1234::100 dhcp-range = 1234::, ra-only does the same as dhcp-range = 1234::1,1234::100 enable-ra _except_ that the managed bits won't be set in the RA replies. It's not pretty, but is does work. >> There's no way to set only the O bit, I'll think about how to do that. > > Probably, ra-only/ra-names syntax can could be replaced with > slaac/dhcp6-stateless/dhcp-statefull form.. > Can't say about the best solution which natively fits conf syntax. Something like that. There's a trade-off between having something that's simple (ie pick one keyword) and the fact that there are several independent things to configure (DHCP-addresses, DHCP-other, SLAAC, SLAAC names from DHCPv4) > >>> 3.Periodic RA isn't working, because alarm code goes into (dhcp || >>> dhcp6) path and don't trigger RA alarms >> >> This code does that, I think. >> >> #ifdef HAVE_DHCP6 >> else if (daemon->ra_contexts) >>/* Not doing DHCP, so no lease system, manage alarms for ra > only */ >> send_alarm(periodic_ra(now), now); #endif > > Yes, but it "else" condition of (damon->dhcp || daemon->dhcp6). > In my case and example, damon->dhcp is enabled, so periodic_ra will not be > executed as expected several times while first minute. In the damon->dhcp || daemon->dhcp6 case, send_alarm is called from lease_update_file, since the first event in the future might be a lease expiry, or it might be an RA multicast. > >>> Only other netlink/dhcpv4 events could trigger it. Also, even if fixed >>> event logic leads to DHCP leases rewrite on every RA event by design. It shouldn't. There'd a check in lease_update_file of the file_dirty flag. >> >> I'm not sure I follow that. How? > > In ra_init first next event(s) are set to now or a bit ahead of ra_time. > At the dhcp/netlink alarm moment they could be in the past and therefore > just executed without any new ra alarm rearm. > This causes only post-check of ra conext timers. Got it. Thank you. > >>> About prefix lifetimes, you refer rfc2462 in the code which is >>> obsoleted by rfc4862. >>> 2 hours rules is only about Valid Lifetime, but Preferred Lifetime >>> might be and usually is much smaller in dynamic v6 prefix environments. >>> The problem is dnsmasq doesn't use separate valid/preferred values, >>> this leads to default gateway lost issue due some "server" >>> reconfiguration when client still threat 2h prefix is valid and > preferred. >> >> This is a bigger problem: how to support hitless network re-numbering. >> I'll tackle it if it becomes clear that it's actually needed for the sort > of >> applications dnsmasq gets used for. At the moment it's not clear it will > be. > > I can say that dnsmasq is widely used in embedded CPEs with wide range of > IPv6 upstream types. > Two cases really require the inner network renumbering support - 6to4 tunnel > with dynamic ipv4 external address and dhcpv6 with dynamic IA_PD. > IPv6 world has no NAT (in traditional meaning), so it's quite pointless to > setup private unrouted IPv6 ranges for local networks. > Transparent renumbering is a big deal, to force client to treat old prefix > as expired, its lifetimes should be dropped to zero, if not (not possible) - > administrator may set preferred lifetime to small value. This will force new > connection to be originated from the new address. When valid lifetime is > over - all existing connections should be disconnected by the stack > immediately. Agreed, I'm in touch with the Bufferbloat/CeroWRT people, who are working on next-gen CPE implementations, but we've not go around to talking much about this yet. I know that Comcast, in the 'states, is talking about delegating prefixes for 6 months at a time, so renumbering is not a "must have" just yet. It's one of those things that add lost of bloat to the spec, but it's not clear how useful it really will be. The 6to4 case, maybe more useful. But is 6to4 going to be used much in the real world? I'm thinking about adding a "deprecated" keyword to dhcp-range, to set the pr
