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? Regards, BALATON Zoltan
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
> 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