Hello, Bringing back this conversation to this list as it seems to be within the edk2 code now.
I've found that syslinux.efi fails when trying to download a file from http. This fails with the efi version but works with the same PXE/HTTP server and QEMU client not using OVMF and syslinux.efi but using BIOS and lpxelinux.0 instead. Looking at packet captures show that the connection is closed by the server after establishment with syslinux.efi. This is the http connection with BIOS and lpxelinux.0: TCP 49153 > http [SYN] Seq=0 Win=64000 Len=0 MSS=1460 TCP http > 49153 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 TCP 49153 > http [ACK] Seq=1 Ack=1 Win=64000 Len=0 HTTP GET /boot HTTP/1.0 with http transfer commencing normally after this, while with OVMF and syslinux.efi I get the following: TCP 1654 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=1039 TSecr=0 TCP http > 1654 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=64 TSval=1151334911 TSecr=1039 TCP 1654 > http [ACK] Seq=1 Ack=1 Win=2097152 Len=0 TSval=1039 TSecr=0 TCP http > 1654 [RST] Seq=1 Win=0 Len=0 These two syslinux versions use different TCP/IP stacks with syslinux.efi using the UEFI provided implementation via these functions: http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/efi/tcp.c which for OVMF seems to be the one in MdeModulePkg/Universal/Network/Tcp4Dxe Besides different options and values used in the EFI case I think the problem might be the increased Window value in the ACK reply which may be too early. The remote side is Apache on FreeBSD so it's unlikely to have any serious bugs in its TCP implementation, on the other hand TcpComputeWnd() in Tcp4Output.c has a comment suggesting the initial window should not be scaled and tries to avoid it by checking if we are in a SYN phase. I've enabled debug messages in OVMF and added another to TcpTransmitSegment() in Tcp4Output.c. this is what I've got: Tcb (3F296898) state TCP_CLOSED --> TCP_SYN_SENT TcpTransmitSegment: for TCB 3F296898, Seq -664267473, Syn 1, Wnd 65535 TcpToSendData: set RTT measure sequence 789932248 for TCB 3F296898 Tcb (3F296898) state TCP_SYN_SENT --> TCP_ESTABLISHED TcpComputeRtt: new RTT for TCB 3F296898 computed SRTT: 0 RTTVAR: 0 RTO: 5 TcpInput: connection established for TCB 3F296898 in SYN_SENT TcpTransmitSegment: for TCB 3F296898, Seq -647490257, Syn 0, Wnd 128 TcpInput: connection reset for TCB 3F296898 Tcb (3F296898) state TCP_ESTABLISHED --> TCP_CLOSED Tcb (3F296898) state TCP_CLOSED --> TCP_CLOSED Seq and Wnd numbers may be byte swapped or truncated because I did not figure out what is in network and what is in host byte order but the correct values can be seen from the packet capture above. Is it possible that there's a bug here computing the window size which should not be changing before we receive the ACK from the remote end? Could it be that the state is transitioned to ESTABLISHED too early or just looking at the Syn flag is not enough? I'm not familiar with EDK2 and TCP at such a low level so any insight from someone knowing these better would be appreciated. I can try coming up with a fix if someone can hint at what should be done and approximately where in the code. Thank you, BALATON Zoltan ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
