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

Eduardo Fleury efleury at gmail.com
Fri Aug 10 19:04:07 UTC 2007


Hi guys,
Since the list is kind of active today, I was wondering if anyone has any
thoughts about that BOOTP issue I mentioned a couple weeks ago.

Thanks,
Eduardo

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




More information about the dhcp-hackers mailing list