Ticket #284 (closed defect: fixed)

Opened 10 years ago

Last modified 10 years ago

PXE tries to boot from wrong server

Reported by: abma Owned by:
Priority: major Component: other
Version: VirtualBox 1.3.8 Keywords: pxe boot netboot next
Cc: Guest type: other
Host type: other


There seems to be a problem in the dhcp client/tftp client of the pxe-code.

i've set up a dhcp server, offering a next server. (wiresharks shows the correct ip address in the DHCP-OFFER) but then, the pxe client tries to boot from a complete wrong ip address.

ip/dhcp server/relay...all seems to be correct, only the boot server is wrong :-/

Change History

comment:1 Changed 10 years ago by abma

note: the port is wrong too, the port should be: 69, but it in is 4011 (read from wireshark)

comment:2 Changed 10 years ago by klaus

Can you please attach the packet trace (DHCP and TFTP only, I'm not interested in other stuff)? Would help tremendously.

If the first DHCP request goes to port 4011 then it detected a proxy DHCP server and asks that first.

comment:3 Changed 10 years ago by abma

i've added a iptables rule which dnats to the right ftp server. this is why the tftp connection starts ( is really, really wrong)

virtualbox is svn version/64 bit. sorry, that could be the problem, i forgot. but with windows i couldn't setup a bridge, because i couldn't set the mac adress of the bridge to the ethernet card one.

comment:4 Changed 10 years ago by abma

i've found a workaround:

with a bootable etherboot iso-image pxebooting is possible.

(nic is pcnet32:pcnet32 0x1022, 0x2000)

comment:5 Changed 10 years ago by klaus

  • Status changed from new to closed
  • Resolution set to fixed

I'm a bit confused by the packet trace you sent. Some packets are definitely missing (i.e. the DHCP discover/request packets). But at least it was sufficient to figure out that you're using a PXE boot menu. So this is not the ProxyDHCP case like I assumed first.

Looking at the DHCP offer and the PXE spec shows that the bug clearly is in our PXE code. The parsing of the menu options doesn't handle one case properly. I think I fixed that in our internal svn version, will appear on OSE svn server soon.

It's very confusing that our PXE code (which is actually a somewhat modified version of Etherboot) doesn't work, but Etherboot does. I checked the code in Etherboot 5.3.4, and it contains the same base bug (but our modification introduced another one). I'd be surprised if Etherboot worked without the DNAT hack.

The fact that you're using a 64 bit version doesn't matter, because currently the PXE ROM is only built on Linux/x86 host. So you're using the binary from svn.

Please reopen this ticket if it still doesn't work.

Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use