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
