[syslinux] syslinux.efi with QEMU/OVMF

Laszlo Ersek lersek at redhat.com
Tue Apr 7 13:53:20 PDT 2015


On 04/07/15 19:22, BALATON Zoltan wrote:
> Hello,
> 
> I'm trying to find out how to pxe boot with syslinux.efi on QEMU with
> OVMF. After getting through the initial hurdle caused by the iPXE based
> option ROM included with QEMU having a problem as described in these
> threads:
> 
> http://www.syslinux.org/archives/2014-November/022804.html
> http://sourceforge.net/p/edk2/mailman/message/33236100/
> 
> I'm now getting further to almost being able to boot but still not quite.
> 
> To eliminate further variables I'm now using the suggested
> virtio-net-pci with romfile= option to disable any iPXE code and only
> use code included in OVMF and syslinux.
> 
> Where I'm stuck now is that syslinux.efi fails when trying to download a
> file from http. This fails with the efi version but works with the same
> PXE/HTTP server and QEMU client not using OVMF and instead of
> syslinux.efi using lpxelinux.0. Looking at packet captures show that the
> connection is closed by the server after establishment with syslinux.efi.
> 
> This is the http connection with BIOS and lpxelinux.0:
> 
> TCP 49153 > http  [SYN] Seq=0 Win=64000 Len=0 MSS=1460
> TCP  http > 49153 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460
> TCP 49153 > http  [ACK] Seq=1 Ack=1 Win=64000 Len=0
> HTTP GET /boot HTTP/1.0
> 
> with http transfer commencing normally after this, while with OVMF and
> syslinux.efi I get the following:
> 
> TCP 1654 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=1039
> TSecr=0
> TCP http > 1654 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=64
> TSval=1151334911 TSecr=1039
> TCP 1654 > http [ACK] Seq=1 Ack=1 Win=2097152 Len=0 TSval=1039 TSecr=0
> TCP http > 1654 [RST] Seq=1 Win=0 Len=0
> HTTP GET /boot HTTP/1.0
> 
> with data packets sent by the http server getting RST replies after this
> presumably due to socket closed in reply to the RST packet from the
> server. I see different options and values used in the EFI case but I
> don't know where these are coming from and if they are causing the
> problem. Does anyone have an understanding what happens or any hints
> what to look for?
> 
> If I try tftp instead it can transfer some files but is very slow
> (slower than it should be as it is faster with the BIOS version) and
> still cannot successfully boot with the transfer ending unexpectedly
> before finishing. (I saw similar reports on the mailing lists with HP
> and Dell hardware but I'm not sure they are related.)
> 
> Any help is greatly appreciated.

As far as I can see (... well, guess), lpxelinux.0 uses the TCP
implementation under core/lwip/, which doesn't support TCP timestamps.

Whereas syslinux.efi apparently uses the embedded gpxe/ tree, and that
one uses TCP timestamps. See tcp_xmit() in gpxe/src/net/tcp.c:

	if ( ( flags & TCP_SYN ) || tcp->timestamps ) {
		tsopt = iob_push ( iobuf, sizeof ( *tsopt ) );
		memset ( tsopt->nop, TCP_OPTION_NOP, sizeof ( tsopt->nop ) );
		tsopt->tsopt.kind = TCP_OPTION_TS;
		tsopt->tsopt.length = sizeof ( tsopt->tsopt );
		tsopt->tsopt.tsval = ntohl ( currticks() );
		tsopt->tsopt.tsecr = ntohl ( tcp->ts_recent );
	}

(When opening the connection, the TCP_SYN flag is set (from tcp_open() I
guess?).)

So, the two builds use different TCP stacks on the client side.

(Obviously I have no clue, but this is what I could gather in five minutes.)

Laszlo


More information about the Syslinux mailing list