Re: [Dnsmasq-discuss] dnsmasq dhcp relay not relaying response from upstream to client
Dear Geert Stappers
On Mon, Jun 28, 2021 at 1:29 PM Geert Stappers via Dnsmasq-discuss <
dnsmasq-discuss@lists.thekelleys.org.uk> wrote:
> 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.
>
> As I stated in
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q2/015194.html
That is, all things come from freeradius is sourced from my rest service.
for every data come from dhcp-relay, FreeRadius daemon will make a json
http post to my rest service.
In response, my rest service will tell FreeRadius daemon what it need to
tell to dhcp-relay.
So the core problem is not at FreeRadius daemon (and it's configuration),
it's in my rest service codes.
My vault not telling it from the start of this discussion
Anyway, here they are:
#
/etc/freeradius/sites-enabled/dhcp
#
server dhcp {
listen {
type = dhcp
ipaddr = 10.10.254.1
port = 67
broadcast = no
performance {
skip_duplicate_checks = no
}
}
dhcp DHCP-Discover {
rest.authorize
}
dhcp DHCP-Request {
rest.authorize
}
dhcp DHCP-Decline {
update reply {
= DHCP-Do-Not-Respond
}
reject
}
dhcp DHCP-Inform {
dhcp_common
ok
}
dhcp DHCP-Release {
rest.authorize
}
dhcp DHCP-Lease-Query {
if () {
}
elsif () {
}
elsif () {
}
else {
update reply {
= DHCP-Lease-Unknown
}
ok
return
}
if (notfound) {
update reply {
= DHCP-Lease-Unknown
}
ok
return
}
update reply {
= DHCP-Lease-Unassigned
}
}
}
#-
/etc/freeradius/mods-enabled
rest {
connect_uri = "http://127.0.0.1:/djenroll/freeradius/;
authorize {
uri = "${..connect_uri}"
method = 'post'
body = 'json'
}
authenticate {
uri = "${..connect_uri}"
method = 'post'
body = 'json'
}
preacct {
uri = "${..connect_uri}"
method = 'post'
body = 'json'
}
accounting {
uri = "${..connect_uri}"
method = 'post'
body = 'json'
}
post-auth {
uri = "${..connect_uri}"
method = 'post'
body = 'json'
}
pool {
start = 0
min = 0
max = 5
spare = 0
uses = 0
lifetime = 0
cleanup_interval = 30
idle_timeout = 60
retry_delay = 30
spread = no
}
}
#
Sincerely
-bino-
>
> > So Nicolas Cavallari, I really appreciate your help.
>
> Yes, compliments to Nicolas for diagnosing the problem.
>
>
>
> > Sincerely
> > -bino-
>
>
> Please make reading in the discussion order possible,
> reply below previous text.
>
>
>
> 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
>
___
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 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 = 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. > > > > 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. > Sincerely > -bino- Please make reading in the discussion order possible, reply below previous text. 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] dnsmasq dhcp relay not relaying response from upstream to client
Dear All After I do what Nicolas Cavallari told me to do, It works smooth. 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. So Nicolas Cavallari, I really appreciate your help. 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
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
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] 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] 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] dnsmasq dhcp relay not relaying response from upstream to client
Dear Geert Stappers I really apprecate your help 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: > > > My question is: > > I'm sure that freeradius sent the response, > > Carefull ... > > > 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. I take another root... Try with isc-dhcp-relay : dhcrelay -d -i enp0s9 enp0s8 -id enp0s9 -iu enp0s8 10.10.254.1 And at the client I got : Listening on LPF/enp0s8/08:00:27:84:51:1b Sending on LPF/enp0s8/08:00:27:84:51:1b Sending on Socket/fallback DHCPDISCOVER on enp0s8 to 255.255.255.255 port 67 interval 8 DHCPOFFER of 10.10.253.3 from 10.10.253.1 DHCPREQUEST for 10.10.253.3 on enp0s8 to 255.255.255.255 port 67 DHCPACK of 10.10.253.3 from 10.10.253.1 bound to 10.10.253.3 -- renewal in 3295 seconds. So I'm pretty sure the FreeRadius sent the response and reach the dhcp-relay node. https://en.wikipedia.org/wiki/Network_Packet_Sniffer > > > > my dnsmasq configuration > > > > port=0 > > interface=enp0s9 > > 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. 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. But, still got the same conndition and client side root@bakalandebian:~# dhclient -d enp0s8 Internet Systems Consortium DHCP Client 4.4.1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/enp0s8/08:00:27:84:51:1b Sending on LPF/enp0s8/08:00:27:84:51:1b Sending on Socket/fallback DHCPDISCOVER on enp0s8 to 255.255.255.255 port 67 interval 3 DHCPDISCOVER on enp0s8 to 255.255.255.255 port 67 interval 3 DHCPDISCOVER on enp0s8 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on enp0s8 to 255.255.255.255 port 67 interval 11 DHCPDISCOVER on enp0s8 to 255.255.255.255 port 67 interval 13 DHCPDISCOVER on enp0s8 to 255.255.255.255 port 67 interval 7 DHCPDISCOVER on enp0s8 to 255.255.255.255 port 67 interval 14 DHCPDISCOVER on enp0s8 to 255.255.255.255 port 67 interval 5 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. > So kindly please help me to fix this problem > > That was recieved as > > Kindly help me with diagnosing a problem. > > > Already started :-) > > > I Apologize for my bad english 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] dnsmasq dhcp relay not relaying response from upstream to client
On Fri, Jun 25, 2021 at 11:30:18AM +0700, Bino Oetomo wrote:
> Dear All.
>
> I Have 3 Virtualbox guest OS, arranged with internal-network as :
>
> Freeradius <--X--> dhcprelay <--Y--> client
( I have seen better ASCII-art )
> 1. Internal networks:
> a. X is 'tftprelay'
> b. Y is 'tftpclient'
That got me confused. After "transmit error correction":
} a. X is 'dhcprelay'
} b. Y is 'dhcpclient'
> 1. Freeradius act as DHCP server, with interface facing dhcprelay.
> IP address : 10.10.254.1
>
> 2. Dhcprelay using dnsmasq 2.80.
> also enabled for packet forwarding.
Probably IP forwarding
> IP Address:
> a. Facing FreeRadius 10.10.254.2
> b. Facing client 10.10.253.1
>
> 3. Client is just plain debian server.
> enp0s8 is interface at network-Y where dnsmas is listening
>
>
> 4. ping test from freeradius to dhcprelay at network-Y
>
> root@tftpserver:~# ping 10.10.253.1
> PING 10.10.253.1 (10.10.253.1) 56(84) bytes of data.
> 64 bytes from 10.10.253.1: icmp_seq=1 ttl=64 time=1.08 ms
> 64 bytes from 10.10.253.1: icmp_seq=2 ttl=64 time=0.900 ms
OK
> 5. Test from client with : dhclient -d enp0s8
> I got:
>
>
> a. at dhcprelay (dnsmasq log)
>
> Jun 25 06:23:47 dhcprelay dnsmasq-dhcp[1366]: DHCP relay 10.10.253.1 ->
> 10.10.254.1
> Jun 25 06:23:54 dhcprelay dnsmasq-dhcp[1366]: DHCP relay 10.10.253.1 ->
> 10.10.254.1
> Jun 25 06:24:08 dhcprelay dnsmasq-dhcp[1366]: DHCP relay 10.10.253.1 ->
> 10.10.254.1
> Jun 25 06:24:26 dhcprelay dnsmasq-dhcp[1366]: DHCP relay 10.10.253.1 ->
> 10.10.254.1
> Jun 25 06:24:41 dhcprelay dnsmasq-dhcp[1366]: DHCP relay 10.10.253.1 ->
> 10.10.254.1
>
> b. Freeradius. Looks like it can receive and response from/to dnsmasq:
>
> ...
> (14) Received code 1025 Id 24307805 from 10.10.253.1:67 to 10.10.254.1:67
> length 300
> (14) DHCP-Opcode = Client-Message
> (14) DHCP-Hop-Count = 1
> (14) DHCP-Transaction-Id = 24307805
> (14) DHCP-Gateway-IP-Address = 10.10.253.1
The relay
> (14) DHCP-Client-Hardware-Address = 08:00:27:84:51:1b
> (14) DHCP-Message-Type = DHCP-Discover
> (14) DHCP-Hostname = "bakalandebian"
> (14) DHCP-Client-Identifier = 0xff2784511b000100012867cc8108002784511b
> (14) DHCP-Network-Subnet = 10.10.253.1/32
> Trying sub-section dhcp DHCP-Discover {...}
> (14) dhcp DHCP-Discover {
> rlm_rest (rest): 0 of 0 connections in use. You may need to increase "spare"
> rlm_rest (rest): Opening additional connection (3), 1 of 5 pending slots used
> rlm_rest (rest): Connecting to "http://127.0.0.1:/djenroll/freeradius/;
> rlm_rest (rest): Reserved connection (3)
> (14) rest: Expanding URI components
> (14) rest: EXPAND http://127.0.0.1:
> (14) rest:--> http://127.0.0.1:
> (14) rest: EXPAND /djenroll/freeradius/
> (14) rest:--> /djenroll/freeradius/
> (14) rest: Sending HTTP POST to "http://127.0.0.1:/djenroll/freeradius/;
> (14) rest: Encoding attribute "DHCP-Client-Identifier"
> (14) rest: Returning 1009 bytes of JSON data (buffer full or chunk exceeded)
> (14) rest: Processing response header
> (14) rest: Status : 100 (Continue)
> (14) rest: Continuing...
> (14) rest: Processing response header
> (14) rest: Status : 200 (OK)
> (14) rest: Type : json (application/json)
> (14) rest: Adding reply:REST-HTTP-Status-Code += "200"
> (14) rest: Parsing attribute "reply:DHCP-IP-Address-Lease-Time"
> (14) rest: EXPAND 7200
> (14) rest:--> 7200
> (14) rest: DHCP-IP-Address-Lease-Time := 7200
> (14) rest: Parsing attribute "reply:DHCP-Client-IP-Address"
> (14) rest: EXPAND 255.255.255.255
> (14) rest:--> 255.255.255.255
> (14) rest: DHCP-Client-IP-Address := 255.255.255.255
> (14) rest: Parsing attribute "reply:DHCP-Your-IP-Address"
> (14) rest: EXPAND 10.10.253.3
> (14) rest:--> 10.10.253.3
For the client
> (14) rest: DHCP-Your-IP-Address := 10.10.253.3
> (14) rest: Parsing attribute "reply:DHCP-Subnet-Mask"
> (14) rest: EXPAND 255.255.255.0
> (14) rest:--> 255.255.255.0
> (14) rest: DHCP-Subnet-Mask := 255.255.255.0
> (14) rest: Parsing attribute "reply:DHCP-Router-Address"
> (14) rest: EXPAND 10.10.253.1
> (14) rest:--> 10.10.253.1
The relay
> (14) rest: DHCP-Router-Address := 10.10.253.1
> (14) rest: Parsing attribute "reply:DHCP-Domain-Name-Server"
> (14) rest: EXPAND 8.8.8.8
> (14) rest:--> 8.8.8.8
> (14) rest: DHCP-Domain-Name-Server := 8.8.8.8
> (14) rest: Parsing attribute "reply:DHCP-Message-Type"
> (14) rest: EXPAND DHCP-Offer
> (14) rest:--> DHCP-Offer
> (14) rest: DHCP-Message-Type := DHCP-Offer
> (14) rest: Parsing attribute "reply:DHCP-Gateway-IP-Address"
> (14) rest: EXPAND 10.10.253.1
> (14) rest:--> 10.10.253.1
> (14) rest: DHCP-Gateway-IP-Address := 10.10.253.1
> (14) rest: Parsing attribute "reply:DHCP-DHCP-Server-Identifier"
> (14) rest: EXPAND 255.255.255.255
> (14) rest:--> 255.255.255.255
> (14) rest: DHCP-DHCP-Server-Identifier := 255.255.255.255
> rlm_rest (rest): Released connection (3)
> (14) [rest.authorize] = updated
> (14) } # dhcp
[Dnsmasq-discuss] dnsmasq dhcp relay not relaying response from upstream to client
Dear All.
I Have 3 Virtualbox guest OS, arranged with internal-network as :
Freeradius <--X--> dhcprelay <--Y--> client
1. Internal networks:
a. X is 'tftprelay'
b. Y is 'tftpclient'
1. Freeradius act as DHCP server, with interface facing dhcprelay.
IP address : 10.10.254.1
2. Dhcprelay using dnsmasq 2.80.
also enabled for packet forwarding.
IP Address:
a. Facing FreeRadius 10.10.254.2
b. Facing client 10.10.253.1
3. Client is just plain debian server.
enp0s8 is interface at network-Y where dnsmas is listening
4. ping test from freeradius to dhcprelay at network-Y
root@tftpserver:~# ping 10.10.253.1
PING 10.10.253.1 (10.10.253.1) 56(84) bytes of data.
64 bytes from 10.10.253.1: icmp_seq=1 ttl=64 time=1.08 ms
64 bytes from 10.10.253.1: icmp_seq=2 ttl=64 time=0.900 ms
64 bytes from 10.10.253.1: icmp_seq=3 ttl=64 time=1.07 ms
64 bytes from 10.10.253.1: icmp_seq=4 ttl=64 time=0.904 ms
64 bytes from 10.10.253.1: icmp_seq=5 ttl=64 time=1.15 ms
5. Test from client with : dhclient -d enp0s8
I got:
a. at dhcprelay (dnsmasq log)
Jun 25 06:23:47 dhcprelay dnsmasq-dhcp[1366]: DHCP relay 10.10.253.1 ->
10.10.254.1
Jun 25 06:23:54 dhcprelay dnsmasq-dhcp[1366]: DHCP relay 10.10.253.1 ->
10.10.254.1
Jun 25 06:24:08 dhcprelay dnsmasq-dhcp[1366]: DHCP relay 10.10.253.1 ->
10.10.254.1
Jun 25 06:24:26 dhcprelay dnsmasq-dhcp[1366]: DHCP relay 10.10.253.1 ->
10.10.254.1
Jun 25 06:24:41 dhcprelay dnsmasq-dhcp[1366]: DHCP relay 10.10.253.1 ->
10.10.254.1
b. Freeradius. Looks like it can receive and response from/to dnsmasq:
...
(14) Received code 1025 Id 24307805 from 10.10.253.1:67 to 10.10.254.1:67
length 300
(14) DHCP-Opcode = Client-Message
(14) DHCP-Hardware-Type = Ethernet
(14) DHCP-Hardware-Address-Length = 6
(14) DHCP-Hop-Count = 1
(14) DHCP-Transaction-Id = 24307805
(14) DHCP-Number-of-Seconds = 58
(14) DHCP-Flags = 0
(14) DHCP-Client-IP-Address = 0.0.0.0
(14) DHCP-Your-IP-Address = 0.0.0.0
(14) DHCP-Server-IP-Address = 0.0.0.0
(14) DHCP-Gateway-IP-Address = 10.10.253.1
(14) DHCP-Client-Hardware-Address = 08:00:27:84:51:1b
(14) DHCP-Message-Type = DHCP-Discover
(14) DHCP-Hostname = "bakalandebian"
(14) DHCP-Parameter-Request-List = DHCP-Subnet-Mask
(14) DHCP-Parameter-Request-List = DHCP-Broadcast-Address
(14) DHCP-Parameter-Request-List = DHCP-Time-Offset
(14) DHCP-Parameter-Request-List = DHCP-Router-Address
(14) DHCP-Parameter-Request-List = DHCP-Domain-Name
(14) DHCP-Parameter-Request-List = DHCP-Domain-Name-Server
(14) DHCP-Parameter-Request-List = DHCP-Domain-Search
(14) DHCP-Parameter-Request-List = DHCP-Hostname
(14) DHCP-Parameter-Request-List = DHCP-NETBIOS-Name-Servers
(14) DHCP-Parameter-Request-List = DHCP-NETBIOS
(14) DHCP-Parameter-Request-List = DHCP-Interface-MTU-Size
(14) DHCP-Parameter-Request-List = DHCP-Classless-Static-Route
(14) DHCP-Parameter-Request-List = DHCP-NTP-Servers
(14) DHCP-Client-Identifier = 0xff2784511b000100012867cc8108002784511b
(14) DHCP-Network-Subnet = 10.10.253.1/32
Trying sub-section dhcp DHCP-Discover {...}
(14) dhcp DHCP-Discover {
rlm_rest (rest): 0 of 0 connections in use. You may need to increase
"spare"
rlm_rest (rest): Opening additional connection (3), 1 of 5 pending slots
used
rlm_rest (rest): Connecting to "http://127.0.0.1:/djenroll/freeradius/;
rlm_rest (rest): Reserved connection (3)
(14) rest: Expanding URI components
(14) rest: EXPAND http://127.0.0.1:
(14) rest:--> http://127.0.0.1:
(14) rest: EXPAND /djenroll/freeradius/
(14) rest:--> /djenroll/freeradius/
(14) rest: Sending HTTP POST to "http://127.0.0.1:/djenroll/freeradius/;
(14) rest: Encoding attribute "DHCP-Opcode"
(14) rest: Encoding attribute "DHCP-Hardware-Type"
(14) rest: Encoding attribute "DHCP-Hardware-Address-Length"
(14) rest: Encoding attribute "DHCP-Hop-Count"
(14) rest: Encoding attribute "DHCP-Transaction-Id"
(14) rest: Encoding attribute "DHCP-Number-of-Seconds"
(14) rest: Encoding attribute "DHCP-Flags"
(14) rest: Encoding attribute "DHCP-Client-IP-Address"
(14) rest: Encoding attribute "DHCP-Your-IP-Address"
(14) rest: Encoding attribute "DHCP-Server-IP-Address"
(14) rest: Encoding attribute "DHCP-Gateway-IP-Address"
(14) rest: Encoding attribute "DHCP-Client-Hardware-Address"
(14) rest: Encoding attribute "DHCP-Network-Subnet"
(14) rest: Encoding attribute "DHCP-Hostname"
(14) rest: Encoding attribute "DHCP-Message-Type"
(14) rest: Encoding attribute "DHCP-Parameter-Request-List"
(14) rest: Encoding attribute "DHCP-Client-Identifier"
(14) rest: Returning 1009 bytes of JSON data (buffer full or chunk exceeded)
(14) rest: Processing response header
(14) rest: Status : 100 (Continue)
(14) rest: Continuing...
(14) rest: Processing response header
(14) rest: Status : 200 (OK)
(14) rest: Type : json (application/json)
(14) rest: Adding reply:REST-HTTP-Status-Code += "200"
(14) rest: Parsing attribute "reply:DHCP-IP-Address-Lease-Time"
(14) rest: EXPAND 7200
(14) rest:--> 7200
