[syslinux] Network Boot IP Configuration Dilemma

[Fred Feirtag]

Background:  I recently wrote to Peter Anvin regarding IPAPPEND
functionality, and he suggested I take the issue to this mailing list.
I see it has been touched upon several times, after reviewing the
archives.  Let me see if I can add to it with a good level of detail:

When using PXE to network boot a linux client, PXE must first
acquire the client's IP address, by dhcp request, then, the downloaded
linux kernel must get the IP address either from pxelinux, or by a
"duplicate" dhcp request.

If the pxelinux.cfg "IPAPPEND 1" entry is used, an "ip=..." string is
appended to the parameters passed to the kernel.  This is, as I will
ultimately conclude below, a less problematic approach, however,
it is in need of being extended to use the currently unused "device"
parameter.

If the pxelinux.cfg "ip=::::::dhcp" entry is used, a dhcp request
will be made by the kernel.

Discussion of the dilemma:

Under ideal circumstances, it makes no difference which approach
is used.  In real world, problematic environments, it may make a very
significant difference.  The first complicating factor is if more than
one network interface is present.  When using the Tyan s2880 Opteron
board, the two on-board interfaces can be turned both on or both off.
It is impossible to use only one of them.  This discussion of
potential problems should apply to any multi-homed netbooting system:

Line 1214 of ipconfig.c (2.4.22 kernel) contains "ic_first_dev->next,"
which implements the objective of the comment on lines 1203-1206:
   "If the config information is insufficient (e.g., ...or we have
    multiple network interfaces and no default was set), use BOOTP
    or RARP to get the missing values."
So if there is more than one device found (the linked list contains
more than a single element), the enumerated "ip=..." values are
ignored and dynamic reconfiguration is attempted, and if dynamic
prococals haven't been compiled into ipconfig, the network
configuration simply fails.  This functionality is understandable,
though I think its wisdom questionable.

I have been able to think of three situations where relevant problems
may occur.

1)  The second network interface, rather than the first, has
     PXE active, and the dhcp issued IP address intended for the
     second interface's identity is used by the first.

2)  The BIOS ordering of the interfaces is different than the
     kernel ordering, so even if the first BIOS located interface
     makes the dhcp request, the kernel sees it as the second.
     I have observed such a similar ordering problem with SCSI
     interfaces, so the same possibility probably exists for network
     interfaces.

3)  A second DHCP server answers the request differently than
     the first.  This is from my experience, the much more likely
     and frequent problem.  Where different servers, possibly
     unintentionally, are answering on the same network, one may
     often answer first for the first request, and the other may
     often answer first for subsequent requests, as the busier, but
     faster system has dhcpd swapped in.

Using the two dhcp request approach may reduce problems #1 and #2.
Using the single dhcp request approach reduces problem #3.
Problems #1 and #2 are solid configuration errors with limited
potential for trouble.  If a system is using an IP address on one
interface that is intended for another of its interfaces, I consider
this the lesser problem.  If, however, a system is intermittently
failing to receive its correct IP address at differing stages of the
boot process, it is a more difficult problem, less likely to be
reported in a way that a system administrator can correctly diagnose it.

I suggest that the syntax of IPAPPEND be changed to allow a specific
device to be named:  "IPAPPEND 1|devname"  ("devname" will usually be
eth0).  Unless and until this is done, here is my hack to change
"ip=#:#:#:#" to "ip=#:#:#:#::eth0:" in pxelinux.asm (after "genipopt"):

...
                 mov eax,[Netmask]
                 call gendotquad ; Zero-terminates its output
                 mov al,':'              ; HACK
                 stosb                   ; HACK
                 mov al,':'              ; HACK
                 stosb                   ; HACK
                 mov al,'e'              ; HACK
                 stosb                   ; HACK
                 mov al,'t'              ; HACK
                 stosb                   ; HACK
                 mov al,'h'              ; HACK
                 stosb                   ; HACK
                 mov al,'0'              ; HACK
                 stosb                   ; HACK
                 mov al,':'              ; HACK
                 stosb                   ; HACK
                 mov al,0                ; HACK
                 stosb                   ; HACK
                 sub di,IPOption
                 mov [IPOptionLen],di
                 popad
                 ret

--Fred

PS:  I don't want to forget to offer thanks for how really good the
syslinux/pxelinux utilities already are.  3 years ago, when etherboot
was a less vendor specific protocol, I used etherboot/mknbi much more,
but now that numerous vendor's come with PXE already in firmware, I've
almost completely switched over to PXE/pxelinux!


-- 
Fred Feirtag
Chief Technologist
Integrity Linux Systems, a division of Integrity Networking Systems, Inc.
1001 Medical Arts Avenue, NE
Albuquerque, NM  87012
email: ffeirtag at integrityns.com
phone: (505) 294 - 7747
fax: (505) 275 - 1125