[syslinux] using http from syslinux.efi

[Gene Cumm]

On Tue, Jul 7, 2015 at 10:12 AM, BALATON Zoltan via Syslinux
<syslinux at zytor.com> wrote:
> Hello,
>
> I'm trying to use http from syslinux.efi but it fails while trying to
> establish the connection to a FreeBSD http server. A packet capture shows:
>
> TCP healthd > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=1094
> TSecr=0
> TCP http > healthd [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=64
> TSval=1596927428 TSecr=1094
> TCP healthd > http [ACK] Seq=1 Ack=1 Win=2097152 Len=0 TSval=1094 TSecr=0
> TCP http > healthd [RST] Seq=1 Win=0 Len=0
>
> This is very similar to what we have debugged before with OVMF that was
> caused by incorrect timestamp value in reply and fixed for OVMF with the
> patch mentioned here:
>
> http://www.syslinux.org/archives/2015-April/023402.html
>
> (The debugging we did that time can be found going back in that thread.)
>
> Now I've met this on real hardware where the UEFI implementation may be
> buggy and I cannot fix that. I've already tried to update to latest
> available firmware but that did not help.
>
> Is there any other possibility to have syslinux.efi use another tcp stack
> that may work better and not exhibit this problem or what component is
> setting the TSVal in the ACK reply packet here? I assume it's part of the
> firmware as it is the same as was for OVMF.
>
> Using tftp is not an option as it takes forever to download a 100+ MB image
> and it does not work either as it gets stuck after a while for yet unknown
> reasons. Another option may be to find a less picky http server that accepts
> the wrong reply anyway, but not sure that exists. Has anyone had success
> with syslinux.efi and http?

IP client.1266 > server.http: Flags [S], seq 1212699493, win 65535,
options [mss 1460,nop,wscale 6,nop,nop,TS val 1037 ecr 0], length 0
IP server.http > client.1266: Flags [S.], seq 1355106653, ack
1212699494, win 28960, options [mss 1460,nop,nop,TS val 24566825 ecr
1037,nop,wscale 7], length 0
IP client.1266 > server.http: Flags [.], ack 1, win 32768, options
[nop,nop,TS val 1037 ecr 0], length 0
IP client.1266 > server.http: Flags [.], seq 1:274, ack 1, win 32768,
options [nop,nop,TS val 1037 ecr 0], length 273
IP server.http > client.1266: Flags [.], ack 274, win 235, options
[nop,nop,TS val 24566825 ecr 1037], length 0
IP server.80 > client.1266: Flags [.], seq 1:1449, ack 274, win 235,
options [nop,nop,TS val 24566825 ecr 1037], length 1448
IP server.80 > client.1266: Flags [.], seq 1449:2897, ack 274, win
235, options [nop,nop,TS val 24566825 ecr 1037], length 1448
IP server.80 > client.1266: Flags [.], seq 2897:4345, ack 274, win
235, options [nop,nop,TS val 24566825 ecr 1037], length 1448
IP server.80 > client.1266: Flags [.], seq 4345:5793, ack 274, win
235, options [nop,nop,TS val 24566825 ecr 1037], length 1448
IP server.80 > client.1266: Flags [.], seq 5793:7241, ack 274, win
235, options [nop,nop,TS val 24566825 ecr 1037], length 1448
IP server.80 > client.1266: Flags [.], seq 7241:8689, ack 274, win
235, options [nop,nop,TS val 24566825 ecr 1037], length 1448
IP client.1266 > server.80: Flags [.], ack 2897, win 32768, options
[nop,nop,TS val 1037 ecr 24566825], length 0

This is the decode of the beginning of a quite successful transfer
that was over 50 MiB with a Linux box.

-- 
-Gene