PXE boot problems on iPaq c500/810e

Hi all,

Since this a network-centric and Compaq issue, I hope it is
sufficiently topical for this forum...

I posted this in a HP/Compaq support forum and would
appreciate any help from Usenet readers too:

Greetings:

We cannot get the c500/810e to PXE boot; it never accepts the bootp/dhcp
offers it is given or it does not properly accept the ip address/mask/gw
values it is given.

Here are the details.

1. We run a number of IBM PXE-booted machines
which use PXE 0.99n and Intel LanDesk
Service Agent II in the bootrom. They
are served by a bootp server. A packet
trace of a successful boot shows that the
bootp reply to the target is unicast to
the offered ip address and bootp flags
are 0x8000 (broadcast). The Vendor Class
ID field from the target is "PXEClient"

2. The iPaq clients on the other hand have
Intel UNDI PXE-2.0 (build 071) and show
a Vendor Class ID field of "PXEClient:Arch:
00000:UNDI:002001" which contains invalid
characters (colons) for vendor specific
options fields (these are separators in
the config files), but even so the client
should accept an ip address in the offer
but instead it reports "Client IP: 0.0.0.0
MASK: 0.0.0.0 DHCP IP: 0.0.0.0". It then
proceeds to _broadcast_ a tftp request for
the boot file name it was given (this
should be a unicast to the tftp server
address it was given).

3. If a DHCP server is configured instead to
offer to the iPaq target, it never accepts
the offers; the iPaq sets the bootp flags
to 0x8000 (broadcast) instead of 0x0000
(unicast), so the DHCP server replies with
a _broadcast_ reply offer and the iPaq
ignores that.

From my reading of PXE specs, PXE 2.0 should
be backward compatible with 0.99 at least as
to obtaining an ip address and netmask; there
may be issues with the need for option 60
Vendor Class ID field matching but every
description of this field for PXE 2.0 clients
states that this field should contain
"PXEClient" and not the string described above.

Was the boot agent in this machine something
custom or unique or buggy?

All replies are much appreciated.

Michael Grigoni
Cybertheque Museum

msg wrote:


3. If a DHCP server is configured instead to
offer to the iPaq target, it never accepts
the offers; the iPaq sets the bootp flags
to 0x8000 (broadcast) instead of 0x0000
(unicast), so the DHCP server replies with
a _broadcast_ reply offer and the iPaq
ignores that.


Solaris (2.6) dhcptab permits colons in data fields if they are
included in a string enclosed in double quotes. In testing with
the Solaris dhcpd, I discovered that the iPaq client will accept
an ip address/mask/gw if the dhcp offer includes a bootfile name
but without it it ignores the offer :-(

Now the problem is convincing the iPaq to accept a 'next server'
address (e.g. BootSrvA in 'dhcptab' parlance) for the location of
the tftp server; it ignores this value and insists on fetching
the bootfile from the dhcp server address. Even when the
bootfile name includes the ip address of the tftp server, e.g.:
"10.0.0.200:/some/path/filename" it directs the tftp request to
the dhcp server's ip address.

All replies much appreciated,

Michael

msg wrote:


Now the problem is convincing the iPaq to accept a 'next server'
address (e.g. BootSrvA in 'dhcptab' parlance) for the location of
the tftp server; it ignores this value and insists on fetching
the bootfile from the dhcp server address. Even when the
bootfile name includes the ip address of the tftp server, e.g.:
"10.0.0.200:/some/path/filename" it directs the tftp request to
the dhcp server's ip address.


This seems to be an issue with PXE 2.0, see:

http://groups.google.com/group/intel...17d3d0403f5523

Note that the response from an Intel rep to the O.P. was a non-sequiter:
Thanks for your inquiry about Intel® products.

First, I would first download and use the newest version of PXE
from:

http://support.intel.com/support/net...0/100pboot.htm

This is version 2.6.

Also the best documentation for PXE is at:

http://developer.intel.com/ial/wfm/t...dk20/index.htm

Thanks for the opportunity to assist.

Sincerely,

John C.

The O.P. obtained the updates which fixed nothing and of course
the agent is burned into the client's bootrom (and is not upgradable
unless a fix is provided by the equipment vendor).

All replies welcome,

Michael

msg wrote:

The O.P. obtained the updates which fixed nothing and of course
the agent is burned into the client's bootrom (and is not upgradable
unless a fix is provided by the equipment vendor).


I may be narrowing the field of possibilities: rom the Intel
PXE PDK ref document (pdf):


Boot ROM - PXE - 2.0 (Build 078) Code Changes
ROM Init
snip
• Added code to parse the client IP, BOOTP server IP and subnet mask
when a BOOTP server is used.
• Removed code that checked for the DHCP message type (option 53) in the
unicast proxyDHCP reply. The ROM was only accepting packets with a
message type of DHCPACK (5). • Added minimum length check to BIS
SMBIOS structure check.
• SIADDR field in DHCP/BOOTP packet is used for TFTP server IP address
if it is not 0.0.0.0.
snip

Each of the above impacts the issues I have reported. How does one
obtain a flasher which will update the code on the iPaq (note that
the firmware from compaq is build 071)?

Regards,

Michael

msg wrote:


How does one obtain a flasher which will update the code on the iPaq
(note that the firmware from compaq is build 071)?


I grabbed the PXE/RPL bootrom updater from Intel ('pxeboot.exe' is
the archive name); it contains PXE 2.0 build 084 and 085 and a flasher
utility. The readme states that if the NIC is embedded on the M/B
then one must either update the code using the manufacturer's rombios
flasher or a manufacturer-specific flasher for the NIC's flash rom.
I will try the generic flasher and report the results.

Regards,

Michael

msg wrote:

I will try the generic flasher and report the results.


Failu The flasher 'ibautil.exe' reports:

Enabling Boot ROM on NIC 1... not supported
The Boot Agent on NIC 1 is controlled by the system BIOS.

As I saw in the README, a 'LOM' (LAN on Motherboard) NIC is
a captive of the system BIOS and its flash can only be
upgraded by a system BIOS flash upgrade... help HP!

Regards,

Michael

msg wrote:

a 'LOM' (LAN on Motherboard) NIC is
a captive of the system BIOS and its flash can only be
upgraded by a system BIOS flash upgrade... help HP!


Until and if HP/Compaq will support this hardware with a BIOS fix here
is the workaround (not pretty) for the broken PXE boot agent:

1. setup a dhcp server to offer the following (Solaris dhcptab example):

PXEClient:Arch:00000:UNDI:002001 m \
:BootFile="/absolute/path/name": \
:TFTPsrvN=server.domain.tld:BootSrvA=ip.ad.dr.s s: \
:Rootpath="ip.ad.dr.ss:/absolute/path":

and for a particular O/S second stage loader, e.g. FreeBSD:

FreeBSD:i386:4.11-RELEASE m \
:Rootpath="ip.ad.dr.ss:/absolute/path/os/root":

also for the subnet of the client:

ip.ad.dr.ss m \
:Broadcast=br.oa.dc.st:Subnet=su.bn.et.ad: \
:Router=ro.ou.te.rd:

also include a macro for the client class which offers DNS, Time
Services, Domain Name, Locale, and Lease Time and persistence.

2. Setup a tftpd on the same host running the dhcp server and
place a copy of the second stage loader (e.g. pxeboot) in
the directory declared in the BootFile option above; be sure
to include any subdirectories with ancillary files needed by
the loader if necessary.

3. The broken boot agent does not honor the 'Rootpath' offer it
is given, so for the example of FreeBSD booting:

Create a symlink called /pxeboot at the root of the server
providing further tftp or nfs services (may be a different
server than the dhcp host) which points to the actual exported
directory to be used by the client. The pxeboot code defaults
to this path when it doesn't receive a Rootpath (or one may
choose to recompile the loader with a different default path
and dispense with the symlink).

Note that the deficiencies in the broken boot agent that are
most onerous a

1. failure to honor the 'next server (SIADDR)' value in the offer
2. failure to accept the 'Rootpath' value in the offer
3. use of broadcast instead of unicast tftp requests when
the bootserver value has been offered (this causes a jabber
of tftp replies from multiple tftp servers).
4. failure to parse the client IP, BOOTP server IP and subnet mask
when a BOOTP server is used.

These all appear to have been remedied by Build 078 of the boot agent.

HP/Compaq, please provide the updater!

Regards,

Michael Grigoni
Cybertheque Museum

msg wrote:


Create a symlink called /pxeboot at the root of the server
providing further tftp or nfs services (may be a different
server than the dhcp host) which points to the actual exported
directory to be used by the client. The pxeboot code defaults
to this path when it doesn't receive a Rootpath (or one may
choose to recompile the loader with a different default path
and dispense with the symlink).

Forgot to mention to share this path '/pxeboot' if using NFS (ro).

Michael