[syslinux] syslinux.efi with QEMU/OVMF

[Laszlo Ersek]

On 04/08/15 13:45, BALATON Zoltan wrote:
> 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?

Add a debug message to a function that you know you reach, and another
to a function that you'd like to, but aren't. Then close the gap with
further debug messages.

> 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.

Yes, I've noticed.

> I'm not too familiar with low level TCP.
> Could this make the server drop the connection?

I could only answer this by looking up the appropriate ietf RFC / STD
and/or checking the server side code. Which you can do too. :)

Laszlo