|
|
Subject: Re: [Soekris] net4501, tftp filename problem -
msg#00016
On Wed, 19 Jun 2002, Paul Komarek wrote:
>
>
> On Wed, 19 Jun 2002, Javier Fernandez wrote:
>
> > At 03:47 PM 6/19/2002 -0400, Paul Komarek wrote:
> >
> > >Hi,
> > >
> > >I'm very new to netbooting. I've done root nfs to a pc, but this is my
> > >first try at tftp'ing the kernel. Watching a network monitor, my dhcp
> > >server send a bootfile string of /foo, but the net4501 requests /foo\377
> > >from the tftp server and gets a "file not found" error. I fully expect
> > >I'm doing something stupid, but an hour or so of reading and
> > >experimentation hasn't shown me what stupid thing I'm doing. Does anyone
> > >have any ideas about what is happening?
> > >
> > >I can happily grab the file with a tftp client (of course, I don't append
> > >\377, either).
> >
> > We have seen this problem with PXE and Solaris DHCP/TFTP. The PXE stacks we
> > tested were the Intel 100/10 Pro card's and, of course, our 4501 toasters.
> > The problem we encountered was that we were using the OptBootFile parameter
> > instead of the BootFile parameter. PXE was parsing that option wrong. The
> > /377 that you were seeing was probably adjacent to the option passed by
> > DHCP. It looks like it is perhaps a PXE bug, but it is workable.
> >
> > I'd be happy to help you get things going, since it looks like we've dealt
> > with this already.
>
> You rock. Thanks for the help. Once I figured out that OptBootFile
> corresponded to the dhcp bootfile option (#67), and after reading the
> packet dumps carefully (yes, 0xff occurs just after the filename was sent,
> I think as an "end of options" marker), I spotted the *other* filename
> field earlier in the dhcp response. Checking some docs (thanks,
> syslinux!), I found the "filename" declaration. This filled in the
> eariler boot file field, and things work (well, tftp starts, anyway -- now
> I have to figure out what to do next ;-).
>
> The synopsis: If the tftp download of the boot file fails due to an
> inexplicable pathname problem, and a packet dump shows crazy stuff
> (perhaps \377 == 0xff) being appended to the filename by the boot client
> when using tftp to request the file (making filename "foo" look like
> "foo\377" in ethereal's rendition of the packet), use the *first* filename
> field in the dhcp packet instead of the *option* field for the boot
> filename. For the ISC dhcp server daemon, that means using the
> declaration
>
> filename "foo";
>
> instead of the option
>
> option bootfile-name "foo";
>
> in /etc/dhcpd.conf.
>
> Again, thank-you very much for your quick response!
>
> -Paul Komarek
For the sake of anyone reading this thread while trying to solve their own
problems -- note that the tftp daemon in netkit-tftp 0.17, mentioned
earlier, does not handle the tsize option. Therefore, it is not suitable
for use with pxelinux from syslinux 1.75. See the syslinux/pxelinux docs
for suggestions about worthy tftp daemons.
-Paul Komarek
_____________________________________________________________________
Soekris Engineering, technical discussion mailing list
[un]subscribe: http://lists.soekris.com/mailman/listinfo/soekris-tech
Thread at a glance:
Previous Message by Date:
Re: [Soekris] net4501, tftp filename problem
On Wed, 19 Jun 2002, Ted Lemon wrote:
> The PXE boot roms don't do string options correctly, so you have to send
> the filename in the 'file' field of the packet in order for it to work, or
> NUL-terminate the string. I suspect this is Intel's bug, not Soekris, but
> what do I know?
I've seen that problem with non-soekris PXE cards (from ASA computers)
as well.
The config below, using ics-dhcps 'filename' - works perfectly for me.
Note however that the grub boad loader will fetch a *slash* prefixed
filename using tftp - something which the FreeBSD tftp deamon does
(rightly) reject. So either hack grub to remove the initial / (see the
openbsd comment in the code) or hack the freebsd tftp deamon to ignore
that /.
I found that for linux I -must- specify the host-name; as otherwise the
NFS rpc barfs with an obscure error.
Dw.
server-name "foem";
server-identifier 10.11.0.2;
next-server 10.11.0.2;
host dubbeldrank {
hardware ethernet 00:00:24:c0:3c:ac;
fixed-address dubbeldrank.leiden.webweaving.org;
option host-name "dubbeldrank.leiden.webweaving.org";
# OPENBSD:
# option root-path "/usr/local/OpenBSD";
# filename "pxeoboot";
# FreeBSD install onto CVF
# option root-path "/cfinstaller"
# filename "pxeboot";
# FreeBSD runtime
option root-path "10.11.0.2:/mboot";
filename "pxeboot";
# Linux
# option root-path "/usr/local/lnux";
# filename "pxegrub";
}
>
> _____________________________________________________________________
> Soekris Engineering, technical discussion mailing list
> [un]subscribe: http://lists.soekris.com/mailman/listinfo/soekris-tech
>
_____________________________________________________________________
Soekris Engineering, technical discussion mailing list
[un]subscribe: http://lists.soekris.com/mailman/listinfo/soekris-tech
Next Message by Date:
Re: net4501, tftp filename problem
You rock.
I think it is the first time a computer person has said that to me. Thanks!
J.
_____________________________________________________________________
Soekris Engineering, technical discussion mailing list
[un]subscribe: http://lists.soekris.com/mailman/listinfo/soekris-tech
Previous Message by Thread:
Re: [Soekris] net4501, tftp filename problem
On Wed, 19 Jun 2002, Javier Fernandez wrote:
> At 03:47 PM 6/19/2002 -0400, Paul Komarek wrote:
>
> >Hi,
> >
> >I'm very new to netbooting. I've done root nfs to a pc, but this is my
> >first try at tftp'ing the kernel. Watching a network monitor, my dhcp
> >server send a bootfile string of /foo, but the net4501 requests /foo\377
> >from the tftp server and gets a "file not found" error. I fully expect
> >I'm doing something stupid, but an hour or so of reading and
> >experimentation hasn't shown me what stupid thing I'm doing. Does anyone
> >have any ideas about what is happening?
> >
> >I can happily grab the file with a tftp client (of course, I don't append
> >\377, either).
>
> We have seen this problem with PXE and Solaris DHCP/TFTP. The PXE stacks we
> tested were the Intel 100/10 Pro card's and, of course, our 4501 toasters.
> The problem we encountered was that we were using the OptBootFile parameter
> instead of the BootFile parameter. PXE was parsing that option wrong. The
> /377 that you were seeing was probably adjacent to the option passed by
> DHCP. It looks like it is perhaps a PXE bug, but it is workable.
>
> I'd be happy to help you get things going, since it looks like we've dealt
> with this already.
You rock. Thanks for the help. Once I figured out that OptBootFile
corresponded to the dhcp bootfile option (#67), and after reading the
packet dumps carefully (yes, 0xff occurs just after the filename was sent,
I think as an "end of options" marker), I spotted the *other* filename
field earlier in the dhcp response. Checking some docs (thanks,
syslinux!), I found the "filename" declaration. This filled in the
eariler boot file field, and things work (well, tftp starts, anyway -- now
I have to figure out what to do next ;-).
The synopsis: If the tftp download of the boot file fails due to an
inexplicable pathname problem, and a packet dump shows crazy stuff
(perhaps \377 == 0xff) being appended to the filename by the boot client
when using tftp to request the file (making filename "foo" look like
"foo\377" in ethereal's rendition of the packet), use the *first* filename
field in the dhcp packet instead of the *option* field for the boot
filename. For the ISC dhcp server daemon, that means using the
declaration
filename "foo";
instead of the option
option bootfile-name "foo";
in /etc/dhcpd.conf.
Again, thank-you very much for your quick response!
-Paul Komarek
_____________________________________________________________________
Soekris Engineering, technical discussion mailing list
[un]subscribe: http://lists.soekris.com/mailman/listinfo/soekris-tech
Next Message by Thread:
Re: net4501, tftp filename problem
You rock.
I think it is the first time a computer person has said that to me. Thanks!
J.
_____________________________________________________________________
Soekris Engineering, technical discussion mailing list
[un]subscribe: http://lists.soekris.com/mailman/listinfo/soekris-tech
|
|