[syslinux] using http from syslinux.efi

[BALATON Zoltan]

> On Tue, Jul 7, 2015 at 10:12 AM, BALATON Zoltan via Syslinux
>> 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
>
On Tue, 7 Jul 2015, Gene Cumm wrote:
> 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.

Thanks. This is also exhibiting the problem of sending back the wrong TS 
value in the ACK reply which makes FreeBSD drop the connection but it 
seems Linux is more permissive and does not send RST for this. Here's 
another thread with the message where we have established that FreeBSD is 
likely in conformance with the relevant RFC and the bug is in whatever 
creates this ACK packet disregarding the most recently received TS value:

http://sourceforge.net/p/edk2/mailman/message/33757349/

You have not mentioned what the client is in your capture. Is it 
syslinux.efi? What UEFI implementation is it running on?

I've found that disabling rfc1323 window scaling and time stamping in 
FreeBSD makes it also succeed but with lower performance so if there's a 
way to fix this it would still be useful.

It's still not booting successfully but that's not because of failed file 
transfer now. I've found that messages printed with \n are overwriting 
each other at the bottom of the screen so I can't read them. I mean like 
this:

text menu is displayed on top of screen
below that:

Loading kernel... ok
Loading initrd1... ok\rLoading initrd2... ok\rError message 1\r
Error message 2...\rBoot aborted!

That is The first Loading kernel message is in it's own line but 
subsequent lines are overwriting each other. Is this intended? In the code 
the Loading messages and error messages have \n but only the first seems 
to be displayed others act as \r. Then the whole process starts again 
overwriting the messages again so I could not get what errors are 
displayed. Is there a way to get the error messages and prevent restarting 
the boot on failure.

Regards,
BALATON Zoltan