[syslinux] Cannot chain to another PXE server on the same subnet

Jeffrey Hutzelman jhutz at cmu.edu
Fri Mar 7 15:01:53 PST 2014


On Fri, 2014-03-07 at 17:46 -0500, Gene Cumm wrote:
> On Fri, Mar 7, 2014 at 4:00 PM, Jeffrey Hutzelman <jhutz at cmu.edu> wrote:
> > On Fri, 2014-03-07 at 05:49 -0500, Gene Cumm wrote:
> 
> >> 1) Thinking about the responses again, I'm absolutely surprised that
> >> you can even boot PXELINUX.  I would have expected the response from
> >> the Altiris server to override your attempts to block it.
> >
> > Nope.  The PXE spec explicitly requires that a PXE response from the
> > "real" DHCP server be given precedence.
> 
> So PXE from DHCP, PXE from PXE and file/sname from DHCP is the order
> of precedence.

Yup.  But it doesn't take much PXE to decide the DHCP server is
providing it.  He's sending the PXEClient vendor class ID and a (zero)
mtftp IP address.  If I wanted to be sure, I'd send discovery control
and a 0.0 boot item, but I'm not that surprised it works without them.

I _am_ mildly surprised your example didn't work.  I wonder if maybe we
can, for the purpose of testing, trim down the overall size of the
encapsulated options to fit in 255 bytes.  For example, it would
probably be sufficient to remove most of the menu items, and perhaps all
of the mtftp-related options, which are all optional if you are willing
to do everything unicast.

What will pxechn do if you use -o more than once with the same option
number?

-- Jeff



More information about the Syslinux mailing list