Opened 17 years ago
Closed 17 years ago
#284 closed defect (fixed)
PXE tries to boot from wrong server
| Reported by: | abma | Owned by: | |
|---|---|---|---|
| Component: | other | Version: | VirtualBox 1.3.8 |
| Keywords: | pxe boot netboot next | Cc: | |
| Guest type: | other | Host type: | other |
Description
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 (5)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
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 by , 17 years ago
http://abma.de/tmp/captured.wireshark
i've added a iptables rule which dnats 71.4.128.0 to the right ftp server. this is why the tftp connection starts (71.4.128.0 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 by , 17 years ago
i've found a workaround:
with a bootable etherboot iso-image pxebooting is possible.
(nic is pcnet32:pcnet32 0x1022, 0x2000)
comment:5 by , 17 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
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: the port is wrong too, the port should be: 69, but it in is 4011 (read from wireshark)