[ipxe-devel] Ipxe cannot handle bigger TFTP blocksize?

Thu Jun 9 12:40:54 UTC 2011

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: tom.lauwers at ext.ec.europa.eu

________________________________

	From: jarrod.b.johnson at gmail.com [mailto:jarrod.b.johnson at gmail.com] On Behalf Of Jarrod Johnson
	Sent: Wednesday, June 08, 2011 9:25 PM
	To: LAUWERS Tom (DIGIT-EXT)
	Cc: ipxe-devel at lists.ipxe.org
	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, <Tom.LAUWERS at ext.ec.europa.eu> 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: tom.lauwers at ext.ec.europa.eu

		_______________________________________________
		ipxe-devel mailing list
		ipxe-devel at lists.ipxe.org
		https://lists.ipxe.org/mailman/listinfo/ipxe-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20110609/daa85530/attachment.htm>