Re: [Dnsmasq-discuss] clients of DHCPv6 with constructed IPv6 address range are not notified on address range change
On 18/09/18 23:03, line wrap clean up wrote: > On Tue, Sep 18, 2018 at 11:13:27PM +0200, Andrey Vakhitov wrote: > Hi Simon, > >>> I've set it up as you suggested, initially name resolution seems >>> to work fine. But after some days of operation (and some nightly >>> reconnects) dnsmasq seems to loose associated IPv6 adresses: DNS >>> request reports only IPv6 address assigned via DHCP. The SLAAC-based >>> IPv6 addresses on hosts are present and correct. How can I investigate >>> and fix this issue? > >> Look in the log for lines that look like >> >> DHCPv4-derived IPv6 names on >> >> which should occur after a reconnect with a different address which >> causes new DHCP address ranges to be constructed. >> >> After that happens, dnsmasq will take a guess at the IPv6 addresses >> that hosts will assign themselves, based on the network address and >> the MAC address of the host (transformed into EUI-64) It then starts >> to ping those addresses, and when it gets a reply, it will log >> >> SLAAC_CONFIRM(interface) >> >> and start using the address/name in the DNS. >> >> Once confirmed, the addresses remain valid until the DHCPv4 lease it's >> based on expires or goes though init-reboot state or the MAC address >> or interface it's accessible by changes. >> >> The only other thing that will delete these addresses in a new address >> appearing and a new dhcp range being created, hence it's interesting >> to look at what happens in the logs after each of those events. > > Strange thing: sometimes after reconnect I can observe expected behaviour > (like you described it, see log 1), sometimes not (SLAAC-CONFIRM is missing, > see log 2) > Is it possible that those hosts are sometimes down or disconnected? FWIW the strategy in the code is to continue trying to ping putative addresses more-or-less forever, with increasing backoff, _except_ when a call to sendto() returns EHOSTUNREACH (no route to host) which causes the code to give up. I confess I have no idea why it's like that, and the git commit messages don't really give much clue. Even more annoying, the original code logged when giving up, but that was subsequently removed, with equally unsatisfactory commits. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] clients of DHCPv6 with constructed IPv6 address range are not notified on address range change
On 18/09/18 23:03, line wrap clean up wrote: > Strange thing: sometimes after reconnect I can observe expected behaviour > (like you described it, see log 1), sometimes not (SLAAC-CONFIRM is missing, > see log 2) > > -- log1 > Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on > 2001:16b8:2284:f5fc::, constructed for lan0 > Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on > 2001:16b8:2284:f5fc::, constructed for lan0 > Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: router advertisement on > 2001:16b8:2284:f5fc::, constructed for lan0 > Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on > 2001:16b8:2284:f5fd::, constructed for dmz0 > Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on > 2001:16b8:2284:f5fd::, constructed for dmz0 > Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: router advertisement on > 2001:16b8:2284:f5fd::, constructed for dmz0 > Sep 17 20:22:45 rtr dnsmasq[7855]: reading /etc/dnsmasq-resolv.conf > -- log2 > Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on > 2001:16b8:22c4:83fc::, constructed for lan0 > Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on > 2001:16b8:22c4:83fc::, constructed for lan0 > Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: router advertisement on > 2001:16b8:22c4:83fc::, constructed for lan0 > Sep 18 04:35:20 rtr dhcpcd[15081]: lan0: waiting for DHCPv6 DAD to complete > Sep 18 04:35:20 rtr dhcpcd[15081]: dmz0: adding address > 2001:16b8:22c4:83fd::1/64 > Sep 18 04:35:20 rtr dhcpcd[15081]: dmz0: pltime 3600 seconds, vltime 7200 > seconds > Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on > 2001:16b8:22c4:83fd::, constructed for dmz0 > Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on > 2001:16b8:22c4:83fd::, constructed for dmz0 > Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: router advertisement on > 2001:16b8:22c4:83fd::, constructed for dmz0 > Sep 18 04:35:20 rtr dhcpcd[15081]: dmz0: waiting for DHCPv6 DAD to complete > Sep 18 04:35:20 rtr dhcpcd[15081]: lan0: adding route to > 2001:16b8:22c4:83fc::/64 > Sep 18 04:35:20 rtr dhcpcd[15081]: dmz0: adding route to > 2001:16b8:22c4:83fd::/64 > Sep 18 04:35:20 rtr dhcpcd[15081]: wan0: executing > `/usr/lib/dhcpcd/dhcpcd-run-hooks' BOUND6 > Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) > 00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e > Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0) > 00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18 > Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) > 00:02:00:00:ab:11:ee:62:d8:4d:ca:9f:9d:d5 > Sep 18 04:35:20 rtr dhcpcd[15081]: wan0: Router Advertisement DAD completed > Sep 18 04:35:20 rtr dhcpcd[15081]: wan0: executing > `/usr/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT > Sep 18 04:35:21 rtr ddclient[1597]: SUCCESS: updating rtrhomevak.spdns.de: > good: IP address set to 2001:16b8:22c4:8300> > Sep 18 04:35:21 rtr dhcpcd[15081]: dmz0: DHCPv6 DAD completed > Sep 18 04:35:21 rtr dhcpcd[15081]: dmz0: executing > `/usr/lib/dhcpcd/dhcpcd-run-hooks' DELEGATED6 > Sep 18 04:35:21 rtr dhcpcd[15081]: lan0: DHCPv6 DAD completed > Sep 18 04:35:21 rtr dhcpcd[15081]: lan0: executing > `/usr/lib/dhcpcd/dhcpcd-run-hooks' DELEGATED6 > Sep 18 04:35:29 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:22c4:83fc:: If you look, lots of things are different between the two logs. In the second one, dhcpcd is doing routing table changes, for instance. That could explain why dnsmasq gives up trying to confirm SLAAC addresses because it gets transient "no route to host" returns. (see previous reply to make sense of this.) Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Duplicate IP detection with fixed IP
On 18/09/18 16:59, Bernard CLABOTS wrote:
> Hi all,
> I have been trying to replicate an issue of IP conflict on Open-WRT,
> the issue is randomly seen, and I expect in real life, it is related to
> a de-sync of the lease data base with the actual situation (in case a
> switch is between the client and the server and the server is rebooted
> e.g., so that the client acts as though it would have a fixed IP.
> Reported as seen as well when moving a client from one setup to another
> setup where the IP that it used to receive is used on the LAN).
>
> I tested with 2 different versions of dnsmasq (2.78 and 2.79).
>
> I use Scapy to forge DHCP Requests (see further).
>
> Setup:
> I have a laptop with a fixed IP inside the range of the DHCP
> (192.168.1.0/26). I then forge a Request of that IP using scapy and I
> cannot explain the behavior:
> 1. I see no ARP whatsoever to the requested IP when DNSMasq handles the
> request.
> 2. When I request the fixed IP for a client with a random MAC, I
> instantly receive an ACK, then I see some unanswered ARP requests
> (*after*) as to "who has [IP just assigned]? Tell 192.168.1.1" where
> 192.168.1.1 is the DHCP server IP.
>
> I end up in a situation where the dhcp.leases contains the fake MAC
> associated to the lease, while the ARP table contains the MAC of the
> fixed IP laptop (probably because I'm not sending any IP packet where
> the IP is associated to the fake MAC, so the switch cannot learn it).
>
> I have observed that Windows 10 has a mechanism to prevent conflicts
> where, whenever a fixed IP is used/configured, after the link is up an
> ARP probe is sent with its own IP. In case it gets answered, the client
> keeps silent and start using a link local IPv4 (169). Yet I have
> tested with a very old laptop running Windows 3.1 and I can replicate
> the issue.
> But basically, it is puzzling that the device is ARPing *after* the DHCP
> distributed the IP.
>
> *The all issue seems to boil down to:* why does DNSMasq not check if the
> IP is free before assigning it?
> I thought that unless option "-5" or "--no-ping" was set, DNSMasq would
> always ping once to the assigned IP *before* assignment (I controlled in
> the code and see that actually, there is a mechanism to store the
> positive identification as well as to blacklist IP's in case a client is
> constantly coming back).
> The only ARP I see in this case is *after* the IP is assigned. How come
> DNSMasq is not trying to ping before assignment? Is there an option to
> force this behavior (from the code I guess not)? Is DNSMasq also somehow
> relying on the ARP table and flags that are set on reachability? or
> solely on the _non_ answer to ping?
>
> Thanks a lot for your assistance.
>
> Regards,
> Bernard
>
> Scapy forged packet (I know the source MAC does not match the client
> MAC, but I deem this good enough for testing, AFAIK it is a legal packet):
> dhcp_request = Ether(dst='ff:ff:ff:ff:ff:ff')/IP(src='0.0.0.0',
> dst='255.255.255.255')/UDP(dport=67,
> sport=68)/BOOTP(xid=RandInt())/DHCP(options=[('message-type',
> 'request'),("server_id","192.168.1.1"),("requested_addr","192.168.1.34"),("hostname","Scapy"),
> 'end'])
>
> dhcp_ack = srp1(dhcp_request, iface='enp9s0')
>
There are two reasons why you are not seeing ARP requests from dnsmasq.
1) DHCP servers (as opposed to clients) use ICMP echo-request AKA ping,
and not ARP to check for address-in-use.
2) Dnsmasq does the ping-check during the DHCPDISCOVER/DHCPOFFER phase
of the protocol, not the DHCPREQUEST/DHCPACK phase.
It's possible for a DHCPREQUEST to create a new entry in the leases
file, but only if the dhcp-authoritative flag is set. In that case when
dnsmasq sees what looks like a lease renewal for a lease it doesn't know
about, it assumes the lease database was lost, and does the renewal
anyway, recreating the lease entry as it does. Without
dhcp-authoritative, it follows the RFC-approved route of replying with
DHCPNAK, which forces the client to go through the whole
DHCPDISCOVER/DHCPOFFER phase, and that does the ping-check.
I don't think it would be possible to make this hack any more safe by
doing the ping-check before re-creating the lease. The whole premise is
that the client attempting to renew is already configured, but the
server lost track of it. So doing a ping-check would expect to get a
reply from the already-configured client.
Cheers,
Simon.
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Seg. fault in cache.c after commt b6f926fb
On 18/09/18 11:28, Kristian Evensen wrote:
> Hello,
>
> I recently updated one of my x86-based OpenWRT-routers to the latest
> nightly, which bumped dnsmasq to 2.80test6. After the update, I see
> that dnsmasq sometimes enters a crash loop. The crash occurs right
> startup (SIGSEV), and the backtrace, looks as follows:
>
> 0x00406a78 in make_non_terminals
> (source=source@entry=0x77ffefa0) at cache.c:1437
> 1437 cache.c: No such file or directory.
> (gdb) bt
> #0 0x00406a78 in make_non_terminals
> (source=source@entry=0x77ffefa0) at cache.c:1437
> #1 0x00407192 in add_hosts_entry (cache=0x77ffefa0,
> addr=0x7fffea28, addrlen=4, index=2, rhash=,
> hashsz=) at cache.c:911
> #2 0x004074e1 in read_hostsfile
> (filename=filename@entry=0x425a8a "/etc/hosts", index=index@entry=2,
> cache_size=cache_size@entry=150, rhash=0x635020,
> hashsz=hashsz@entry=641) at cache.c:1040
> #3 0x00407810 in cache_reload () at cache.c:1185
> #4 0x00418037 in clear_cache_and_reload
> (now=now@entry=1537265437) at dnsmasq.c:1547
> #5 0x00405ec3 in async_event (now=1537265437, pipe=15) at
> dnsmasq.c:1310
> #6 main (argc=, argv=) at dnsmasq.c:1077
>
> My current work-around is to check if crecp is NULL and then return
> from make_non_terminals(). However, I don't know the code well enough
> to know if this change will break anything else (though everything
> seems to work fine).
>
> There is nothing special with my hosts file, it looks as follows:
>
> 127.0.0.1 localhost
>
> ::1 localhost ip6-localhost ip6-loopback
> ff02::1 ip6-allnodes
> ff02::2 ip6-allrouters
> 192.168.5.1 myrouter.lan
>
> If checking for NULL is acceptable, I will be more than happy to send
> my patch. If not, I wonder if anyone has any hints on how to proceed
> to solve this issue?
>
Thanks for the report. The obvious explanation is that whine_malloc() is
returning NULL, and the code should handle that. whine_malloc only
returns NULL if the system cannot allocate any more memory, which is
possible, but unlikely. Is your router very short on memory?
whine_malloc() is just a wrapper around malloc that logs an error if the
malloc fails (hence the name) Are you seeing messages like
failed to allocate %d bytes
just before the crashes? That would make me more comfortable that we
understand the problem. I think the best solution is to wrap all of
*crecp = *source;
crecp->flags &= ~(F_IPV4 | F_IPV6 | F_CNAME | F_DNSKEY | F_DS |
F_REVERSE);
crecp->flags |= F_NAMEP;
crecp->name.namep = name;
cache_hash(crecp);
with
if (crecp)
{
}
and I'll commit that to the git repo now.
Cheers,
Simon
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] clients of DHCPv6 with constructed IPv6 address range are not notified on address range change
On Tue, Sep 18, 2018 at 11:13:27PM +0200, Andrey Vakhitov wrote: Hi Simon, >> I've set it up as you suggested, initially name resolution seems >> to work fine. But after some days of operation (and some nightly >> reconnects) dnsmasq seems to loose associated IPv6 adresses: DNS >> request reports only IPv6 address assigned via DHCP. The SLAAC-based >> IPv6 addresses on hosts are present and correct. How can I investigate >> and fix this issue? > Look in the log for lines that look like > > DHCPv4-derived IPv6 names on > > which should occur after a reconnect with a different address which > causes new DHCP address ranges to be constructed. > > After that happens, dnsmasq will take a guess at the IPv6 addresses > that hosts will assign themselves, based on the network address and > the MAC address of the host (transformed into EUI-64) It then starts > to ping those addresses, and when it gets a reply, it will log > > SLAAC_CONFIRM(interface) > > and start using the address/name in the DNS. > > Once confirmed, the addresses remain valid until the DHCPv4 lease it's > based on expires or goes though init-reboot state or the MAC address > or interface it's accessible by changes. > > The only other thing that will delete these addresses in a new address > appearing and a new dhcp range being created, hence it's interesting > to look at what happens in the logs after each of those events. Strange thing: sometimes after reconnect I can observe expected behaviour (like you described it, see log 1), sometimes not (SLAAC-CONFIRM is missing, see log 2) -- log1 Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on 2001:16b8:2284:f5fc::, constructed for lan0 Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on 2001:16b8:2284:f5fc::, constructed for lan0 Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: router advertisement on 2001:16b8:2284:f5fc::, constructed for lan0 Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on 2001:16b8:2284:f5fd::, constructed for dmz0 Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on 2001:16b8:2284:f5fd::, constructed for dmz0 Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: router advertisement on 2001:16b8:2284:f5fd::, constructed for dmz0 Sep 17 20:22:45 rtr dnsmasq[7855]: reading /etc/dnsmasq-resolv.conf Sep 17 20:22:45 rtr dnsmasq[7855]: using local addresses only for domain homenet Sep 17 20:22:45 rtr dnsmasq[7855]: using nameserver 8.8.4.4#53 Sep 17 20:22:45 rtr dnsmasq[7855]: using nameserver 8.8.8.8#53 Sep 17 20:22:45 rtr dnsmasq[7855]: ignoring nameserver fd00::7eff:4dff:fe03:2c18 - cannot make/bind socket: Address alr> Sep 17 20:22:45 rtr dnsmasq[7855]: setting upstream servers from DBus Sep 17 20:22:45 rtr dnsmasq[7855]: using local addresses only for domain homenet Sep 17 20:22:45 rtr dnsmasq[7855]: using nameserver 8.8.4.4#53 Sep 17 20:22:45 rtr dnsmasq[7855]: using nameserver 8.8.8.8#53 Sep 17 20:22:47 rtr dhcpcd[15081]: lan0: DHCPv6 DAD completed Sep 17 20:22:47 rtr dhcpcd[15081]: lan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' DELEGATED6 Sep 17 20:22:47 rtr dhcpcd[15081]: dmz0: DHCPv6 DAD completed Sep 17 20:22:47 rtr dhcpcd[15081]: dmz0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' DELEGATED6 Sep 17 20:22:49 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0) 00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18 Sep 17 20:22:55 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e Sep 17 20:22:56 rtr dhcpcd[15081]: wan0: fe80::7eff:4dff:fe03:2c18 is unreachable, expiring it Sep 17 20:22:56 rtr dhcpcd[15081]: wan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT Sep 17 20:22:58 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:2284:f5fc:: Sep 17 20:22:58 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:2250:65f8:: old prefix Sep 17 20:22:58 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e Sep 17 20:22:59 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2284:f5fd:: Sep 17 20:22:59 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2250:65f9:: old prefix Sep 17 20:23:03 rtr dnsmasq-dhcp[7855]: SLAAC-CONFIRM(lan0) 2001:16b8:2284:f5fc:d250:99ff:fe84:93d0 vdrmain Sep 17 20:23:03 rtr dnsmasq-dhcp[7855]: SLAAC-CONFIRM(dmz0) 2001:16b8:2284:f5fd:5054:ff:fe12:3456 dmzhost Sep 17 20:23:03 rtr dhcpcd[15081]: wan0: fe80::7eff:4dff:fe03:2c18 is reachable again Sep 17 20:23:03 rtr dhcpcd[15081]: wan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT Sep 17 20:23:05 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2284:f5fd:: Sep 17 20:23:05 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2250:65f9:: old prefix Sep 17 20:23:05 rtr dnsmasq-dhcp[7855]: SLAAC-CONFIRM(lan0) 2001:16b8:2284:f5fc:222:4dff:fea7:dcdc vdrkit Sep 17 20:23:05 rtr dnsmasq-dhcp[7855]: SLAAC-CONFIRM(lan0) 2001:16b8:2284:f5fc:fca1:42ff:fed2:a2bd xenhost - -- log2 Sep 18 04:35:20 rtr
Re: [Dnsmasq-discuss] WG: clients of DHCPv6 with constructed IPv6 address range are not notified on address range change
Hi Simon, >> I've set it up as you suggested, initially name resolution seems to >> work fine. But after some days of operation (and some nightly >> reconnects) dnsmasq seems to loose associated IPv6 adresses: DNS >> request reports only IPv6 address assigned via DHCP. The SLAAC-based >> IPv6 addresses on hosts are present and correct. How can I investigate and fix this issue? > Look in the log for lines that look like > > DHCPv4-derived IPv6 names on > > which should occur after a reconnect with a different address which causes new DHCP address ranges to be constructed. > > After that happens, dnsmasq will take a guess at the IPv6 addresses that hosts will assign themselves, > based on the network address and the MAC address of the host (transformed into EUI-64) > It then starts to ping those addresses, and when it gets a reply, it will log > > SLAAC_CONFIRM(interface) > > and start using the address/name in the DNS. > > Once confirmed, the addresses remain valid until the DHCPv4 lease it's based on expires or goes > though init-reboot state or the MAC address or interface it's accessible by changes. > > The only other thing that will delete these addresses in a new address appearing and a new dhcp > range being created, hence it's interesting to look at what happens in the logs after each of those events. Strange thing: sometimes after reconnect I can observe expected behaviour (like you described it, see log 1), sometimes not (SLAAC-CONFIRM is missing, see log 2) -- log1 Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on 2001:16b8:2284:f5fc::, constructed for lan0 Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on 2001:16b8:2284:f5fc::, constructed for lan0 Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: router advertisement on 2001:16b8:2284:f5fc::, constructed for lan0 Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on 2001:16b8:2284:f5fd::, constructed for dmz0 Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on 2001:16b8:2284:f5fd::, constructed for dmz0 Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: router advertisement on 2001:16b8:2284:f5fd::, constructed for dmz0 Sep 17 20:22:45 rtr dnsmasq[7855]: reading /etc/dnsmasq-resolv.conf Sep 17 20:22:45 rtr dnsmasq[7855]: using local addresses only for domain homenet Sep 17 20:22:45 rtr dnsmasq[7855]: using nameserver 8.8.4.4#53 Sep 17 20:22:45 rtr dnsmasq[7855]: using nameserver 8.8.8.8#53 Sep 17 20:22:45 rtr dnsmasq[7855]: ignoring nameserver fd00::7eff:4dff:fe03:2c18 - cannot make/bind socket: Address alr> Sep 17 20:22:45 rtr dnsmasq[7855]: setting upstream servers from DBus Sep 17 20:22:45 rtr dnsmasq[7855]: using local addresses only for domain homenet Sep 17 20:22:45 rtr dnsmasq[7855]: using nameserver 8.8.4.4#53 Sep 17 20:22:45 rtr dnsmasq[7855]: using nameserver 8.8.8.8#53 Sep 17 20:22:47 rtr dhcpcd[15081]: lan0: DHCPv6 DAD completed Sep 17 20:22:47 rtr dhcpcd[15081]: lan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' DELEGATED6 Sep 17 20:22:47 rtr dhcpcd[15081]: dmz0: DHCPv6 DAD completed Sep 17 20:22:47 rtr dhcpcd[15081]: dmz0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' DELEGATED6 Sep 17 20:22:49 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0) 00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18 Sep 17 20:22:55 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e Sep 17 20:22:56 rtr dhcpcd[15081]: wan0: fe80::7eff:4dff:fe03:2c18 is unreachable, expiring it Sep 17 20:22:56 rtr dhcpcd[15081]: wan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT Sep 17 20:22:58 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:2284:f5fc:: Sep 17 20:22:58 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:2250:65f8:: old prefix Sep 17 20:22:58 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e Sep 17 20:22:59 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2284:f5fd:: Sep 17 20:22:59 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2250:65f9:: old prefix Sep 17 20:23:03 rtr dnsmasq-dhcp[7855]: SLAAC-CONFIRM(lan0) 2001:16b8:2284:f5fc:d250:99ff:fe84:93d0 vdrmain Sep 17 20:23:03 rtr dnsmasq-dhcp[7855]: SLAAC-CONFIRM(dmz0) 2001:16b8:2284:f5fd:5054:ff:fe12:3456 dmzhost Sep 17 20:23:03 rtr dhcpcd[15081]: wan0: fe80::7eff:4dff:fe03:2c18 is reachable again Sep 17 20:23:03 rtr dhcpcd[15081]: wan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT Sep 17 20:23:05 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2284:f5fd:: Sep 17 20:23:05 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2250:65f9:: old prefix Sep 17 20:23:05 rtr dnsmasq-dhcp[7855]: SLAAC-CONFIRM(lan0) 2001:16b8:2284:f5fc:222:4dff:fea7:dcdc vdrkit Sep 17 20:23:05 rtr dnsmasq-dhcp[7855]: SLAAC-CONFIRM(lan0) 2001:16b8:2284:f5fc:fca1:42ff:fed2:a2bd xenhost - -- log2 Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on 2001:16b8:22c4:83fc::, constructed for lan0 Sep 18
[Dnsmasq-discuss] Duplicate IP detection with fixed IP
Hi all, I have been trying to replicate an issue of IP conflict on Open-WRT,
the issue is randomly seen, and I expect in real life, it is related to a
de-sync of the lease data base with the actual situation (in case a switch is
between the client and the server and the server is rebooted e.g., so that the
client acts as though it would have a fixed IP. Reported as seen as well when
moving a client from one setup to another setup where the IP that it used to
receive is used on the LAN).
I tested with 2 different versions of dnsmasq (2.78 and 2.79).
I use Scapy to forge DHCP Requests (see further).
Setup:I have a laptop with a fixed IP inside the range of the DHCP
(192.168.1.0/26). I then forge a Request of that IP using scapy and I cannot
explain the behavior:1. I see no ARP whatsoever to the requested IP when
DNSMasq handles the request.2. When I request the fixed IP for a client with a
random MAC, I instantly receive an ACK, then I see some unanswered ARP requests
(*after*) as to "who has [IP just assigned]? Tell 192.168.1.1" where
192.168.1.1 is the DHCP server IP.
I end up in a situation where the dhcp.leases contains the fake MAC associated
to the lease, while the ARP table contains the MAC of the fixed IP laptop
(probably because I'm not sending any IP packet where the IP is associated to
the fake MAC, so the switch cannot learn it).
I have observed that Windows 10 has a mechanism to prevent conflicts where,
whenever a fixed IP is used/configured, after the link is up an ARP probe is
sent with its own IP. In case it gets answered, the client keeps silent and
start using a link local IPv4 (169). Yet I have tested with a very old
laptop running Windows 3.1 and I can replicate the issue.But basically, it is
puzzling that the device is ARPing *after* the DHCP distributed the IP.
*The all issue seems to boil down to:* why does DNSMasq not check if the IP is
free before assigning it?
I thought that unless option "-5" or "--no-ping" was set, DNSMasq would always
ping once to the assigned IP *before* assignment (I controlled in the code and
see that actually, there is a mechanism to store the positive identification as
well as to blacklist IP's in case a client is constantly coming back).The only
ARP I see in this case is *after* the IP is assigned. How come DNSMasq is not
trying to ping before assignment? Is there an option to force this behavior
(from the code I guess not)? Is DNSMasq also somehow relying on the ARP table
and flags that are set on reachability? or solely on the _non_ answer to ping?
Thanks a lot for your assistance.
Regards,Bernard
Scapy forged packet (I know the source MAC does not match the client MAC, but I
deem this good enough for testing, AFAIK it is a legal packet):dhcp_request =
Ether(dst='ff:ff:ff:ff:ff:ff')/IP(src='0.0.0.0',
dst='255.255.255.255')/UDP(dport=67,
sport=68)/BOOTP(xid=RandInt())/DHCP(options=[('message-type',
'request'),("server_id","192.168.1.1"),("requested_addr","192.168.1.34"),("hostname","Scapy"),
'end'])
dhcp_ack = srp1(dhcp_request, iface='enp9s0')___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Seg. fault in cache.c after commt b6f926fb
Hello, I recently updated one of my x86-based OpenWRT-routers to the latest nightly, which bumped dnsmasq to 2.80test6. After the update, I see that dnsmasq sometimes enters a crash loop. The crash occurs right startup (SIGSEV), and the backtrace, looks as follows: 0x00406a78 in make_non_terminals (source=source@entry=0x77ffefa0) at cache.c:1437 1437 cache.c: No such file or directory. (gdb) bt #0 0x00406a78 in make_non_terminals (source=source@entry=0x77ffefa0) at cache.c:1437 #1 0x00407192 in add_hosts_entry (cache=0x77ffefa0, addr=0x7fffea28, addrlen=4, index=2, rhash=, hashsz=) at cache.c:911 #2 0x004074e1 in read_hostsfile (filename=filename@entry=0x425a8a "/etc/hosts", index=index@entry=2, cache_size=cache_size@entry=150, rhash=0x635020, hashsz=hashsz@entry=641) at cache.c:1040 #3 0x00407810 in cache_reload () at cache.c:1185 #4 0x00418037 in clear_cache_and_reload (now=now@entry=1537265437) at dnsmasq.c:1547 #5 0x00405ec3 in async_event (now=1537265437, pipe=15) at dnsmasq.c:1310 #6 main (argc=, argv=) at dnsmasq.c:1077 My current work-around is to check if crecp is NULL and then return from make_non_terminals(). However, I don't know the code well enough to know if this change will break anything else (though everything seems to work fine). There is nothing special with my hosts file, it looks as follows: 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters 192.168.5.1 myrouter.lan If checking for NULL is acceptable, I will be more than happy to send my patch. If not, I wonder if anyone has any hints on how to proceed to solve this issue? BR, Kristian ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
