Re: [Dnsmasq-discuss] Patch to cache SRV records - updated version (#3)
On 01/07/2019 08:32 AM, Simon Kelley wrote: > I've worked through the patch, and been inspired to clean up a few > long-standing nasty bits. This has the consequence that the mechanisms > which were added to enable storage of DNSKEY and DS RRtypes during the > the DNSSEC campaign are now much more general, and I've used them to > implement SRV caching. The new code is therefore all mine, as are any > bugs, but the net effect is the same as Jeremy's (I hope). > > > I didn't implement a config switch to disable caching of SRV records, > because I can't conceive of a situation where such would be necessary. > > > Code is in the git repo now, and we're eating the new dog food here. > Please test away. New to the list but just wanted to report my experience with the “new dog food”. I use dnsmasq in Docker and have a script that will fully build my configuration from the official Ubuntu docker image and the dnsmasq git repository HEAD. Its been working well for almost a year now. I only once had to rollback a commit when it broke compilation and after some waiting, a new commit fixed the issue. After updating to commit 5b99eae59d59a8e34a7e512059b98bbd803312f2 today, I’m finding that it dies with a "Segmentation fault (core dumped)" in about 30 minutes or less. I compile it with CFLAGS='-Wall -W -O2 -DNO_IPV6 and launch it with /usr/local/sbin/dnsmasq -d --log-facility=/var/log/dnsmasq.log If you have any advice on capturing more information about the segfault, let me know. -Daniel___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Patch to cache SRV records - updated version (#3)
On 01/07/2019 08:32 AM, Simon Kelley wrote: > I've worked through the patch, and been inspired to clean up a few > long-standing nasty bits. This has the consequence that the mechanisms > which were added to enable storage of DNSKEY and DS RRtypes during the > the DNSSEC campaign are now much more general, and I've used them to > implement SRV caching. The new code is therefore all mine, as are any > bugs, but the net effect is the same as Jeremy's (I hope). > > > I didn't implement a config switch to disable caching of SRV records, > because I can't conceive of a situation where such would be necessary. > > > Code is in the git repo now, and we're eating the new dog food here. > Please test away. Thanks a *lot* Simon. I'll start testing this new version asap. Jeremy. signature.asc Description: OpenPGP digital signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCP, how to ignore the client MAC address?
On 1/7/2019 4:23 PM, smicha wrote: > Hi all, > > first of all, thank you for the grade software !!! > But I have a small questions regarding "dnsmasq" and DHCP requests. > > Background: > We have running different, isolated test-landscapes. In each network a > VM is running with dnsmasq, which do the DHCP/DNS task. > Some of the VM's in the landscape needs to have a "static" DHCP-IP, > because a Firewall in front of the landscape routes traffic to the VM's > (Rules are IP based) > > So far so good. > > Sometimes, when VM's (with the static DHCP-IP) has some problems and > crash's and can not "release" there DHCP-IP, we need to re-deploy the > same VM from our pool. > But, when the re-deployement process is starting, that new VM will have > a different MAC Address per default. The Hostname is the same as before > the old one had. > > Now, the problem is begin, because dnsmasq have already a valid DHCP > lease for the old (destroyed) VM and the new, re-deployed VM will get a > different IP as expect. > > I see in the dnsmasq logfile the following message: > > not using configured address 10.117.247.79 because it is leased to > 00:50:56:85:02:ff > > The traffic from the firewall in front of, can reach the new VM (because > the new VM does not have the correct expected IP). > > In the past I use the tool "dhcp_release" to fix the issue, but now I > ask is there an other way to fix this problem. > > > Question: > I there an option, that dnsmasq ignore the Client MAC address for > "static" DHCP leases? > > > As far as I see, dnsmasq use a combination of "Hostname" and "MAC" for > the DHCP leases. > > > I hope I could describe my problem understandable ;-) > Some hints from dnsmasq.conf: # Give the machine which says its name is "bert" IP address # 192.168.0.70 and an infinite lease #dhcp-host=bert,192.168.0.70,infinite # Always give the host with client identifier 01:02:02:04 # the IP address 192.168.0.60 #dhcp-host=id:01:02:02:04,192.168.0.60 # Always give the host with client identifier "marjorie" # the IP address 192.168.0.60 #dhcp-host=id:marjorie,192.168.0.60 # Enable the address given for "judge" in /etc/hosts # to be given to a machine presenting the name "judge" when # it asks for a DHCP lease. #dhcp-host=judge See also (1) for more info on 'dhcp-host'. 1) http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html -- John Doe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Patch to cache SRV records - updated version (#3)
I've worked through the patch, and been inspired to clean up a few long-standing nasty bits. This has the consequence that the mechanisms which were added to enable storage of DNSKEY and DS RRtypes during the the DNSSEC campaign are now much more general, and I've used them to implement SRV caching. The new code is therefore all mine, as are any bugs, but the net effect is the same as Jeremy's (I hope). I didn't implement a config switch to disable caching of SRV records, because I can't conceive of a situation where such would be necessary. Code is in the git repo now, and we're eating the new dog food here. Please test away. Cheers, Simon. On 20/12/2018 23:20, Jeremy Allison wrote: > On 12/20/2018 03:11 PM, Simon Kelley wrote: >> This is worth having for the removal of the archaic 16-bit limit on the >> flags field in a cache record alone. I've been meaning to tackle that >> for some time. >> >> This time of year either frees up lots of time for coding, or yields >> none at all, and for me it's the later, but I will go through this and >> merge it in the new year. > > Oh thanks for the comments. I'm currently running this version > under valgrind (with a minor test hack to force negative > SRV records to explitly expire after 60 seconds to ensure > I'm going through the cache expire code paths) and it seems > robust so far. > > There are some people in the ChromeOS Teams also looking > at this, although as it's holiday time here in the US it > might not get fully examined until Jan. If anyone finds > any more errors with it under test I'll let you know > and update it. > > Cheers & thanks and Merry Christmas / Happy Holidays ! > > Jeremy. > signature.asc Description: OpenPGP digital signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] DHCP, how to ignore the client MAC address?
Hi all, first of all, thank you for the grade software !!! But I have a small questions regarding "dnsmasq" and DHCP requests. Background: We have running different, isolated test-landscapes. In each network a VM is running with dnsmasq, which do the DHCP/DNS task. Some of the VM's in the landscape needs to have a "static" DHCP-IP, because a Firewall in front of the landscape routes traffic to the VM's (Rules are IP based) So far so good. Sometimes, when VM's (with the static DHCP-IP) has some problems and crash's and can not "release" there DHCP-IP, we need to re-deploy the same VM from our pool. But, when the re-deployement process is starting, that new VM will have a different MAC Address per default. The Hostname is the same as before the old one had. Now, the problem is begin, because dnsmasq have already a valid DHCP lease for the old (destroyed) VM and the new, re-deployed VM will get a different IP as expect. I see in the dnsmasq logfile the following message: not using configured address 10.117.247.79 because it is leased to 00:50:56:85:02:ff The traffic from the firewall in front of, can reach the new VM (because the new VM does not have the correct expected IP). In the past I use the tool "dhcp_release" to fix the issue, but now I ask is there an other way to fix this problem. Question: I there an option, that dnsmasq ignore the Client MAC address for "static" DHCP leases? As far as I see, dnsmasq use a combination of "Hostname" and "MAC" for the DHCP leases. I hope I could describe my problem understandable ;-) Many Thanks Michael ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent
On Mon, Jan 07, 2019 at 01:09:11PM +0530, Sandeep K M wrote: > On Fri, Jan 4, 2019 at 7:32 PM Geert Stappers wrote: > > On Fri, Jan 04, 2019 at 05:34:03PM +0530, Sandeep K M wrote: > > > > > Please let me know if any other information is needed. > > > > Not yet mentioned in this thread is working connectity between "server" > > and "client". This will require temporary manual configuration > > of an IPv6 address at client. Let say it is 2020::2/120. > > Then verify with more than "ping". Example given: `ssh 1040::2` > > > > It shall reveal how well router ( with the odd name 'Switch' ) is > > configured for routing between 1040::/120 and 2020::/120. > > Also if the ssh deamon is able to send packets out on the right > > interface. > > > > I do know that it might seem a detour. And we also known that > > original poster is already stuck with current setup. So the "detour" > > could be a step forward. Good luck. > > > > > Hi, > > As you suggested I added the IPv6 address 2020::2/120 manually to my client > > # ip -6 addr add 2020::2/120 dev eth1 > > when I pinged the server it failed : > > root@Ubuntu3481:~# ping6 -I 2020::2 1040::2 > PING 1040::2(1040::2) from 2020::2 : 56 data bytes > ping: sendmsg: Network is unreachableping: sendmsg: Network is unreachale > > Then I added a default route: > > > root@Ubuntu3481:~# ip -6 route add default via 2020::1 > root@Ubuntu3481:~# ip -6 route > 2020::/120 dev eth1 proto kernel metric 256 > fe80::/64 dev eth0 proto kernel metric 256 > fe80::/64 dev eth1 proto kernel metric 256 > default via 2020::1 dev eth1 metric 1024 > > I see the ping is working fine now: > > root@Ubuntu3481:~# ping6 -I 2020::2 1040::2 > PING 1040::2(1040::2) from 2020::2 : 56 data bytes > 64 bytes from 1040::2: icmp_seq=1 ttl=63 time=0.278 ms > 64 bytes from 1040::2: icmp_seq=2 ttl=63 time=0.178 ms > 64 bytes from 1040::2: icmp_seq=3 ttl=63 time=0.172 ms So ICMP packets can roundtrip across the router. If other packets can, is still unknown. (As in '> > Then verify with more than "ping". Example given: `ssh 1040::2`') Idea is finding out if the original problem could be caused by incomplete routing rules. > But when I remove the manually configured IPv6 address and try to get a new > IPv6 using "dhclient -6 eth1" again it fails. I see the same log lines in > dnsmasq log: > > Jan 7 07:19:54 dnsmasq-dhcp[3815]: DHCPSOLICIT(m1s1p7) > 00:01:00:01:23:c5:ba:1b:00:50:56:96:d1:7c > Jan 7 07:19:54 dnsmasq-dhcp[3815]: DHCPADVERTISE(m1s1p7) 2020::19 > 00:01:00:01:23:c5:ba:1b:00:50:56:96:d1:7c > Jan 7 07:19:55 dnsmasq-dhcp[3815]: DHCPSOLICIT(m1s1p7) > 00:01:00:01:23:c5:ba:1b:00:50:56:96:d1:7c > Jan 7 07:19:55 dnsmasq-dhcp[3815]: DHCPADVERTISE(m1s1p7) 2020::19 > 00:01:00:01:23:c5:ba:1b:00:50:56:96:d1:7c > > When we have enable-ra configured wont dnsmasq advertise the gateway IP's ? > Do we need to enable RA even in the switch where relay agent is running ? > can we configure default gateway to the clients via dhcpv6 options similar > to IPv4 ? > > > PS: If I replace dnsmasq server with ISC DHCP server everything works fine. And the essential configuration items of the working setup are correctly transposed to the non-working setup? Regards Geert Stappers Curious about why the DHCPADVERTISE packets aren't seen with a network sniffer. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Infinite(?) RTR-ADVERTs being sent out [in Ubuntu NetworkManager testuite]
Hi there,
Back at the desk now. All I can do are naive things, so here's some of
those (inline):
On Fri, Dec 21, 2018 at 10:42:10PM +, Iain Lane wrote:
> Thanks Simon. I'm more or less offline for the holidays from now on, but
> I did test this and it didn't resolve the problem, I'm sorry to say.
>
> On Thu, Dec 20, 2018 at 11:36:46PM +, Simon Kelley wrote:
> > /* First time found, do fast RA. */
> > if (template->if_index != if_index ||
> > !IN6_ARE_ADDR_EQUAL(&template->local6, local))
I added some logging (inside the block, but *before* the new code to
update template->{if_index,local6}) to print out which condition was
failing to cause us to keep entering this loop. It's the second part
(!IN6_ARE_ADDR_EQUAL(...)). Short excerpt at the bottom¹.
Not sure if that output teaches you anything.
I looked at what ra_start_unsolicited() was doing, to see if I could add
an extra condition to prevent entering the branch multiple times for the
same context. This² works for the NetworkManager, but I don't know if
it's a sensible approach.
> > {
> > + template->if_index = if_index;
> > + template->local6 = *local;
> > ra_start_unsolicited(param->now, template);
> > param->newone = 1;
> > }
> > -
> > - template->if_index = if_index;
> > - template->local6 = *local;
(Don't you need to keep doing this for the pre-existing case? Done that in my ²
below.)
Thanks!
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
¹ Jan 7 11:58:40 dnsmasq-dhcp[2867]: RTR-ADVERT(veth42) 2600::
Jan 7 11:58:40 dnsmasq[2867]: Doing the bad thing: template->if_index !=
if_index? no, !IN6_ARE_ADDR_EQUAL(&template->local6, local)? yes
(2600:::::::0001 !=
2600::::2c9a:36ff:fea9:bc93)
Jan 7 11:58:40 dnsmasq[2867]: Doing the bad thing: template->if_index !=
if_index? no, !IN6_ARE_ADDR_EQUAL(&template->local6, local)? yes
(2600::::2c9a:36ff:fea9:bc93 !=
2600:::::::0001)
Jan 7 11:58:40 dnsmasq-dhcp[2867]: RTR-ADVERT(veth42) 2600::
Jan 7 11:58:40 dnsmasq[2867]: Doing the bad thing: template->if_index !=
if_index? no, !IN6_ARE_ADDR_EQUAL(&template->local6, local)? yes
(2600:::::::0001 !=
2600::::2c9a:36ff:fea9:bc93)
Jan 7 11:58:40 dnsmasq[2867]: Doing the bad thing: template->if_index !=
if_index? no, !IN6_ARE_ADDR_EQUAL(&template->local6, local)? yes
(2600::::2c9a:36ff:fea9:bc93 !=
2600:::::::0001)
Jan 7 11:58:40 dnsmasq-dhcp[2867]: RTR-ADVERT(veth42) 2600::
Jan 7 11:58:40 dnsmasq[2867]: Doing the bad thing: template->if_index !=
if_index? no, !IN6_ARE_ADDR_EQUAL(&template->local6, local)? yes
(2600:::::::0001 !=
2600::::2c9a:36ff:fea9:bc93)
Jan 7 11:58:40 dnsmasq[2867]: Doing the bad thing: template->if_index !=
if_index? no, !IN6_ARE_ADDR_EQUAL(&template->local6, local)? yes
(2600::::2c9a:36ff:fea9:bc93 !=
2600:::::::0001)
²
diff --git a/src/dhcp6.c b/src/dhcp6.c
index 56b2532..d8bbf28 100644
--- a/src/dhcp6.c
+++ b/src/dhcp6.c
@@ -655,14 +655,18 @@ static int construct_worker(struct in6_addr *local, int
prefix,
is_same_net6(local, &template->end6, template->prefix))
{
/* First time found, do fast RA. */
- if (template->if_index != if_index ||
!IN6_ARE_ADDR_EQUAL(&template->local6, local))
+ if ((template->if_index != if_index ||
!IN6_ARE_ADDR_EQUAL(&template->local6, local)) &&
template->ra_short_period_start == 0)
{
+ template->if_index = if_index;
+ template->local6 = *local;
ra_start_unsolicited(param->now, template);
param->newone = 1;
}
-
- template->if_index = if_index;
- template->local6 = *local;
+ else
+{
+ template->if_index = if_index;
+ template->local6 = *local;
+}
}
}
signature.asc
Description: PGP signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
