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

Gene Cumm gene.cumm at gmail.com
Fri Mar 7 16:19:53 PST 2014

On Fri, Mar 7, 2014 at 6:01 PM, Jeffrey Hutzelman <jhutz at cmu.edu> wrote:
> 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?

Override.  Due to how the dhcp pack/unpack functions work and the
underlying data structures, it'd have to be redesigned to handle this.

Interesting, 16 different vendor-specific servers are specified.
Vendor (option 43; PXE) sub-option 8 is a list of type (2B), count
(1B), IPv4 (4B * Count) (each is 7 bytes since count is only 1 in this


More information about the Syslinux mailing list