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

[Jarrod Johnson]

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/20110608/0aba0bb6/attachment.htm>