Re: [Dnsmasq-discuss] [BUG] RA are sent too fast and slows down the machine
On 21/08/2019 19:59, Petr Mensik wrote: > Hi Simon and Maarten, > > we discovered when playing with NetworkManager-ci [1], that lastest > release is somehow broken. Test running dnsmasq are quite slow on latest > release. > > I have created repeatable started script that reproduces it. Then used > git bisect to find when it was broken. It seems fast sending were > intentional in commit 0a496f059c1e9 [2], but maybe way it affects the > system were underestimated. It is significant for systems that hit such > issue. I think it has to be fixed to slow it down to short time > interval, not endless loop. Reported as Fedora bug [3]. > > 1. https://github.com/NetworkManager/NetworkManager-ci > 2. > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=0a496f059c1e9d75c33cce4c1211d58422ba4f62 > 3. https://bugzilla.redhat.com/show_bug.cgi?id=1739797 > Petr, returning to this after too long away, I've committed what seems like the most sensible fix: http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=515ba97595e60c762c448657f3c0e545c1e365f9 which is different from yours. It only starts fast-RA when the dhcp-range in question has never been used before. This satisfies the original aim of 0a496f059c1e9d75c33cce4c1211d58422ba4f62 but eliminates the possibility of the infinite loop. Does that work for you? Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Please consider clarifying the man page about the tftp service
On Mon, Jan 27, 2020 at 06:44:22PM +0100, Olivier Cailloux wrote: > Le lundi 27 janvier 2020 à 15:58 +, Simon Kelley a écrit : > > This is a laudible aim, the problem is that there's no such thing > > as "which option is required exactly". Netboot is gnarly thicket of > > different standards and different ways of doing things, and depending > > on how you want to do things, and which standards the things you > > are trying to boot support, then you need different options. For > > instance in your case you presumably have another DHCP server on > > the network which is dealing with handing out addresses, and you're > > relying on the never-standardised "proxy DHCP" feature of PXE to do > > be able to do netbooting without touching the configuration of that > > other DHCP server. > > In fact if you use just one DHCP server which can be configured, > > especially if it's running dnsmasq, netbooting is much simpler > > than the way you've done it. A primer on netbooting with examples > > of dnsmasq configurations would be a good thing to have, but it's > > place is not in the dnsmasq man page. > > > I understand that it is no simple matter in my situation (and simpler > in others)to clarify the doc and still support every possible use case. > Still, I have a hunch that it is possible to do better (though it might > be because of me not having thought about some use cases). For example, > is there a reason to run the following command? > sudo /usr/sbin/dnsmasq --port=0 "--dhcp-range=192.168.1.0, proxy" " > --dhcp-boot=pxelinux.0,saucisson" --enable-tftp --log-dhcp > > In my understanding, the --pxe-service switch is required in such a > situation (as you correctly deduced, that is a situation where another > DHCP server is running), or there is some other problem in the command. > If so, dnsmasq should say it. > > But I certainly could be wrong, being no expert in net booting. https://networkboot.org/ > > Cheers > > Thank you for your interest and time. > -- Olivier Groeten Geert Stappers -- Leven en laten leven ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Please consider clarifying the man page about the tftp service
Le lundi 27 janvier 2020 à 15:58 +, Simon Kelley a écrit : > This is a laudible aim, the problem is that there's no such thing as > "which option is required exactly". Netboot is gnarly thicket of > different standards and different ways of doing things, and depending > on > how you want to do things, and which standards the things you are > trying > to boot support, then you need different options. For instance in > your > case you presumably have another DHCP server on the network which is > dealing with handing out addresses, and you're relying on the > never-standardised "proxy DHCP" feature of PXE to do be able to do > netbooting without touching the configuration of that other DHCP > server. > In fact if you use just one DHCP server which can be configured, > especially if it's running dnsmasq, netbooting is much simpler than > the > way you've done it. A primer on netbooting with examples of dnsmasq > configurations would be a good thing to have, but it's place is not > in > the dnsmasq man page. > > I understand that it is no simple matter in my situation (and simpler in others)to clarify the doc and still support every possible use case. Still, I have a hunch that it is possible to do better (though it might be because of me not having thought about some use cases). For example, is there a reason to run the following command? sudo /usr/sbin/dnsmasq --port=0 "--dhcp-range=192.168.1.0, proxy" " --dhcp-boot=pxelinux.0,saucisson" --enable-tftp --log-dhcp In my understanding, the --pxe-service switch is required in such a situation (as you correctly deduced, that is a situation where another DHCP server is running), or there is some other problem in the command. If so, dnsmasq should say it. But I certainly could be wrong, being no expert in net booting. > > Cheers Thank you for your interest and time. -- Olivier > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Please consider clarifying the man page about the tftp service
On 24/01/2020 21:49, Olivier Cailloux wrote: > Dear list, > > I have been happy to use dnsmasq to install debian through network > boot. However, it has taken a lot of trials and errors before I found > the correct command line to use. I’d like to report my experience in > hope that the man page be possibly improved, as the developers see fit. > > It was very unclear to me while reading the man page which options > exactly need to be turned on to enable network boot. I tried the > following commands: > sudo /usr/sbin/dnsmasq --port=0 "--dhcp-range=192.168.1.0, proxy" " > --dhcp-boot=pxelinux.0,saucisson" --enable-tftp --log-dhcp > sudo /usr/sbin/dnsmasq --port=0 "--dhcp-range=192.168.1.0,proxy" " > --dhcp-boot=pxelinux.0" --enable-tftp --log-dhcp --tftp- > root=/home/olivier/netboot > sudo /usr/sbin/dnsmasq --port=0 "--dhcp-range=192.168.1.0,proxy" " > --dhcp-boot=/pxelinux.0" --enable-tftp --log-dhcp --tftp- > root=/home/olivier/netboot --dhcp-no-override > > before I finally found a correct one: > sudo /usr/sbin/dnsmasq --port=0 "--dhcp-range=192.168.1.0,proxy" " > --dhcp-boot=pxelinux.0" --enable-tftp --log-dhcp --tftp- > root=/home/olivier/netboot "--pxe-service=x86PC,Install Linux, > pxelinux" > > (All this took a while because I did not even know the TFTP service was > not activated with my first tries, so I thought the problem lied > somewhere else.) > > The man page says: “If dnsmasq is providing a TFTP service (see -- > enable-tftp ) then only the filename is required here to enable network > booting.” and also reading about the pxe-service option, I thought that > it was unnecessary and was there just to allow for customizing the > string that would display at start (which I thought I do not need). > > Please consider clarifying the man page concerning the relevant options > to state which option is required exactly; and especially, please > consider making dnsmasq tell something in the log file, or (better > IMHO) refuse to start when the options it receives are incoherent. With > the current behavior, it is very hard, when it’s the first time you do > it, to even know that dnsmasq is not configured properly. > This is a laudible aim, the problem is that there's no such thing as "which option is required exactly". Netboot is gnarly thicket of different standards and different ways of doing things, and depending on how you want to do things, and which standards the things you are trying to boot support, then you need different options. For instance in your case you presumably have another DHCP server on the network which is dealing with handing out addresses, and you're relying on the never-standardised "proxy DHCP" feature of PXE to do be able to do netbooting without touching the configuration of that other DHCP server. In fact if you use just one DHCP server which can be configured, especially if it's running dnsmasq, netbooting is much simpler than the way you've done it. A primer on netbooting with examples of dnsmasq configurations would be a good thing to have, but it's place is not in the dnsmasq man page. Cheers Simon ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] how to force dnsmasq to stop ignoring nameserver it thinks is on a local interface
Yes, sorry - that was a typo. Should have been 'is now ignoring' -Original Message- From: wkitt...@gmail.com [mailto:wkitt...@gmail.com] Sent: Saturday, January 25, 2020 9:23 AM To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] how to force dnsmasq to stop ignoring nameserver it thinks is on a local interface On 1/25/20 8:04 AM, Jonathan Knoll wrote: > I run dnsmasq in a kubernetes pod with some forwarding rules that > include some kubernetes service IPs (172.31.*). In a recent > kubernetes update, it seems that kubernetes configures all of those > service addresses as IPVS interfaces in the pod, and I believe dnsmasq > is not ignoring those forwarding rules because it typo? "is not ignoring" or "is now ignoring"?? > believes they are all local interfaces. Is there a way to force > dnsmasq to use the nameservers? -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.thekelleys.org.uk_mailman_listinfo_dnsmasq-2Ddiscuss&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=p0-OZ-Makpysak8_95uldC4NnpiabeIz_6fATzQwXi8&m=2R0_CzGjvNcbSw773xpYvtfcHF3LubGWZS4AWcVPUzU&s=TKlBr7-py3-9u_heaM59GWSWWIQzb7LuvYT9kbhmDVM&e= ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - Multiple reservations for single host
Dear Harald, Am 27.01.20 um 10:05 schrieb Harald Jensås: > On Sun, 2020-01-26 at 20:01 +0100, Oliver Freyermuth wrote: >> I also like this new approach. "Wasting" 4 addresses for one host >> seems to be the only way >> to solve this while conforming to RFCs. >> >> However, there's one issue I can't find a good solution for in this >> scheme - >> how to solve the "DNS problem" if dnsmasq is only used for DHCP, but >> DNS is provided by other means? >> >> The "range reservation", as highlighted, means the final address is >> not well predictable (may depend on hardware, >> other parts of the boot process etc.). >> When dnsmasq is also doing the DNS part, that's not a problem, since >> it will use the final / "most recently leased" address for DNS. >> Does anybody have a good proposal for the case when DHCP is provided >> by dnsmasq but DNS is maintained separately >> (i.e. the "final address" needs to be fixed)? >> >> Cheers, >> Oliver > > I think adding tag support for dhcp-host entries as follow up. > > The idea would be to have a config like this: > > # OPTION_CLIENT_ARCH_TYPE (61) > dhcp-match=set:efi6,option6:61,0007 > dhcp-match=set:efi6,option6:61,0009 > dhcp-match=set:efi6,option6:61,0011 > # User class is iPXE > dhcp-userclass=set:ipxe6,iPXE > > dhcp-host=tag:efi6,tag:ipxe6,52:54:00:bc:c3:fd,[fd12:3456:789a:1::bb00/126],host2 > dhcp-host=tag:!efi6,tag:!ipxe6,52:54:00:bc:c3:fd,[fd12:3456:789a:1::bb05],host2 > > The "temporary addresses" in [fd12:3456:789a:1::bb00/126] are only used > when architecture type is one of the UEFI types or the userclass option > have "iPXE". The dhcp client in the final OS should always end up with > fd12:3456:789a:1::bb05. nice! Really helpful, that looks like it should work - I was just not clever enough to come up with that :-). Our setup is sadly a bit clumsy - we have "Web-GUI-access" (no API :-( ) to one central DHCP/DNS appliance which can do DNS for v4/v6 and DHCPv4, but not DHCPv6 (due to other network components in between). So while we want to keep the information and DNS at that one central place, we have to use dnsmasq for DHCPv6 for now and manually sync information. Using the tag-based approach, this should work fine. We'll likely get to test this at larger scale in the upcoming months, and I may be able to do a test at small scale in the next weeks based on your patch (need to find a time-slot first...). Cheers and thanks, Oliver > > > Another possible solution would be to use a dhcp-script which run's > nsupdate to dynamically update the dns server. > > > > -- > Harald > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - Multiple reservations for single host
On Sun, 2020-01-26 at 20:01 +0100, Oliver Freyermuth wrote: > I also like this new approach. "Wasting" 4 addresses for one host > seems to be the only way > to solve this while conforming to RFCs. > > However, there's one issue I can't find a good solution for in this > scheme - > how to solve the "DNS problem" if dnsmasq is only used for DHCP, but > DNS is provided by other means? > > The "range reservation", as highlighted, means the final address is > not well predictable (may depend on hardware, > other parts of the boot process etc.). > When dnsmasq is also doing the DNS part, that's not a problem, since > it will use the final / "most recently leased" address for DNS. > Does anybody have a good proposal for the case when DHCP is provided > by dnsmasq but DNS is maintained separately > (i.e. the "final address" needs to be fixed)? > > Cheers, > Oliver I think adding tag support for dhcp-host entries as follow up. The idea would be to have a config like this: # OPTION_CLIENT_ARCH_TYPE (61) dhcp-match=set:efi6,option6:61,0007 dhcp-match=set:efi6,option6:61,0009 dhcp-match=set:efi6,option6:61,0011 # User class is iPXE dhcp-userclass=set:ipxe6,iPXE dhcp-host=tag:efi6,tag:ipxe6,52:54:00:bc:c3:fd,[fd12:3456:789a:1::bb00/126],host2 dhcp-host=tag:!efi6,tag:!ipxe6,52:54:00:bc:c3:fd,[fd12:3456:789a:1::bb05],host2 The "temporary addresses" in [fd12:3456:789a:1::bb00/126] are only used when architecture type is one of the UEFI types or the userclass option have "iPXE". The dhcp client in the final OS should always end up with fd12:3456:789a:1::bb05. Another possible solution would be to use a dhcp-script which run's nsupdate to dynamically update the dns server. -- Harald ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - List or Range reservation for single host
On Sun, 2020-01-26 at 18:34 +, Simon Kelley wrote:
> /62 is crazy, I don't know why I even said that. Harald, if you could
> tweak your patch work with 128-based prefixes, I think we have
> reached a
> successful conclusion.
Sure, since 128-bit int's might not be available on many platforms
where dnsmasq run I opted to support a max prefix of /64. So a prefix
between /64 - /128 are valid in config. If the user tries to use a
prefix < /64 an error is raised.
Updated patch below:
From 0c3aeb799d185007d7c9feeb10c84a582b769a72 Mon Sep 17 00:00:00 2001
From: Harald Jensås
Date: Mon, 13 Jan 2020 19:44:43 +0100
Subject: [PATCH] DHCPv6 - List and Range reservation for single host
Add the possibility to provide list's of individual
addresses as well as prefixed ranges of ipv6 addresses
for a dhcp-host reservation.
When a request matching the clid or mac address is
recieved the server will iterate over all candidate
addresses until it find's one that is not already
leased to a different clid/iaid and advertise
this address.
Using multiple reservations for a single host makes it
possible to maintain a static leases only configuration
which support network booting systems with UEFI firmware
that request a new address (a new SOLICIT with a new IA_NA
option using a new IAID) for different boot modes, for
instance 'PXE over IPv6', and 'HTTP-Boot over IPv6'. Open
Virtual Machine Firmware (OVMF) and most UEFI firmware
build on the EDK2 code base exhibit this behaviour.
---
man/dnsmasq.8 | 16 +++
src/dnsmasq.h | 15 +--
src/option.c | 75 ---
src/rfc3315.c | 66 +
4 files changed, 155 insertions(+), 17 deletions(-)
diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
index cb5cc73..46daf98 100644
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -1079,6 +1079,22 @@ work reliably if only one of the hardware addresses is
active at any
time and there is no way for dnsmasq to enforce this. It is, for instance,
useful to allocate a stable IP address to a laptop which
has both wired and wireless interfaces.
+
+For DHCPv6 it is possible to provide multiple IPv6 addresses for a single
+dhcp-host. It is also possible to use a prefix in the configuration to
+set up a range of addresses. For example:
+\fB--dhcp-host=52:54:00:3f:5c:c0,[fd12:3456::aa02][fd12:3456::aa04],host1\fP
+will make the two addresses \fBfd12:3456::aa02\fP and \fBfd12:3456::aa04\fP
+available to the host with hardware address 52:54:00:3f:5c:c0.
+\fB--dhcp-host=52:54:00:3f:5c:c0,[fd12:3456::aa00/126],host1\fP
+will make the range of 4 addresses between the base address (fd12:3456::aa00)
+and the end address (fd12:3456::aa03) available to the host with hardware
+address 52:54:00:3f:5c:c0. Multiple non-prefixed, prefixed or prefixed
+wildcard addresses with only the host-identifier part can be mixed, eg:
+\fB--dhcp-host=52:54:00:3f:5c:c0,[::aa03][::aa04/127][::aa08/126],host1\fP.
+Providing multiple addresses is useful for network booting where individual
+boot stages will request addresses with different IAID's.
+
.TP
.B --dhcp-hostsfile=
Read DHCP host information from the specified file. If a directory
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index 7fb440c..5c771b6 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -759,14 +759,24 @@ struct hwaddr_config {
struct hwaddr_config *next;
};
+#ifdef HAVE_DHCP6
+struct in6_addr_list {
+ struct in6_addr addr6;
+ int prefix;
+ unsigned long flags;
+ struct in6_addr_list *next;
+};
+#endif
+
struct dhcp_config {
- unsigned int flags;
+ unsigned long flags;
int clid_len; /* length of client identifier */
unsigned char *clid; /* clientid */
char *hostname, *domain;
struct dhcp_netid_list *netid;
#ifdef HAVE_DHCP6
- struct in6_addr addr6;
+ struct in6_addr addr6; /* internal only, user opts in addr6_list */
+ struct in6_addr_list *addr6_list;
#endif
struct in_addr addr;
time_t decline_time;
@@ -790,6 +800,7 @@ struct dhcp_config {
#define CONFIG_ADDR6 4096
#define CONFIG_WILDCARD 8192
#define CONFIG_ADDR6_HOSTS 16384/* address added by from /etc/hosts */
+#define CONFIG_ADDR6_CAND32768/* IPv6 address candidate(s) available */
struct dhcp_opt {
int opt, len, flags;
diff --git a/src/option.c b/src/option.c
index f110b75..9f19ca8 100644
--- a/src/option.c
+++ b/src/option.c
@@ -1015,6 +1015,16 @@ static void dhcp_netid_list_free(struct dhcp_netid_list
*netid)
}
}
+static void dhcp_addr6_list_free(struct in6_addr_list *addr6_list)
+{
+ while (addr6_list)
+{
+ struct in6_addr_list *tmp = addr6_list;
+ addr6_list = addr6_list->next;
+ free(tmp);
+}
+}
+
static void dhcp_config_free(struct dhcp_config *config)
{
if (config)
@@ -1027,6 +1037,9 @@ static void dhcp_config_free(struct dhcp_config *config)
free(tmp);
}
dhcp_netid_list_free(config->netid);
+#ifdef HAVE_DHCP6
+
