<div dir="ltr"><div>Dear Nicolas Cavallari<br><br></div><div>I really appreciate your help<br></div><div>I will go to my rest code and do some correction<br></div><div><br>Well, actually that not freeradius (as a software name) but as a node name.<br><br></div><div>All thing come from freeradius is sourced from my rest code.<br><br></div><div>Sincerely<br></div><div>-bino-<span class="gmail-gI"><span></span></span></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 26, 2021 at 6:26 PM Nicolas Cavallari <<a href="mailto:nicolas.cavallari@green-communications.fr">nicolas.cavallari@green-communications.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Let's look at the reply from freeradius:<br>
<br>
> (14) Sent code 1026 Id 24307805 from <a href="http://10.10.254.1:67" rel="noreferrer" target="_blank">10.10.254.1:67</a> to <a href="http://10.10.253.1:67" rel="noreferrer" target="_blank">10.10.253.1:67</a><br>
> length 0<br>
> (14)   DHCP-Relay-IP-Address = 10.10.253.1<br>
> (14)   DHCP-Client-Identifier = 0xff2784511b000100012867cc8108002784511b<br>
> (14)   DHCP-IP-Address-Lease-Time = 7200<br>
> (14)   DHCP-Client-IP-Address = 255.255.255.255<br>
<br>
This is suspicious. RFC 2131 Table 3 says ciaddr (Client IP Address) <br>
should be 0.0.0.0 in a DHCPOFFER, and should otherwise mirror the ciaddr <br>
sent by the client, which, in this case, was 0.0.0.0 too.<br>
<br>
> (14)   DHCP-Your-IP-Address = 10.10.253.3<br>
> (14)   DHCP-Subnet-Mask = 255.255.255.0<br>
> (14)   DHCP-Router-Address = 10.10.253.1<br>
> (14)   DHCP-Domain-Name-Server = 8.8.8.8<br>
> (14)   DHCP-Message-Type = DHCP-Offer<br>
> (14)   DHCP-Gateway-IP-Address = 10.10.253.1<br>
> (14)   DHCP-DHCP-Server-Identifier = 255.255.255.255<br>
<br>
This is HIGHLY suspicious. This is supposed to be the address of the <br>
server. The rules are set in section 4.1 of the RFC, and most notably:<br>
<br>
"a server MUST choose an address as a 'server identifier' that, to the <br>
best of the server's knowledge, is reachable from the client."<br>
<br>
This is not going to work well in this case.<br>
<br>
> (14)   DHCP-Opcode = Server-Message<br>
> (14)   DHCP-Hardware-Type = Ethernet<br>
> (14)   DHCP-Hardware-Address-Length = 6<br>
> (14)   DHCP-Hop-Count = 1<br>
> (14)   DHCP-Transaction-Id = 24307805<br>
> (14)   DHCP-Flags = 0<br>
<br>
The "broadcast" flag is not set. This means that the client supports <br>
unicast replies, so the relay should unicast the reply to yiaddr using <br>
chaddr...<br>
<br>
So what would dnsmasq do with such a response ?<br>
<br>
relay_reply4() would correctly detect that this is a server-to-relay <br>
response, so is_relay_reply = 1,<br>
<br>
but ciaddr is not zero, and dnsmasq will trust ciaddr over yiaddr (this <br>
makes perfect sense for a DHCP server, a relay should not see anything <br>
with ciaddr != 0 anyway). so the destination is set to <br>
<a href="http://255.255.255.255:68" rel="noreferrer" target="_blank">255.255.255.255:68</a>, and we skip all the destination selection code (the <br>
one that looks at the broadcast flag), as well as the interface <br>
selection code.<br>
<br>
dnsmasq would probably sends the packet to <a href="http://255.255.255.255:68" rel="noreferrer" target="_blank">255.255.255.255:68</a> without <br>
telling on which interface it should be sent or which source address <br>
should be used, because ciaddr is supposed to be a unicast address. What <br>
the kernel would do in this case is anyone's guess.<br>
<br>
Even if such a message could be forwarded verbatim to the client, it <br>
would probably confuse it. When a client receives a lease from a DHCP <br>
server, it will renew it by sending unicast packets directly to the <br>
server's "server identifier" address, without involving the relay. But <br>
here, "server identifier" is set to 255.255.255.255...<br>
<br>
On the other hand, the ISC DHCP server/relay/client have probably seen <br>
their share of nonsensical DHCP implementations, and can probably see <br>
through freeradius's nonsense packets.<br>
</blockquote></div></div>