Jarrod,
while HTTP/FTP would certainly work much better than TFTP, I guess that the MS
bootmanager uses the iPXE-provided API to send/receive TFTP traffic (as it
doesn't implement it's own network adapter driver and I guess it uses the BOOT
ROM's IP-stack as well).
So something must get lost. The TFTP response doesn't get back to the MS
bootmgr (or maybe just the first packet and no additional packets in the same
frame - not sure if I use the correct terminology here).
Is the maximum buffer size that iPXE can handle documented somwhere. Is there a
source file (eg a constant) I could alter to increase the buffer and allow it
to accept 8K TFTP-messages (TFTP-responses)?
On a side note:
It would certainly be a nice feature if iPXE could intercept the TFTP-request
of the MS bootmgr and translate it to a HTTP/FTP URI, download the file and
return it to the bootmgr as if it was coming from a TFTP server. It would allow
any TFTP-aware boot manager to boot from any media, provided there's a
translation implemented at iPXE level (eg. by a user-provided script).
Best regards,
Bien à Vous,
Tom Lauwers
DIGIT A.2-002 Desktop, Peripherals & Mobile Solutions
Siemens
Office: B-28 03/030
Tel. (+32-2)[29]51649 - Fax. (+32-2)[29]50164
E-mail: [email protected]
________________________________
From: [email protected] [mailto:[email protected]] On
Behalf Of Jarrod Johnson
Sent: Wednesday, June 08, 2011 9:25 PM
To: LAUWERS Tom (DIGIT-EXT)
Cc: [email protected]
Subject: Re: [ipxe-devel] Ipxe cannot handle bigger TFTP blocksize?
Probably useless 'advice', but if MS would kindly detect the existance
of and use iPXE's http/ftp capable APIs, that'd be the best solution.
On Wed, Jun 8, 2011 at 5:15 AM, <[email protected]> wrote:
Dear iPXE developers,
I'm having the following problem with iPXE; I'm using the
bootable ISO that I burned to a CD-ROM.
I'm booting WinPE over PXE. This works when I'm using a DHCP
server on a local subnet (on which I can set the correct scope options), but
due to security policies I cannot set DHCP scope options on the rest of the
network. So the objective is to boot iPXE from CD-ROM or USB-key with an
embedded script that simply executes:
dhcp
set next-server x.x.x.x
imgfetch /Boot/pxeboot.n12
boot pxeboot.n12
I tested this and it works well. It doesn't work anymore though
when I increase the TFTP block size within the BCD config (so Microsoft's
bootmgr.exe will request bigger chunks of data from the TFTP-server).
Our TFTP-server must be reached over a WAN (cross-country), so
TFTP-throughput is very slow (inherent of the protocol, since it's UDP and
every packet needs to be acknowledged). On all of our PC's on the local subnet
(using DHCP scope options and the BOOT ROM of the NIC, so not iPXE) it works
well when I increase tftpblocksize to 8K and download time of a standard WinPE
image drops from 10 minutes to 1,5 minute; which is great. But iPXE is unable
to handle this kind of TFTP-traffic.
Here's the script that I use to create the BCD config:
set BCD-File=C:\TFTP-ROOT\Boot\BCD
del %BCD-File%
Bcdedit /createstore %BCD-File%
Bcdedit /store %BCD-File% /create {ramdiskoptions}
Bcdedit /store %BCD-File% /set {ramdiskoptions}
ramdisksdidevice boot
Bcdedit /store %BCD-File% /set {ramdiskoptions}
ramdisksdipath \boot\boot.sdi
---> Bcdedit /store %BCD-File% /set {ramdiskoptions}
ramdisktftpblocksize 1432
Bcdedit /store %BCD-File% /set {ramdiskoptions}
ramdisktftpwindowsize 2
Set guid={10000000-1000-1000-1000-100000000000}
Bcdedit /store %BCD-File% /create %guid% /d "WinPE
PXE-boot image" /application osloader
Bcdedit /store %BCD-File% /set %guid% systemroot
\Windows
Bcdedit /store %BCD-File% /set %guid% detecthal Yes
Bcdedit /store %BCD-File% /set %guid% winpe Yes
Bcdedit /store %BCD-File% /set %guid% osdevice
ramdisk=[boot]\Boot\winpe_x86.wim,{ramdiskoptions}
Bcdedit /store %BCD-File% /set %guid% device
ramdisk=[boot]\Boot\winpe_x86.wim,{ramdiskoptions}
Bcdedit /store %BCD-File% /create {bootmgr} /d "Lite
Touch Installation"
Bcdedit /store %BCD-File% /set {bootmgr} timeout 1
Bcdedit /store %BCD-File% /set {bootmgr} displayorder
%guid%
This works, but is very slow. So I replace line 7 with:
Bcdedit /store %BCD-File% /set {ramdiskoptions}
ramdisktftpblocksize 8192
Now it still works on pc's using the internal NIC's PXE-boot
code (and it's much faster), but it doesn't work anymore with iPXE.
My guess is that iPXE cannot handle TFTP-responses that are
spread over multiple ethernet frames. 1432 bytes works well because with
overhead it's lower than the MTU (1500 bytes). But when the TFTP-server sends 2
or more UDP packets (to send a bigger block of data, requiring less
acknowledgements), these somehow get lost.
Any ideas? Thanks a lot in advance.
Best regards,
Bien à Vous,
Tom Lauwers
DIGIT A.2-002 Desktop, Peripherals & Mobile Solutions
Siemens
Office: B-28 03/030
Tel. (+32-2)[29]51649 - Fax. (+32-2)[29]50164
E-mail: [email protected]
_______________________________________________
ipxe-devel mailing list
[email protected]
https://lists.ipxe.org/mailman/listinfo/ipxe-devel
_______________________________________________
ipxe-devel mailing list
[email protected]
https://lists.ipxe.org/mailman/listinfo/ipxe-devel
