Mailing List Archive

"Alex Holliday" <metaphage@hotmail.com> writes:

> I have managed to set up DHCP and TFTP on a Fedora Core 6 server but
> the problem is when PXELinux on the client tries to load the
> configuration file.

Did you check http://syslinux.zytor.com/pxe.php#tftp ? Also, try
running the tftp server in verbose mode, and look at the logs.
--
Feri.

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Wagner Ferenc wrote:
> "Alex Holliday" <metaphage@hotmail.com> writes:
>
>> I have managed to set up DHCP and TFTP on a Fedora Core 6 server but
>> the problem is when PXELinux on the client tries to load the
>> configuration file.
>
> Did you check http://syslinux.zytor.com/pxe.php#tftp ? Also, try
> running the tftp server in verbose mode, and look at the logs.

Especially you should add

next-server <Your_TFTP_server_address>;

[See: http://syslinux.zytor.com/archives/2005-October/006033.html]

You could also try to use an absolute path to "pxelinux.0"

filename "/tftpboot/pxelinux.0";

But I guess it's the missing "next-server" directive ...

BTW: What is "pxelinux.1"?

Axel

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Wagner Ferenc wrote:
>"Alex Holliday" <metaphage@hotmail.com> writes:
>
>>I have managed to set up DHCP and TFTP on a Fedora Core 6 server but
>>the problem is when PXELinux on the client tries to load the
>>configuration file.
>
>Did you check http://syslinux.zytor.com/pxe.php#tftp ? Also, try
>running the tftp server in verbose mode, and look at the logs.

Especially you should add

next-server <Your_TFTP_server_address>;

Hi all, this fixed the problem, I don't understand why this needs to be
there if it knows where to get pxelinux.1. Also where would it have been
trying to get the file from?? And pxelinux.1 is pxelinux 3.36, pxelinux.0 is
pxelinux 3.11.

Thanks.

_________________________________________________________________
Live Search delivers results the way you like it. Try live.com now!
http://www.live.com

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Alex Holliday wrote:
> Wagner Ferenc wrote:
>> "Alex Holliday" <metaphage@hotmail.com> writes:
>>
>>> I have managed to set up DHCP and TFTP on a Fedora Core 6 server but
>>> the problem is when PXELinux on the client tries to load the
>>> configuration file.
>> Did you check http://syslinux.zytor.com/pxe.php#tftp ? Also, try
>> running the tftp server in verbose mode, and look at the logs.
>
> Especially you should add
>
> next-server <Your_TFTP_server_address>;
>
> Hi all, this fixed the problem, I don't understand why this needs to be
> there if it knows where to get pxelinux.1. Also where would it have been
> trying to get the file from??

As hpa already pointed out in his reply to

http://syslinux.zytor.com/archives/2005-October/006033.html

<quote>
It worked before because previous versions of ISC DHCP defaulted to
"next-server == boot server". They removed that default without warning.
</quote>

So while "pxelinux[.0]" is loaded from "boot-server", "pxelinux" itself
is left without a valid ip-address (next-server) to continue from.

I don't know, if it would be possible for "pxelinux" to derive "next-server"
from "boot-server", in case that "next-server" is empty.
But perhaps the "boot-server" information is no longer available when
"pxelinux" is executed, otherwise -- I guess -- hpa would have already
implemented this.

Axel

P. S.: Did you actually reply to a previous post?
I can't find any "In-Reply-To" header and neither does thunderbird.
So your message isn't grouped into the thread ...

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Dyks, Axel (XL) wrote:
> Alex Holliday wrote:
>> Wagner Ferenc wrote:
>>> "Alex Holliday" <metaphage@hotmail.com> writes:
>>>
>>>> I have managed to set up DHCP and TFTP on a Fedora Core 6 server but
>>>> the problem is when PXELinux on the client tries to load the
>>>> configuration file.
>>> Did you check http://syslinux.zytor.com/pxe.php#tftp ? Also, try
>>> running the tftp server in verbose mode, and look at the logs.
>> Especially you should add
>>
>> next-server <Your_TFTP_server_address>;
>>
>> Hi all, this fixed the problem, I don't understand why this needs to be
>> there if it knows where to get pxelinux.1. Also where would it have been
>> trying to get the file from??
>
> As hpa already pointed out in his reply to
>
> http://syslinux.zytor.com/archives/2005-October/006033.html
>
> <quote>
> It worked before because previous versions of ISC DHCP defaulted to
> "next-server == boot server". They removed that default without warning.
> </quote>
>
> So while "pxelinux[.0]" is loaded from "boot-server", "pxelinux" itself
> is left without a valid ip-address (next-server) to continue from.
>
> I don't know, if it would be possible for "pxelinux" to derive "next-server"
> from "boot-server", in case that "next-server" is empty.
> But perhaps the "boot-server" information is no longer available when
> "pxelinux" is executed, otherwise -- I guess -- hpa would have already
> implemented this.
>

I did some more research on this matter:

The RELNOTES document starting with version 3.0.3 of ISC's DHCPD lists
the following change since 3.0.2

<quote source="RELNOTES(3.0.3 and newer)">
The siaddr field was being improperly set to the server-identifier when
responding to DHCP messages. RFC2131 clarified the siaddr field as
meaning the 'next server in the bootstrap process', eg a tftp server.
The siaddr field is now left zeroed unless next-server is configured.
</quote>

... though the corresponding manual page had not been updated accordingly

<quote source="dhcpd.conf(3.0.3)">
The "next-server" statement is used to specify the host address of
the server from which the initial boot file (specified in the
"filename" statement) is to be loaded. "Server-name" should
be a numeric IP address or a domain name. If no "next-server"
parameter applies to a given client, the DHCP server's IP address is
used.
</quote>

... which has been fixed meanwhile

<quote source="dhcpd.conf(3.1.0a2)">
The "next-server" statement is used to specify the host address of
the server from which the initial boot file (specified in the
"filename" statement) is to be loaded. "Server-name" should
be a numeric IP address or a domain name.
</quote>

Actually I do not understand, why ISC changed their interpretation of RFC2131.

<quote source="RFC2131">
DHCP clarifies the interpretation of the 'siaddr' field as the
address of the server to use in the next step of the client's
bootstrap process. A DHCP server may return its own address in the
'siaddr' field, if the server is prepared to supply the next
bootstrap service (e.g., delivery of an operating system executable
image). A DHCP server always returns its own address in the 'server
identifier' option.
</quote>

I think that having a "filename" statement in "dhcpd.conf" but no
"next-server" statement is a strong indicator for the DHCP server
('s IP address) also being used "to supply the next bootstrap service".

Regardless of being the ISC interpretation right or wrong the actually
misbehaving component in the bootstrap process seems to be the
PXE-ROM of Alex's client. Complying with RFC2131 would forbid
to silently use the DHCP server address to download "pxelinux[.0]",
if "siaddr" (next-server) is found to be empty.

So according to RFC2131 the following is true:

* ISC may be right or may be wrong
// I think, they are wrong or at least they are
// guessing wrong ...

* pxelinux's behaviour is correct
// Well, it might not try to download anything from
// an empty (0.0.0.0) IP-Address

* Alex client's PXE-ROM behaves wrong
// It shouldn't download "filename" from "DHCP-Server", if
// siaddr (next-server) is empty

Axel

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Dyks, Axel (XL) wrote:
>
> So while "pxelinux[.0]" is loaded from "boot-server", "pxelinux" itself
> is left without a valid ip-address (next-server) to continue from.
>
> I don't know, if it would be possible for "pxelinux" to derive "next-server"
> from "boot-server", in case that "next-server" is empty.
> But perhaps the "boot-server" information is no longer available when
> "pxelinux" is executed, otherwise -- I guess -- hpa would have already
> implemented this.
>

Well, what one can do is to violate the protocol (which the PXE stack
itself apparently does here) and so something like that... it might be
the right thing to do.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

H. Peter Anvin wrote:
> Dyks, Axel (XL) wrote:
>> So while "pxelinux[.0]" is loaded from "boot-server", "pxelinux" itself
>> is left without a valid ip-address (next-server) to continue from.
>>
>> I don't know, if it would be possible for "pxelinux" to derive "next-server"
>> from "boot-server", in case that "next-server" is empty.
>> But perhaps the "boot-server" information is no longer available when
>> "pxelinux" is executed, otherwise -- I guess -- hpa would have already
>> implemented this.
>>
>
> Well, what one can do is to violate the protocol (which the PXE stack
> itself apparently does here) and so something like that... it might be
> the right thing to do.

Well, after doing my analysis and also figuring out that the PXE stack
actually does the wrong thing, I doubt that "meaning well" is equal to
"doing well" in this case.
// I originally thought that there would be a technical problem instead
// of a protocol violation that prevents pxelinux from setting
// next-server to boot/dhcp-server ...

If the PXE stack -- propably "meaning well" -- wouldn't violate RFC2131,
nobody would see pxelinux failing to download the config files after
being downloaded by itself from the same TFTP server.

I currently can't think of a scenario in which a more "meaning well"
pxelinux would simply pass on the problem to a subsequent stage in the
boot process, but you'll never know ...

After all, the solution is simple. RTFM and add "next-server" to "dhcpd.conf".

:-) Axel

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.