[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