filename in BOOTP reply vs RFC 951 -- ignore the previous message please

[Eduardo Fleury]

FYI, this would be the patch.
Note that now it only uses the default filename if packet -> raw -> file
(ie. the filename field in the received packet) is empty.

Here is a extract from RFC 951 about that:

====

      We now check the boot file name field (file).  The field will be
      null if the client is not interested in filenames, or wants the
      default bootfile.  If the field is non-null, it is used as a
      lookup key in a database, along with the client's IP address.  If
      there is a default file or generic file (possibly indexed by the
      client address) or a fully-specified path name that matches, then
      replace the 'file' field with the fully-specified path name of the
      selected boot file.  If the field is non-null and no match was
      found, then the client is asking for a file we dont have; discard
      the packet, perhaps some other BOOTP server will have it

====

My understanding is that nobody actually cares about a true check whether
the server have the requested file or not specially because the tftp server
might be in a different machine than the dhcp/bootp server. However I
believe that trusting that the file asked exists somewhere is better then
assuming the only file available is the default one.

Best regards,
Eduardo

____
Eduardo Fleury
Software Engineer
IBM Linux Technology Center Brazil

On 7/30/07, Eduardo Fleury <efleury at gmail.com> wrote:
>
> Sorry for the previous message which was sent before being ready.
> -----------
> Hi, how are you?
>
> I've set up an ISC DHCP/BOOTP server so that it provides a set of images I
> need to make an IBM Power machine boot from the network, however I've run
> into a situation that might require a correction in the dhcp server.
>
> The issue is the following, the image I'm trying to boot is split in
> several files due to a few design restrictions. In order to boot I's
> expecting the following to work:
>
> 1) CLIENT sends a bootp request with a NULL filename (aka zeroed filename
> field).
> 2) SERVER sends bootp reply with default filename (as specified in
> dhcpd.conf or whatever)
> 3) CLIENT gets the first file with TFTP.
> 4) CLIENT sends a bootp request for the 2nd file - filename field IS
> SPECIFIED.
> 5) SERVER sends a bootp reply to let the client know it can get the SECOND
> file.
> 6) CLIENT gets the second file with TFTP.
>
> And then steps 4-6 repeat until all files needed have been got.
>
> I've also read the RFC 951 and 1542 and from what I could understand it
> seems that this behavior is in accordance to the BOOTP standard.
>
> However, this is not working because in the 5th step above, the BOOTP
> reply message is sent with the first filename in it. Reading the code in v.
> 3.1.0 I could see that currently, if a filename is specified in dhcpd.confthis filename will be ALWAYS used, no matter what arrives in the BOOTP
> request message.
>
> My understanding is that the filename specified in the configuration file
> should be used ONLY IF the bootp request hadn't specified a filename itself,
> ie. the server shouldn't override the filename specified by the client.
>
> I'd like to know if you agree with my understanding. If you do, this is
> something that could be changed with a tiny patch (1 line) in v. 3.1.0 (I
> have yet to check in v. 4).
>
> Kind regards,
> Eduardo
>
> ____
> Eduardo Fleury
> Software Engineer
> IBM Linux Technology Center Brazil
>