Re: [Dnsmasq-discuss] client q: both static and dhcp
Hey Carl, On Sat, 2021-06-26 at 19:16 -0500, Carl Karsten wrote: > I'm looking for advice on haveing some boxes to have both dynamic and > static IPs. Why use a static IP at all? We have often enough seen people use static addresses for the wrong reasons. Consider using only DHCP and (a) use a hostname to access the device. In the end, memorizing some- service.lan is more reliable than 192.168.1.149. You may think differently, but let's see what you say after not having logged into the box for half a year - do you still know the address without looking it up? However, you may still recall a good hostname. (b) use a deterministic DHCP server like dnsmasq. It always tries to assign the same IP addresses to the same devices (instead of numbering them sequentially based on their appearance like cheap routers often do). Using (a), (b) or (a)+(b) doesn't require you to have a static IP at all. Best, Dominik ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq dhcp relay not relaying response from upstream to client
Dear Nicolas Cavallari I really appreciate your help I will go to my rest code and do some correction Well, actually that not freeradius (as a software name) but as a node name. All thing come from freeradius is sourced from my rest code. Sincerely -bino- On Sat, Jun 26, 2021 at 6:26 PM Nicolas Cavallari < nicolas.cavall...@green-communications.fr> wrote: > Let's look at the reply from freeradius: > > > (14) Sent code 1026 Id 24307805 from 10.10.254.1:67 to 10.10.253.1:67 > > length 0 > > (14) DHCP-Relay-IP-Address = 10.10.253.1 > > (14) DHCP-Client-Identifier = 0xff2784511b000100012867cc8108002784511b > > (14) DHCP-IP-Address-Lease-Time = 7200 > > (14) DHCP-Client-IP-Address = 255.255.255.255 > > This is suspicious. RFC 2131 Table 3 says ciaddr (Client IP Address) > should be 0.0.0.0 in a DHCPOFFER, and should otherwise mirror the ciaddr > sent by the client, which, in this case, was 0.0.0.0 too. > > > (14) DHCP-Your-IP-Address = 10.10.253.3 > > (14) DHCP-Subnet-Mask = 255.255.255.0 > > (14) DHCP-Router-Address = 10.10.253.1 > > (14) DHCP-Domain-Name-Server = 8.8.8.8 > > (14) DHCP-Message-Type = DHCP-Offer > > (14) DHCP-Gateway-IP-Address = 10.10.253.1 > > (14) DHCP-DHCP-Server-Identifier = 255.255.255.255 > > This is HIGHLY suspicious. This is supposed to be the address of the > server. The rules are set in section 4.1 of the RFC, and most notably: > > "a server MUST choose an address as a 'server identifier' that, to the > best of the server's knowledge, is reachable from the client." > > This is not going to work well in this case. > > > (14) DHCP-Opcode = Server-Message > > (14) DHCP-Hardware-Type = Ethernet > > (14) DHCP-Hardware-Address-Length = 6 > > (14) DHCP-Hop-Count = 1 > > (14) DHCP-Transaction-Id = 24307805 > > (14) DHCP-Flags = 0 > > The "broadcast" flag is not set. This means that the client supports > unicast replies, so the relay should unicast the reply to yiaddr using > chaddr... > > So what would dnsmasq do with such a response ? > > relay_reply4() would correctly detect that this is a server-to-relay > response, so is_relay_reply = 1, > > but ciaddr is not zero, and dnsmasq will trust ciaddr over yiaddr (this > makes perfect sense for a DHCP server, a relay should not see anything > with ciaddr != 0 anyway). so the destination is set to > 255.255.255.255:68, and we skip all the destination selection code (the > one that looks at the broadcast flag), as well as the interface > selection code. > > dnsmasq would probably sends the packet to 255.255.255.255:68 without > telling on which interface it should be sent or which source address > should be used, because ciaddr is supposed to be a unicast address. What > the kernel would do in this case is anyone's guess. > > Even if such a message could be forwarded verbatim to the client, it > would probably confuse it. When a client receives a lease from a DHCP > server, it will renew it by sending unicast packets directly to the > server's "server identifier" address, without involving the relay. But > here, "server identifier" is set to 255.255.255.255... > > On the other hand, the ISC DHCP server/relay/client have probably seen > their share of nonsensical DHCP implementations, and can probably see > through freeradius's nonsense packets. > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] client q: both static and dhcp
This is a bit OT, if there is a better place let me know. I'm looking for advice on haveing some boxes to have both dynamic and static IPs. There is a risk that my static choice collides with an IP on a random lan I jack into, which I can deal with manually. Might even make a MOTD message telling me why I can't log in and see the MOTD ;) What else might be a problem? This conf gets me that: juser@gator:~$ cat /etc/network/interfaces auto lo enp0s31f6 enp0s31f6:0 iface lo inet loopback iface enp0s31f6 inet static address 192.168.1.31 netmask 255.255.255.0 gateway 192.168.1.1 iface enp0s31f6:0 inet dhcp juser@gator:~$ ip a show enp0s31f6 2: enp0s31f6: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 40:8d:5c:7f:bb:90 brd ff:ff:ff:ff:ff:ff inet 192.168.1.31/24 brd 192.168.1.255 scope global enp0s31f6 valid_lft forever preferred_lft forever inet 192.168.1.118/24 brd 192.168.1.255 scope global secondary dynamic enp0s31f6:0 valid_lft 14219sec preferred_lft 14219sec inet6 fe80::428d:5cff:fe7f:bb90/64 scope link valid_lft forever preferred_lft forever juser@gator:~$ /sbin/route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG0 00 enp0s31f6 192.168.1.0 0.0.0.0 255.255.255.0 U 0 00 enp0s31f6 -- Carl K ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] [PATCH] Do not crash when Ubus connection fails.
When using multiple dnsmasq instances Ubus only connects on one of them.
Since 3c93e8eb41952a9c91699386132d6fe83050e9be dnsmasq crashes instead.
This change avoids the crash, leading to a graceful retry + error log.
Signed-off-by: Etan Kissling
---
src/dnsmasq.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/dnsmasq.c b/src/dnsmasq.c
index 04582da..2b4291b 100644
--- a/src/dnsmasq.c
+++ b/src/dnsmasq.c
@@ -449,10 +449,8 @@ int main (int argc, char **argv)
if (option_bool(OPT_UBUS))
#ifdef HAVE_UBUS
{
- char *err;
daemon->ubus = NULL;
- if ((err = ubus_init()))
- die(_("UBus error: %s"), err, EC_MISC);
+ (void) ubus_init(); /* Logging not set up yet. */
}
#else
die(_("UBus not available: set HAVE_UBUS in src/config.h"), NULL,
EC_BADCONF);
--
2.30.1 (Apple Git-130)
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq dhcp relay not relaying response from upstream to client
On Sat, Jun 26, 2021 at 11:52:10AM +0700, Bino Oetomo wrote: > On Sat, Jun 26, 2021 at 4:12 AM Geert Stappers wrote: > > On Fri, Jun 25, 2021 at 11:30:18AM +0700, Bino Oetomo wrote: > > > but how to know if dnsmasq is receiving that response? > > > > ... use networksniffer at **server** to verify that > >the network packets actual do leave 'freeradius' > >at the correct network interface. > > > > Next step will be netsniffing at the DHCP relay computer. > > > I'm not good in network sniffing. Luckly there is now a good reason to get more comfortable with it. > This is tcpdump at the relay : > > 11:42:41.275012 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from > 08:00:27:84:51:1b, length 300 > 11:42:41.275324 IP 10.10.253.1.67 > 10.10.254.1.67: BOOTP/DHCP, Request from > 08:00:27:84:51:1b, length 300 > 11:42:41.433288 IP 10.10.254.1.67 > 10.10.253.1.67: BOOTP/DHCP, Reply, length > 301 > 11:42:45.558901 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from > 08:00:27:84:51:1b, length 300 > 11:42:45.559148 IP 10.10.253.1.67 > 10.10.254.1.67: BOOTP/DHCP, Request from > 08:00:27:84:51:1b, length 300 > 11:42:45.721512 IP 10.10.254.1.67 > 10.10.253.1.67: BOOTP/DHCP, Reply, length > 301 > 11:42:56.982058 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from > 08:00:27:84:51:1b, length 300 > 11:42:56.982472 IP 10.10.253.1.67 > 10.10.254.1.67: BOOTP/DHCP, Request from > 08:00:27:84:51:1b, length 300 > 11:42:57.113442 IP 10.10.254.1.67 > 10.10.253.1.67: BOOTP/DHCP, Reply, length > 301 > > Againt, I'm pretty sure that freeradius sent the response and it reach the > relay. Yes, `tcpdump` does proof that. > But, still got the same conndition and client side > > root@bakalandebian:~# dhclient -d enp0s8 ... > DHCPDISCOVER on enp0s8 to 255.255.255.255 port 67 interval 3 > DHCPDISCOVER on enp0s8 to 255.255.255.255 port 67 interval 7 > DHCPDISCOVER on enp0s8 to 255.255.255.255 port 67 interval 14 > No DHCPOFFERS received. > No working leases in persistent database - sleeping. > > Yes isc-dhcp-relay works, > but I need to stick with dnsmasq since I need to take care about iPXE. I'm also here for the great combination of iPXE and dnsmasq. > > So kindly please help me to fix this problem > > > > That was recieved as > > > > Kindly help me with diagnosing a problem. > > > > > > Already started :-) > > And there is the good observation from Nicolas Cavallari I suggest to continue the email thread there. > > > log-dhcp > > > dhcp-relay=10.10.253.1,10.10.254.1 > > > > Manual page dnsmasq snippet: > >--dhcp-relay=,[, > > > So the 'dhcp-relay=10.10.253.1,10.10.254.1' looks good ... > > > I edited it to --> dhcp-relay=10.10.253.1,10.10.254.1,enp0s8 > enp0s8 is facing freeradius. Acknowledge > I Apologize for my bad english Advice: * Focus on the technical challenge ( focus on the "original problem" ) * Prevent getting exhausted on non-native language stuff > Dear Geert Stappers > I really apprecate your help We all appreciate a healthy community. Groeten Geert Stappers -- Silence is hard to parse ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] what is 'next-server' ? is it dhcp-option 66?
On Sat, Jun 26, 2021 at 02:58:16PM +0700, Bino Oetomo wrote: > On Sat, Jun 26, 2021 at 1:24 PM Geert Stappers wrote: > > On Sat, Jun 26, 2021 at 09:55:01AM +0700, Bino Oetomo wrote: > > > Dear All. > > > > > Is 'next-server' different from dhcp-option-66? > > > > Yes, they are two different "fields" in a DHCP network packet. > > > Qouting https://datatracker.ietf.org/doc/html/rfc2131#page-9 RFC-2131 Dynamic Host Configuration Protocol 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op (1)| htype (1) | hlen (1)| hops (1)| +---+---+---+---+ |xid (4)| +---+---+ | secs (2)| flags (2) | +---+---+ | ciaddr (4) | +---+ | yiaddr (4) | +---+ | siaddr (4) | +---+ | giaddr (4) | +---+ | | | chaddr (16) | | | | | +---+ | | | sname (64) | +---+ | | | file(128)| +---+ | | | options (variable) | +---+ > So, what is it's option number? > is it the same as siaddr? The above model of a DHCP network packet should answer those questions. Regards Geert Stappers Fully are that knowning what is in the network packet, does not mean knowning how it is implemented. -- Silence is hard to parse ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq dhcp relay not relaying response from upstream to client
On Sat, Jun 26, 2021 at 01:26:10PM +0200, Nicolas Cavallari wrote: > Let's look at the reply from freeradius: > > > (14) Sent code 1026 Id 24307805 from 10.10.254.1:67 to 10.10.253.1:67 > > length 0 > > (14) DHCP-Relay-IP-Address = 10.10.253.1 > > (14) DHCP-Client-Identifier = 0xff2784511b000100012867cc8108002784511b > > (14) DHCP-IP-Address-Lease-Time = 7200 > > (14) DHCP-Client-IP-Address = 255.255.255.255 > > This is suspicious. RFC 2131 Table 3 says ciaddr (Client IP Address) should > be 0.0.0.0 in a DHCPOFFER, and should otherwise mirror the ciaddr sent by > the client, which, in this case, was 0.0.0.0 too. > > > (14) DHCP-Your-IP-Address = 10.10.253.3 > > (14) DHCP-Subnet-Mask = 255.255.255.0 > > (14) DHCP-Router-Address = 10.10.253.1 > > (14) DHCP-Domain-Name-Server = 8.8.8.8 > > (14) DHCP-Message-Type = DHCP-Offer > > (14) DHCP-Gateway-IP-Address = 10.10.253.1 > > (14) DHCP-DHCP-Server-Identifier = 255.255.255.255 > > This is HIGHLY suspicious. This is supposed to be the address of the server. Good observation. > The rules are set in section 4.1 of the RFC, and most notably: > > "a server MUST choose an address as a 'server identifier' that, to the best > of the server's knowledge, is reachable from the client." > > This is not going to work well in this case. > > > (14) DHCP-Opcode = Server-Message > > (14) DHCP-Hardware-Type = Ethernet > > (14) DHCP-Hardware-Address-Length = 6 > > (14) DHCP-Hop-Count = 1 > > (14) DHCP-Transaction-Id = 24307805 > > (14) DHCP-Flags = 0 > > The "broadcast" flag is not set. This means that the client supports unicast > replies, so the relay should unicast the reply to yiaddr using chaddr... > > So what would dnsmasq do with such a response ? > > relay_reply4() would correctly detect that this is a server-to-relay > response, so is_relay_reply = 1, > > but ciaddr is not zero, and dnsmasq will trust ciaddr over yiaddr (this > makes perfect sense for a DHCP server, a relay should not see anything with > ciaddr != 0 anyway). so the destination is set to 255.255.255.255:68, and we > skip all the destination selection code (the one that looks at the broadcast > flag), as well as the interface selection code. > > dnsmasq would probably sends the packet to 255.255.255.255:68 without > telling on which interface it should be sent or which source address should > be used, because ciaddr is supposed to be a unicast address. What the kernel > would do in this case is anyone's guess. > > Even if such a message could be forwarded verbatim to the client, it would > probably confuse it. When a client receives a lease from a DHCP server, it > will renew it by sending unicast packets directly to the server's "server > identifier" address, without involving the relay. But here, "server > identifier" is set to 255.255.255.255... > > On the other hand, the ISC DHCP server/relay/client have probably seen their > share of nonsensical DHCP implementations, and can probably see through > freeradius's nonsense packets. At https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q2/015184.html is the message that reports "success" with isc-dhcp-relay. Currently there is no information if the swap of "dhcp relay" was the only change. There _could_ be also change at freeradius DHCP server configuration. Senseble thing would be revert the swap, so dnsmasq again as "dhcp relay", and see if: * problem still exists * problem can be eliminated by re-configuring the Freeradius DHCP server Groeten Geert Stappers -- Silence is hard to parse ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH v5] openwrt: Integration of connmark based DNS filtering
> On 16 Jun 2021, at 23:56, Etan Kissling wrote: > > This integrates the proposed Dnsmasq patch from email: > - [PATCH v5] dnsmasq: connection track mark based DNS query filtering > into OpenWrt 21.02. > > Signed-off-by: Etan Kissling > (updated to latest patch) > Signed-off-by: Etan Kissling > --- > Etan Kissling : > v2: Update to v6 of underlying dnsmasq patch. > v3: Update to v7 of underlying dnsmasq patch. > v4: Update to v8 of underlying dnsmasq patch. > v5: Update to v9 of underlying dnsmasq patch (requires v2.86test2). This has been accepted into OpenWrt master. https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=dea4bae7c2b963af02e1e3e3bdb5cd656a5ea3d3 Etan ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq dhcp relay not relaying response from upstream to client
Let's look at the reply from freeradius: (14) Sent code 1026 Id 24307805 from 10.10.254.1:67 to 10.10.253.1:67 length 0 (14) DHCP-Relay-IP-Address = 10.10.253.1 (14) DHCP-Client-Identifier = 0xff2784511b000100012867cc8108002784511b (14) DHCP-IP-Address-Lease-Time = 7200 (14) DHCP-Client-IP-Address = 255.255.255.255 This is suspicious. RFC 2131 Table 3 says ciaddr (Client IP Address) should be 0.0.0.0 in a DHCPOFFER, and should otherwise mirror the ciaddr sent by the client, which, in this case, was 0.0.0.0 too. (14) DHCP-Your-IP-Address = 10.10.253.3 (14) DHCP-Subnet-Mask = 255.255.255.0 (14) DHCP-Router-Address = 10.10.253.1 (14) DHCP-Domain-Name-Server = 8.8.8.8 (14) DHCP-Message-Type = DHCP-Offer (14) DHCP-Gateway-IP-Address = 10.10.253.1 (14) DHCP-DHCP-Server-Identifier = 255.255.255.255 This is HIGHLY suspicious. This is supposed to be the address of the server. The rules are set in section 4.1 of the RFC, and most notably: "a server MUST choose an address as a 'server identifier' that, to the best of the server's knowledge, is reachable from the client." This is not going to work well in this case. (14) DHCP-Opcode = Server-Message (14) DHCP-Hardware-Type = Ethernet (14) DHCP-Hardware-Address-Length = 6 (14) DHCP-Hop-Count = 1 (14) DHCP-Transaction-Id = 24307805 (14) DHCP-Flags = 0 The "broadcast" flag is not set. This means that the client supports unicast replies, so the relay should unicast the reply to yiaddr using chaddr... So what would dnsmasq do with such a response ? relay_reply4() would correctly detect that this is a server-to-relay response, so is_relay_reply = 1, but ciaddr is not zero, and dnsmasq will trust ciaddr over yiaddr (this makes perfect sense for a DHCP server, a relay should not see anything with ciaddr != 0 anyway). so the destination is set to 255.255.255.255:68, and we skip all the destination selection code (the one that looks at the broadcast flag), as well as the interface selection code. dnsmasq would probably sends the packet to 255.255.255.255:68 without telling on which interface it should be sent or which source address should be used, because ciaddr is supposed to be a unicast address. What the kernel would do in this case is anyone's guess. Even if such a message could be forwarded verbatim to the client, it would probably confuse it. When a client receives a lease from a DHCP server, it will renew it by sending unicast packets directly to the server's "server identifier" address, without involving the relay. But here, "server identifier" is set to 255.255.255.255... On the other hand, the ISC DHCP server/relay/client have probably seen their share of nonsensical DHCP implementations, and can probably see through freeradius's nonsense packets. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] what is 'next-server' ? is it dhcp-option 66?
Dear Geert Stappers I really appreciate your help On Sat, Jun 26, 2021 at 1:24 PM Geert Stappers via Dnsmasq-discuss < dnsmasq-discuss@lists.thekelleys.org.uk> wrote: > On Sat, Jun 26, 2021 at 09:55:01AM +0700, Bino Oetomo wrote: > > Dear All. > > > Is 'next-server' different from dhcp-option-66? > > Yes, they are two different "fields" in a DHCP network packet. > > So, what is it's option number? is it the same as siaddr? Sincerely -bino- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] what is 'next-server' ? is it dhcp-option 66?
On Sat, Jun 26, 2021 at 09:55:01AM +0700, Bino Oetomo wrote: > Dear All. Hello, > I have 3 Virtualbox guest. > A. tftp-server DNSMASQ v.2.80 with IP address 10.10.254.1 > B. dhcp-server DNSMASQ v.280 with IP address 10.10.254.2 and 10.10.253.1 > (This one facing IPXE client) > C. IPXE client +-+ +-+ +-+ | |10.10.254 | | 10.10.253 | | | A +---+ B +---+ C | | |.1 .2| |.1.dhcp| | +-+ +-+ +-+ > When I config dhcp server with: > 'dhcp-boot=lpxelinux.0,server.name,10.10.254.1' > IPXE client received 'next server' 10.10.254.1 > > Next try, I commented 'dhcp-boot' line, and put > dhcp-option=66,10.10.254.1 > dhcp-option=67,lpxelinux.0 > > DNSMASQ log says: > > dnsmasq-dhcp: 3891074361 next server: 10.10.253.1 > dnsmasq-dhcp: 3891074361 sent size: 1 option: 53 message-type 5 > dnsmasq-dhcp: 3891074361 sent size: 4 option: 54 server-identifier > 10.10.253.1 > dnsmasq-dhcp: 3891074361 sent size: 4 option: 51 lease-time 12h > dnsmasq-dhcp: 3891074361 sent size: 4 option: 58 T1 6h > dnsmasq-dhcp: 3891074361 sent size: 4 option: 59 T2 10h30m > dnsmasq-dhcp: 3891074361 sent size: 4 option: 1 netmask 255.255.255.0 > dnsmasq-dhcp: 3891074361 sent size: 4 option: 28 broadcast 10.10.253.255 > dnsmasq-dhcp: 3891074361 sent size: 4 option: 3 router 10.10.253.1 > dnsmasq-dhcp: 3891074361 sent size: 12 option: 67 bootfile-name lpxelinux.0 > dnsmasq-dhcp: 3891074361 sent size: 12 option: 66 tftp-server 10.10.254.1 > > and the IPXE client receive 10.10.253.1, not as described by option:66 Come again, because I do see > dnsmasq-dhcp: 3891074361 next server: 10.10.253.1 > dnsmasq-dhcp: 3891074361 sent size: 12 option: 66 tftp-server 10.10.254.1 > Is 'next-server' different from dhcp-option-66? Yes, they are two different "fields" in a DHCP network packet. Regards Geert Stappers Did invest yesterday (in his timezone) a lot of time in an interesting DHCPrelay related problem. -- Silence is hard to parse ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
