pxeboot arps for its own ip address

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

pxeboot arps for its own ip address

Paul de Weerd
Hi all,

I'm trying to install an older Dell system, an Optiplex GX-1. This is
a 600 MHz P3 with the latest BIOS (A10) from H^HDell. It has an
onboard xl(4) that supports PXE booting so I decided (after several
broken floppies) to take the pxeboot-route.

The system will come up and start DHCP'ing for an IP address. When it
gets a lease it downloads the pxeboot bootloader from my tftp server
and executes it. This looks like :

3Com PXE, version 0.99n.02
Copyright (C) 1997,1998  Intel Corporation.  All rights reserved.

(C) Copyright 1999,2000 Lanworks Technologies Co.
a subsidiary of 3Com Corporation

DHCP MAC ADDR: 00 B0 D0 18 26 4F
CLIENT IP: 192.168.94.46  MASK: 255.255.255.192  DHCP IP: 192.168.94.60
probing: pc0 com0 com1 apm pxe+[0.99] mem[640K 383M a20=on]
disk: fd0 hd0+*
net: mac 00:00:00:00:01:00, ip 0.0.0.0, server 0.0.0.0
>> OpenBSD/i386 PXEBOOT 1.06

After this, it tries to arp for its own IP address :

19:01:52.566774 0:b0:d0:18:26:4f ff:ff:ff:ff:ff:ff 0806 60: arp who-has 192.168.94.46 tell 192.168.94.46

After three such attempts, I get a 'PXE-E11: ARP timeout.' error and
the system tries again. After four of these errors the machine crashes
with a double fault trap (warning : typed in by hand) :

trap: 13(43747): double fault
cn_tab=0x4c660
eax     e0b ecx 4d734 edx       4e894 ebx       4e89c
esp     fd68 ebp        fd88 esi        4e0a0 edi       4e880
eip     8 eflags        4e894 cs        246 ss  10
ds      10 es   10 fs   10 gs   10
Code dump [0x8]:
f000e2c3 3ef000e2 b23ef000 b23ef0 f000b23e 3ef000b2 b23ef000 b23ef0
Memory dump [0x1a000]:
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
Stack trace [0xfd68]:
d 74000000 34740000 4347400 43474 8000434 80004 800
8 46000000 2460000 24600 246 94000002 e8940000 4e89400
4e894 9c0004e8 e89c0004 4e89c00 4e89c a00004e8 e0a00004 4e0a000
fe0a0 600004e0 d7600004 80d76000 4380d760 a84380d7 fda84380 fda843
fda8 60000fd 1e060000 41e0600 41e06 a000041e e0a00004 4e0a000
4e0a0 9c0004ea e89c0004 4e89c00 4e89c d0004e8 20d0004 20d00

[this output looks quite similar when produced several times, although
many values differ, lots of stuff is the same]

I also tried with a published ARP entry for this IP address on my
DHCP/TFTP server :

        $ sudo arp -s 192.168.94.46 0:b0:d0:18:26:4f permanent pub

This crashes the machine with a similar double fault trap immediately
after sending out the 'is-at' reply in response to the first ARP
who-has request.

So there's a couple of strange things (in my opinion) :

        o pxeboot shows MAC and IP with lots of 0's
        o the system tries to ARP for its own IP

My question is, does the PXE implementation of the xl(4) card suck or
is there some bug in pxeboot(8) ? It manages to download pxeboot
correctly, but I'm not sure if that makes it an otherwise good PXE
implementation. Has anyone seen this sort of behaviour before ?

I should note that I used the latest pxeboot from my local mirror,
although there seems to be little change between this version and 3.8

        $ md5 /tftpboot/pxeboot
        MD5 (/tftpboot/pxeboot) = 4d0956341ea53b9f74326b273ef9aff0

If anyone wants, I can provide tcpdump logs of the process.

Thanks,

Paul 'WEiRD' de Weerd

--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.weirdnet.nl/                 

Reply | Threaded
Open this post in threaded view
|

Re: pxeboot arps for its own ip address

Nick Holland
Paul de Weerd wrote:

> Hi all,
>
> I'm trying to install an older Dell system, an Optiplex GX-1. This is
> a 600 MHz P3 with the latest BIOS (A10) from H^HDell. It has an
> onboard xl(4) that supports PXE booting so I decided (after several
> broken floppies) to take the pxeboot-route.
>
> The system will come up and start DHCP'ing for an IP address. When it
> gets a lease it downloads the pxeboot bootloader from my tftp server
> and executes it. This looks like :
>
> 3Com PXE, version 0.99n.02

Version numbers less than 1 are scary on commercial products.
They are annoying on free products.

Doesn't anyone FINISH anything anymore?

> Copyright (C) 1997,1998  Intel Corporation.  All rights reserved.
>
> (C) Copyright 1999,2000 Lanworks Technologies Co.
> a subsidiary of 3Com Corporation
>
> DHCP MAC ADDR: 00 B0 D0 18 26 4F
> CLIENT IP: 192.168.94.46  MASK: 255.255.255.192  DHCP IP: 192.168.94.60
> probing: pc0 com0 com1 apm pxe+[0.99] mem[640K 383M a20=on]
> disk: fd0 hd0+*
> net: mac 00:00:00:00:01:00, ip 0.0.0.0, server 0.0.0.0
>>> OpenBSD/i386 PXEBOOT 1.06
>
> After this, it tries to arp for its own IP address :
>
> 19:01:52.566774 0:b0:d0:18:26:4f ff:ff:ff:ff:ff:ff 0806 60: arp who-has 192.168.94.46 tell 192.168.94.46
>
> After three such attempts, I get a 'PXE-E11: ARP timeout.' error and
> the system tries again. After four of these errors the machine crashes
> with a double fault trap (warning : typed in by hand) :
>
> trap: 13(43747): double fault
> cn_tab=0x4c660
> eax     e0b ecx 4d734 edx       4e894 ebx       4e89c
> esp     fd68 ebp        fd88 esi        4e0a0 edi       4e880
> eip     8 eflags        4e894 cs        246 ss  10
> ds      10 es   10 fs   10 gs   10
> Code dump [0x8]:
> f000e2c3 3ef000e2 b23ef000 b23ef0 f000b23e 3ef000b2 b23ef000 b23ef0
> Memory dump [0x1a000]:
> 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0
> Stack trace [0xfd68]:
> d 74000000 34740000 4347400 43474 8000434 80004 800
> 8 46000000 2460000 24600 246 94000002 e8940000 4e89400
> 4e894 9c0004e8 e89c0004 4e89c00 4e89c a00004e8 e0a00004 4e0a000
> fe0a0 600004e0 d7600004 80d76000 4380d760 a84380d7 fda84380 fda843
> fda8 60000fd 1e060000 41e0600 41e06 a000041e e0a00004 4e0a000
> 4e0a0 9c0004ea e89c0004 4e89c00 4e89c d0004e8 20d0004 20d00
>
> [this output looks quite similar when produced several times, although
> many values differ, lots of stuff is the same]
>
> I also tried with a published ARP entry for this IP address on my
> DHCP/TFTP server :
>
> $ sudo arp -s 192.168.94.46 0:b0:d0:18:26:4f permanent pub
>
> This crashes the machine with a similar double fault trap immediately
> after sending out the 'is-at' reply in response to the first ARP
> who-has request.
>
> So there's a couple of strange things (in my opinion) :
>
> o pxeboot shows MAC and IP with lots of 0's
> o the system tries to ARP for its own IP
>
> My question is, does the PXE implementation of the xl(4) card suck or
> is there some bug in pxeboot(8) ? It manages to download pxeboot
> correctly, but I'm not sure if that makes it an otherwise good PXE
> implementation. Has anyone seen this sort of behaviour before ?

yes, unfortunately.
Looks like we get junk at the same places, Dell GX1, G1 and GX100
systems are where I saw this problem as well. :)

I've seen similar problems on fxp cards, however most of those are flash
upgradable, whereas 3Com cards don't seem to be.  The PXE ROMs of that
vintage didn't seem very good...  Our PXE boot process seems to work
better on newer-vintage ROMs than it does on these first-generation
products.

I have placed some of these cards in the Right Person's hands to see if
it can be improved, but that person has been pretty busy lately...

The good news is, 3Com has a PXE boot floppy that works for almost all
their Ethernet cards (inc. ISA products), free for the download.  All
things considered, /for my uses/, the floppy (or burning it to a
bootable CD) is more useful than the boot ROMs.

Nick.

Reply | Threaded
Open this post in threaded view
|

Re: pxeboot arps for its own ip address

Josh Webb
In reply to this post by Paul de Weerd
Paul de Weerd wrote:
> So there's a couple of strange things (in my opinion) :
>
> o pxeboot shows MAC and IP with lots of 0's
> o the system tries to ARP for its own IP

I don't know about that first one, but it is normal for a host to ARP
for its own IP. That is what's known as a "gratuitous" ARP. If there is
a reply, the system knows there is an address conflict. Also, it serves
to update the ARP cache on other systems if a different NIC takes over
for an IP address (like if the system or NIC were replaced).

Reply | Threaded
Open this post in threaded view
|

Re: pxeboot arps for its own ip address

Paul de Weerd
In reply to this post by Nick Holland
Hi Nick,

Thanks for your reply.

On Sun, Nov 20, 2005 at 03:29:13PM -0500, Nick Holland wrote:
| > 3Com PXE, version 0.99n.02
|
| Version numbers less than 1 are scary on commercial products.
| They are annoying on free products.
|
| Doesn't anyone FINISH anything anymore?

Great minds...

| The good news is, 3Com has a PXE boot floppy that works for almost all
| their Ethernet cards (inc. ISA products), free for the download.  All
| things considered, /for my uses/, the floppy (or burning it to a
| bootable CD) is more useful than the boot ROMs.

A reasonable (and interesting) point, but my main interest in booting
this system via PXE was lack of a CD-ROM drive and *#&@(*&$@(* failing
floppies. It's been forever since I last bought new floppies .. in
fact I just yesterday threw out some 5.25" 360KB ones I found while
cleaning up some old mess. I was hoping the floppy-days were over.

Nonetheless, thanks for your answer. I'll find some other means to
install this box and another box to play PXE games with ;)

Cheers,

Paul 'WEiRD' de Weerd

--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.weirdnet.nl/                 

Reply | Threaded
Open this post in threaded view
|

Re: pxeboot arps for its own ip address

Paul de Weerd
In reply to this post by Josh Webb
On Sun, Nov 20, 2005 at 02:53:04PM -0600, Josh Webb wrote:
| Paul de Weerd wrote:
| >So there's a couple of strange things (in my opinion) :
| >
| > o pxeboot shows MAC and IP with lots of 0's
| > o the system tries to ARP for its own IP
|
| I don't know about that first one, but it is normal for a host to ARP
| for its own IP. That is what's known as a "gratuitous" ARP. If there is
| a reply, the system knows there is an address conflict. Also, it serves
| to update the ARP cache on other systems if a different NIC takes over
| for an IP address (like if the system or NIC were replaced).

Very true, but this machine waits for an answer (which should not (and
does not) come after a gratuitous arp. And it will complain with an
"arp timeout" error message. That is rather strange if you'd ask me,
timeouts on gratuitous arps.

Cheers,

Paul 'WEiRD' de Weerd

--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.weirdnet.nl/