On 07/07/2022 13:43, Alan DeKok wrote:
On Jul 7, 2022, at 8:37 AM, Paul Thornton <paul@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.