On Fri, May 05, 2023 at 11:02:49PM +0200, Johan Vromans wrote:
On Fri, 5 May 2023 22:13:24 +0200, Geert Stappers wrote:
On Fri, May 05, 2023 at 08:47:14PM +0200, Johan Vromans wrote:
... The system is a Raspberry Pi running Raspbian.
It is DHCP/DNS server (dnsmasq) for my LAN.
As said earlier, all information [for this type of system] points towards
setting the static address in /etc/dhcpcd.conf and apparently dhcpcd
handles this situation. At least, this has been working for several years
Let's try to understand why it was working.
without problems. Until now, that is, thanks to some buggy(?) IoT devices.
It is too early to blame the IoT devices.
I don't blame them... They merely revealed there's something fishy.
Let's try to find out what is going on in the dhcpcd-dnsmasq-combo.
I now have the static address setting in /etc/network/interfaces and
disabled dhcpcd so everything is fine again, and hopefully more robust.
Thanks all for your valuable feedback that helped me to find the problem
and its solution.
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2023q2/017057.html
has:
}
} On second thought:
} The problem could be how dhcpcd and dnsmasq work together.
}
} Or more likely:
} The problem could be how dhcpcd and dnsmasq are configured.
}
}
} So far we have seen (parts of) dhcpcd configuration
} and no dnsmasq configuration at al.
}
That text in other words:
Share with the dnsmasq mailinglist (archive) the dnsmasq configuration.
The original problem is most likely solvable with the original dhcpcd
configuration in-place.
Strange that you keep pointing towards dnsmasq,
dnsmasq *plus* dhcpcd
while Geoff already clearly
explained that it is not dnsmasq, but dhcpcd that drops the address.
Text from the email Geoff did reply to:
}
} ... a number of IoT devices. Occasionally, when they try to set up the
} DHCP lease, some of them send wrong packets. The device effectively claims
} the IP address of the DHCP server. From the system log:
}
} May 4 05:39:59 srv1 dhcpcd[449]: eth0: hardware address
} xx:xx:xx:xx:xx::ce claims 192.168.1.10
}
} where 192.168.1.10 is the address of the DHCP server.
}
} If a second package arrives within 10 seconds,
}
} May 4 05:40:08 srv1 dhcpcd[449]: eth0: hardware address
} xx:xx:xx:xx:xx::e7 claims 192.168.1.10
}
} dnsmasq shuts down the network connection
}
} dhcpcd[449]: eth0: 10 second defence failed for 192.168.1.10
} dnsmasq-dhcp[24169]: DHCPRELEASE(eth0) 192.168.1.96 xx:xx:xx:xx:xx::e7
} avahi-daemon[373]: Withdrawing address record for 192.168.1.10 on eth0.
} avahi-daemon[373]: Leaving mDNS multicast group on interface eth0.IPv4 with
} address 192.168.1.10. avahi-daemon[373]: Interface eth0.IPv4 no longer
} relevant for mDNS. dhcpcd[449]: eth0: deleting route to 192.168.1.0/24
} dhcpcd[449]: eth0: deleting default route via 192.168.1.1
}
} and slowly the LAN collapses.
Note the
} xx:xx:xx:xx:xx::ce claims 192.168.1.10
} xx:xx:xx:xx:xx::e7 claims 192.168.1.10
Two different MAC addresses wanting IP address 192.168.1.10.
But if it makes you happy,
[1]
I've attached the dnsmasq configs.
I left out the hosts part, it's just a long series of
xx:xx:xx:xx:xx:xx,192.168.1.nnn,hostname.squirrel.nl,24h
Let's assume there is
} xx:xx:xx:xx:xx:aa,192.168.1.10,dnsmasq.squirrel.nl,24h
So some kind of a claim on .10 for DNS-DHCP-server dnsmasq.
# dnsmasq_conf for squirrel.nl -- generated Mon May 1 10:29:58 2023
# Do not forward simple name queries.
domain-needed
# Do not forward reverse lku for private domains.
bogus-priv
# Filter extraneous DNS requests by Windows.
filterwin2k
# Do not use /etc/resolv.conf.
no-resolv
no-poll
# FQDN.
expand-hosts
domain=squirrel.nl
# Do not forward to external servers.
local=/squirrel.nl/
# External name servers.
server=1.1.1.1
server=1.0.0.1
# Only use our own list of hosts.
no-hosts
addn-hosts=/etc/local/dnsmasq_hosts
# TXT entries in separate file
# conf-file=/etc/local/dnsmasq_txt
# Additional configs.
conf-dir=/etc/local/dnsmasq.d,*.conf
# Logging.
#log-queries
# DHCP settings for squirrel.nl -- generated Mon May 1 10:29:58 2023
dhcp-authoritative
# Location of leases.
#dhcp-leasefile=/var/lib/misc/dnsmasq.leases
# Local name servers.
dhcp-option=6,192.168.1.10,192.168.1.16
# Default router.
dhcp-option=option:router,192.168.1.1
# Addresses for dynamic hosts.
dhcp-range=192.168.1.33,192.168.1.50,6h
Now we known that .10 is *outside* the DHCP range.
# NTP host(s).
dhcp-option=option:ntp-server,192.168.1.10
# PXE boot image.
dhcp-boot=pxelinux.0,pxeboot.squirrel.nl,192.168.1.16
# DHCP host names in separate file.
dhcp-hostsfile=/etc/local/dnsmasq_dhcp
# Logging.
#log-dhcp
# TFTP settings for squirrel.nl -- generated Mon May 1 10:29:58 2023
# TFTP server for PXE boot.
enable-tftp
tftp-root=/tftpboot
Qouting another email from Johan:
} I have this in my /etc/dhcpcd.conf:
}
} interface eth0
} static ip_address=192.168.1.10/24
} static routers=192.168.1.1
My stab on why it "worked":
* server with dhcpcd and dnsmasq is started
* dhcpcd does DHCP client thing
* No answer, the static configuration of dhcpcd is activated
* dnsmasq is started
* ignorance is bliss
Yet unknown:
* The kind of reservation that dnsmasq has for .10
* How to tell dhcpcd "keep 192.168.1.10"
My stab on how it breaks:
* a new DHCP client asks for 192.168.1.10
* dnsmasq unaware that 192.168.1.10 is intended for its self
* dhcpcd not doing a renew (remaining shortly the static config)
* dhcpcd stepping aside, releasing its "static" .10 address
* dnsmasq losing the addres it was using
Preventing the breakage with having a true static IP address for the
dnsmasq server is a good solution. Probably the best from the point of
view from dnsmasq. I don't know if dnsmasq can send DHCPNAK, DHCP Negative
Acknowlegde, when it sees requests for a reservation. It would help
dhcpcd to defence its IP-address.
With some luck is Roy Marples or another person with dhcpcd knowlegde
on this list and can tell how to configure dhcpcd to keep an assigned
IP-address. How to prevent
} dhcpcd[449]: eth0: 10 second defence failed for 192.168.1.10
There is an unknown ascpect on this interesting problem:
Why are the IoT devices asking for 192.168.1.10?
Answer to that question is in providing information on the IoT devices.
Yeah, it might feel odd, but is a good thing to describe the clients
that are supposed to talk to a server.
Idea to help dhcpcd to defend it's address, is moving it to a place
where it wouldn't be under heavy attack. Like moving to 192.168.1.9
At that address it doesn't have to deal with requests for 192.168.1.10
by the IoT devices. My guess is that 192.168.1.10 is some default for
the IoT device. I think it is a good thing to move DNS away from the .10
address that an IoT device likes to claim.
Groeten
Geert Stappers
Foot note
[1] Part of Happyness is knowing what you have.
Knowning how dnsmasq behaves (in corner cases) is joyfull.
Dnsmasq is a server, various clients make it usefull. (As in: There
is no point in having a server when no clients connect to it.)
