Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

4.0.x - DHCP does not print the correct destination port when sending a reply #3221

Open
nchaigne opened this issue Dec 22, 2019 · 4 comments
Open

Comments

@nchaigne
Copy link
Contributor

@nchaigne nchaigne commented Dec 22, 2019

Issue type

  • Defect - Unexpected behaviour (obvious or verified by project member).

Defect

How to reproduce the issue

Configure FreeRADIUS to listen on port 6700.
Sent a DHCP Discover from port 67 (using giaddr), to FreeRADIUS port 6700.

Started with -X, FreeRADIUS says it sends the reply to the sender and port 67 (as expected):

(7)  Sending DHCP-Offer XID 00000000 from 127.0.0.1:6700 to 10.11.12.1:67 via lo

But it actually sends the reply to port 6700, as shown by a tcpdump:

18:52:41.930624 IP 10.11.12.1.67 > 127.0.0.1.6700: BOOTP/DHCP, Request from b3:5e:e5:00:b3:5e, length 300
18:52:41.931121 IP 127.0.0.1.6700 > 10.11.12.1.6700: UDP, length 300
@alandekok

This comment has been minimized.

Copy link
Member

@alandekok alandekok commented Dec 22, 2019

DHCP is a horrible protocol unfortunately. It mandates src/dst ports for various situations. i.e. it doesn't support clients sending packets from random source ports.

It's not really clear what to do here. Perhaps one solution is to use (and enforce) the RFC ports if the server is listening on the RFC ports. i.e. run like a normal DHCP server when using the RFC ports.

Then, if the server isn't listening on the RFC ports, it should just behave like a normal UDP application, and swap src/dst ip/port when sending replies.

@nchaigne

This comment has been minimized.

Copy link
Contributor Author

@nchaigne nchaigne commented Dec 22, 2019

How about:

  • If the server is sending a reply to a giaddr, and the packet source IP address is that giaddr, then use the packet source port as destination (not RFC but allows more flexibility)
  • If sending a reply to a giaddr that is not the packet source IP, then send to that giaddr and standard port 67 (enforce RFC)

Though maybe it's not worth the hassle since non standard ports are just for testing.
I don't mind if you prefer to leave it as it is now.

But at least, the server should not lie about what it is doing. If it is sending to port 6700, it should not say 67. :)

@nchaigne nchaigne changed the title 4.0.x - DHCP does not send reply to the correct port 4.0.x - DHCP does not print the correct destination port when sending a reply Dec 22, 2019
@nchaigne

This comment has been minimized.

Copy link
Contributor Author

@nchaigne nchaigne commented Dec 23, 2019

The "incorrect" reply debug is printed from mod_process (proto_dhcpv4_base.c), before the reply is actually sent.
But then mod_write (proto_dhcpv4_udp.c) will do its own work on source/destination.

Maybe just change the debug "Reply will be sent to giaddr." here to add information such as the actual destination port?

			DEBUG("Reply will be sent to giaddr.");
			address.dst_ipaddr.addr.v4.s_addr = ipaddr;
			address.dst_port = inst->port;
			address.src_port = inst->port;

(source address could also be useful, since there's some "magic" involved)

@nchaigne

This comment has been minimized.

Copy link
Contributor Author

@nchaigne nchaigne commented Dec 23, 2019

Or add a debug "Sending from... to..." at "send_reply" juste before actually sending:

https://github.com/FreeRADIUS/freeradius-server/blob/master/src/modules/proto_dhcpv4/proto_dhcpv4_udp.c#L424

nchaigne added a commit to nchaigne/freeradius-server that referenced this issue Dec 30, 2019
Helps understanding FreeRADIUS#3221
arr2036 added a commit that referenced this issue Jan 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.