[syslinux] syslinux.efi with QEMU/OVMF
Laszlo Ersek
lersek at redhat.com
Wed Apr 8 04:56:10 PDT 2015
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
More information about the Syslinux
mailing list