PXE booting with 3.2.x: DHCP-Server-IP-Address
Dear all, when debugging why PXE booting didn't work after switching from ISC-dhcp to freeradius I noticed, that the "next-server" in ISC is in freeradius taken from "DHCP-Server-IP-Address". This field "siaddr" in the DHCP Packets (not in the option area) ist used by the clients. A comment in raddb/sites-available/dhcp says: # The source IP for unicast packets is chosen from the first # one of the following items which returns a valid IP # address: # # src_ipaddr # ipaddr # reply:DHCP-Server-IP-Address # reply:DHCP-DHCP-Server-Identifier So I never thought that I need to use "DHCP-Server-IP-Address" for the TFTP server (which is not the same as the dhcp server at our site). The first usefull hint was https://github.com/nagios-plugins/nagios-plugins/blob/master/plugins-root/ch...: /* * RFC 2131 (2.) says: "DHCP clarifies the interpretation of the * 'siaddr' field as the address of the server to use in the next step * of the client's bootstrap process. A DHCP server may return its own * address in the 'siaddr' field, if the server is prepared to supply * the next bootstrap service (e.g., delivery of an operating system * executable image). A DHCP server always returns its own address in * the 'server identifier' option." So the setting of "siaddr" in freeradius for pxe booting to a different server seems to be not possible, if you need to set the DHCP-Server-IP-Address also dynamically in freeradius processing. Sorry if I misunderstand things - I'm not fluent in the RFC and PXE stuff in BIOS. Thanks a lot, greetings Hermann P.S: A quick check of v4 master seems to have a syntax change only in the raddb comment -- Administration/Zentrale Dienste, Interdiziplinaeres Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg IWR; INF 205; 69120 Heidelberg; Tel: (06221)54-14405 Fax: -14427 Email: Hermann.Lauer@iwr.uni-heidelberg.de
On 24/06/2024 10:03, Hermann.Lauer@uni-heidelberg.de wrote:
So I never thought that I need to use "DHCP-Server-IP-Address" for the TFTP server (which is not the same as the dhcp server at our site).
What should work is, in the virtual server "listen" section, set the ipaddr or src_ipaddr to that of the DHCP server. Then in your policy set the value of &reply:DHCP-Server-IP-Address to be the TFTP server. Note, in FreeRADIUS v3, all DHCP options have a DHCP- prefix - this is to distinguish them from RADIUS attributes. In FreeRADIUS v4, virtual servers operate in a protocol name space, so those prefixes are removed, making this particular option less confusing - it does not refer to the "DHCP server IP address", but rather the DHCP option "server IP address" Nick -- Nick Porter
Hello Nick, On Mon, Jun 24, 2024 at 11:28:58AM +0100, Nick Porter wrote:
On 24/06/2024 10:03, Hermann.Lauer@uni-heidelberg.de wrote:
So I never thought that I need to use "DHCP-Server-IP-Address" for the TFTP server (which is not the same as the dhcp server at our site).
What should work is, in the virtual server "listen" section, set the ipaddr or src_ipaddr to that of the DHCP server.
Then in your policy set the value of &reply:DHCP-Server-IP-Address to be the TFTP server.
thanks for the quick hint. Already found that out and it works (setting TFTP Server from a python module). Would it be resonable to exchange the order for future development to: # src_ipaddr # ipaddr # reply:DHCP-DHCP-Server-Identifier # reply:DHCP-Server-IP-Address That would allow both attributes (TFTP and DHCP Server Adress) to be dynamically setable, eg. in a python module. Thanks and greetings Hermann -- Administration/Zentrale Dienste, Interdiziplinaeres Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg IWR; INF 205; 69120 Heidelberg; Tel: (06221)54-14405 Fax: -14427 Email: Hermann.Lauer@iwr.uni-heidelberg.de
On Jun 25, 2024, at 5:10 AM, Hermann.Lauer@uni-heidelberg.de wrote:
thanks for the quick hint. Already found that out and it works (setting TFTP Server from a python module).
That's good.
Would it be resonable to exchange the order for future development to
We can't change the behaviour of a stable version. We'll take a look at addressing this in v4. Alan DeKok.
Hello Alan, On Tue, Jun 25, 2024 at 09:56:53AM -0400, Alan DeKok wrote:
thanks for the quick hint. Already found that out and it works (setting TFTP Server from a python module). ... Would it be resonable to exchange the order for future development to
We can't change the behaviour of a stable version. We'll take a look at addressing this in v4.
Of course! But many thanks to you, guys, for looking into it in v4. Greetings Hermann -- Administration/Zentrale Dienste, Interdiziplinaeres Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg IWR; INF 205; 69120 Heidelberg; Tel: (06221)54-14405 Fax: -14427 Email: Hermann.Lauer@iwr.uni-heidelberg.de
On 25/06/2024 15:25, Hermann.Lauer@uni-heidelberg.de wrote:
Of course! But many thanks to you, guys, for looking into it in v4.
Having taken a quick look in the v3.2 and v4 source, the sample virtual server comments are not strictly correct. v3.2 actually does - reply:Packet-Src-IP-Address - if the request was unicast, the address on which the packet was received - src_ipaddr - ipaddr - reply:DHCP-DHCP-Server-Identifier v4 actually does - src_ipaddr - ipaddr - reply.Server-Identifier Neither version look at the Server-IP-Address (or DHCP-Server-IP-Address) option. I'll get the sample virtual server comments corrected Nick -- Nick Porter
participants (3)
-
Alan DeKok -
Hermann.Lauer＠uni-heidelberg.de -
Nick Porter