<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;"><DIV>Hi,</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>I am going throgh BOOTP and DHCP differences and i came across three fields in Linux next-server, server-name and tftp-server-name. </DIV>
<DIV> </DIV>
<DIV>In Windows 2003 Server the "sname" field is never used and option 66 ( tftp-server-name option) and "siaddr" fields are same. </DIV>
<DIV> </DIV>
<DIV>I have few questions and understandings on Linux behaviour and in general in RFC :<BR> <BR>1) siaddr field from RFC will match to "next-server" name in Linux.</DIV>
<DIV> </DIV>
<DIV>2) In which case "sname" field can be used ? For linux sname is equivalent to "server-name" , does its behaviour is also similar to "next-server".</DIV>
<DIV> </DIV>
<DIV> If i give "sname" ipaddress but not "next-server" in DHCP server conf file as per man page " used to inform the client of the name of the server from which it is booting" , does this implies it can be used as "tftp-server" if not what is the purpose of this field? </DIV>
<DIV> </DIV>
<DIV>and how it is used.</DIV>
<DIV> </DIV>
<DIV>Also in one of forun thread it is mentioned that "this is the name of the dhcp server" if it is so , we already have dhcp-server-identifier field, why duplication of this?<BR> <BR>Somewhere i read , this field is used by client to identify the server name from which it wants to boot, but no where setting this option is present in clients (either in windows or Linux).In RFC the sname field is mentioned by clients only as options or unused. So client should never use it is my assumption.</DIV>
<DIV> </DIV>
<DIV>3) Next question is when "tftp-server-name" option will be used.</DIV>
<DIV><BR>Also in previous forum thread (given in references) it is mentioned that the client should request for it . Using which option should the client request it, so that it will work?</DIV>
<DIV><BR>What will happen if i set both "next-server(siaddr) " and "tftp-server-name" which will be given preference.</DIV>
<DIV><BR>In windows 2003 server, if we configure option 66 it is not sending it seperately as option but overriding the "siaddr" field. This means that "sname" is not overloaded and even though the name is "option 66" internally they are setting "siaddr" field. Is this behaviour correct as per RFC? </DIV>
<DIV> </DIV>
<DIV>Please let me know your thoughts on this. I will appreciate your comments/ views on this. This will help me in understanding of the DHCP in general. Below are the references which i have gone through.</DIV>
<DIV> </DIV>
<DIV><BR>References:================================================</DIV>
<DIV><A href="http://www.daemon-systems.org/man/dhcpd.conf.5.html">http://www.daemon-systems.org/man/dhcpd.conf.5.html</A></DIV>
<DIV><A href="http://linux.die.net/man/5/dhcp-options">http://linux.die.net/man/5/dhcp-options</A></DIV>
<DIV>Linux Man pages: </DIV>
<DIV>next-server server-name;</DIV>
<DIV> The next-server statement is used to specify the host address of the<BR> server from which the initial boot file (specified in the filename<BR> statement) is to be loaded. Server-name should be a numeric IP<BR> address or a domain name.</DIV>
<DIV> <BR>The server-name statement</DIV>
<DIV> server-name name ;</DIV>
<DIV> The server-name statement can be used to inform the client of the<BR> name of the server from which it is booting. Name should be the<BR> name that will be provided to the client.</DIV>
<DIV><BR>option tftp-server-name text; </DIV>
<DIV><BR>This option is used to identify a TFTP server and, if supported by the client, should have the same effect as the server-name declaration. BOOTP clients are </DIV>
<DIV>unlikely to support this option. Some DHCP clients will support it, and others actually require it. </DIV>
<DIV><BR>Already discussed threads, but not clear to me:</DIV>
<DIV><BR><A href="https://lists.isc.org/pipermail/dhcp-users/2006-September/001874.html">https://lists.isc.org/pipermail/dhcp-users/2006-September/001874.html</A></DIV>
<DIV><A href="https://lists.isc.org/pipermail/dhcp-users/2007-March/003089.html">https://lists.isc.org/pipermail/dhcp-users/2007-March/003089.html</A></DIV>
<DIV> </DIV>
<DIV>DHCP RFC 2131 and </DIV>
<DIV>options RFC : <A href="http://tools.ietf.org/html/rfc2132">http://tools.ietf.org/html/rfc2132</A></DIV>
<DIV><BR> siaddr 4 IP address of next server to use in bootstrap;<BR> returned in DHCPOFFER, DHCPACK by server.<BR> <BR> sname 64 Optional server host name, null terminated string.</DIV>
<DIV><BR>TFTP server name</DIV>
<DIV> This option is used to identify a TFTP server when the 'sname' field<BR> in the DHCP header has been used for DHCP options.</DIV>
<DIV> The code for this option is 66, and its minimum length is 1.</DIV>
<DIV> Code Len TFTP server<BR> +-----+-----+-----+-----+-----+---<BR> | 66 | n | c1 | c2 | c3 | ...<BR> +-----+-----+-----+-----+-----+---</DIV>
<DIV>RFC sec 4.3.1<BR> <BR> DHCPOFFER DHCPACK</DIV>
<DIV>'sname' Server host name Server host name (unused)<BR> or options or options<BR> <BR> DHCPDISCOVER DHCPREQUEST<BR>'sname' options, if options, if (unused)<BR> indicated in indicated in<BR> 'sname/file'
'sname/file'<BR> option; otherwise option; otherwise<BR> unused unused</DIV>
<DIV><BR>Sec 3.5 </DIV>
<DIV>The client SHOULD include the 'maximum DHCP message size' option to<BR> let the server know how large the server may make its DHCP messages.<BR> The parameters returned to a client may still exceed the space<BR> allocated to options in a DHCP message. In this case, two additional<BR> options flags (which must appear in the 'options' field of the<BR> message) indicate that the 'file' and 'sname' fields are to be used<BR> for options.In this case, two additional<BR> options flags (which must appear in the 'options' field of the<BR> message) indicate that the 'file' and 'sname' fields are to be used<BR> for options.</DIV>
<DIV><BR>========================================================================</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Sujata</DIV></td></tr></table>