[Dnsmasq-discuss] dnsmasq dhcp relay not relaying response from upstream to client
stappers at stappers.nl
Mon Jun 28 06:13:15 UTC 2021
On Mon, Jun 28, 2021 at 09:15:03AM +0700, Bino Oetomo wrote:
> Dear All
> On Sat, Jun 26, 2021 at 6:26 PM 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 = 188.8.131.52
> > > (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.
> After I do what Nicolas Cavallari told me to do, It works smooth.
Thanks for reporting that DHCP relay function of dnsmasq works.
> Since my FreeRadius installation is sourcing all reply attribute from my
> rest service, I made my rest to:
> 1. Give the right broadcast address DHCP option.
> 2. Give the right Server Identifier DHCP option.
> Point #2 also fix my other problem about TFTP boot.
Please share the whole FreeRadius DHCP server configuration file with us.
In the mailinglist archive ( https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q2/015180.html)
is currently only the incomplete (and "broken") configuration.
It is a good thing to give the mailing archive a working version.
The complete version shows where to insert the extra settings
and which syntax.
> So Nicolas Cavallari, I really appreciate your help.
Yes, compliments to Nicolas for diagnosing the problem.
Please make reading in the discussion order possible,
reply below previous text.
Silence is hard to parse
More information about the Dnsmasq-discuss