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

[Eduardo Fleury]

Here's the attachment
diff -ru dhcp-3.1.0/server/bootp.c dhcp-3.1.0-patched/server/bootp.c
--- dhcp-3.1.0/server/bootp.c   2006-08-09 09:57:48.000000000 -0500
+++ dhcp-3.1.0-patched/server/bootp.c   2007-07-30 11:11:19.000000000 -0500
@@ -283,7 +283,7 @@

        /* Figure out the filename. */
        oc = lookup_option (&server_universe, options, SV_FILENAME);
-       if (oc &&
+       if (!(packet -> raw -> file[0]) && oc &&
            evaluate_option_cache (&d1, packet, lease,
                                   (struct client_state *)0,
                                   packet -> options, options,


On 7/30/07, Eduardo Fleury <efleury at gmail.com> wrote:
>
> 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.conf this 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
> >
>
>