[syslinux] syslinux.efi with QEMU/OVMF

BALATON Zoltan balaton at eik.bme.hu
Wed Apr 8 04:45:13 PDT 2015


On Tue, 7 Apr 2015, Laszlo Ersek wrote:
> 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.

OK, so I've changed the test with BIOS to use gpxelinux.0 instead (hoping 
that will match the syslinux.efi case better, did not check details in the 
source yet) and that does not work either but in a different way.

The packet capture shows that gpxelinux.0 does not even try to open a the 
TCP connection to the http server. It flashes briefly:

Loading filename... Failed: No such file or directory

then returns to the menu. The file is there and lpxelinux.0 finds and 
loads it. A DNS query is sent for the server name in the http URL and gets 
a reply but the request is not made after that. (Also tried with IP 
address with the same results: no DNS query in this case but no http 
connection is tried either.)

I've also noticed that for the syslinux.efi case I had a typo in the 
config for the server name but that does not seem to do a DNS query and 
just uses the server IP address (which happened to be correct for my 
case). But syslinux.efi breaks on getting an RST from the server.

A few things seem to be broken here. Any ideas where to start debugging?

The main difference in packets shown in my previous message, apart from 
additional features due to different TCP/IP stack is the big Window size 
returned with the client's ACK. I'm not too familiar with low level TCP. 
Could this make the server drop the connection?

Regards,
BALATON Zoltan


More information about the Syslinux mailing list