DHCP relay - wrong interface for relayed packet

[Paul Thornton]

On 07/07/2022 13:43, Alan DeKok wrote:
> On Jul 7, 2022, at 8:37 AM, Paul Thornton <paul at prt.org> wrote:
>
>> My C isn't up to fixing this properly but I'm going to attempt a quick hack proof-of-concept to see if it does work.
> 
>    Great, thanks.

I did some basic (and ugly) work: Cloned fr_dhcp_send, added in a 
"create new socket, hard-code destination IP and port, and sendto() that 
socket instead" bit of code, and made dhcprelay_process_client_request 
call my modified version.

This does solve my problem - the packet now follows the correct default 
route towards the upstream DHCP server :-).


That then exposed another issue - more relating to the original patch to 
change the destination port relayed to.  Of course, when I send to port 
1067, the upstream DHCP server sends the reply on 1067 - which the relay 
isn't listening on.  So the OFFER goes into the void.

I think the proper fix for that is to ensure that the relay is listening 
on any alternative port; but my knowledge of the inner workings of the 
DHCP server is lacking to work out how to do that here (what is 
responsible for setting up the socket that 
dhcprelay_process_server_reply then handles data from?).

As another slightly hacky fix, is there a way, on the upstream DHCP 
server (also FR), to force the destination port to 67 - aside from 
another blunt code hack - I couldn't see anything in the dictionary that 
would allow this.

Paul.