On 10/31/2014 04:56 PM, Michael Brown wrote:
On 30/10/14 15:31, Floris Bos wrote:
Fantastic debugging work. Could you possibly copies post the two
captures (either as attached raw .pcap files, or uploaded to
https://appliance.cloudshark.org/upload/ ?
https://www.cloudshark.org/captures/a781ff622adc
https://www.cloudshark.org/captures/0968b06118f5
Thanks!
So, the problem seems to be triggered by the delayed-ACK behaviour
from commit d28bb51 ("[tcp] Defer sending ACKs until all received
packets have been processed"). I don't think commit 18d0818 ("[tcp]
Do not send RST for unrecognised connection") should make any
difference, since there are no unrecognised connections for which a
RST could be sent within these traces.
As mentioned, the dumps are incomplete, because they were done on the
Ethernet interface of the host system.
In my test environment the host system runs two Virtualbox virtual machines:
1) the VM that is doing the network booting.
2) a VM that plays for installation server, and runs
DHCP/tftp/webserver/samba server software.
Direct communication between VM 1 and VM 2 is handled inside Virtualbox,
and does not touch the Ethernet interface of the host system, and
therefore does not appear in the earlier dumps.
I just did some more testing, and executed tcpdump on the VM that plays
installation server.
It seems iPXE does not close down the connection to the webserver it
downloads wimboot, boot.wim, etc. from properly.
I'm seeing retransmissions of the FIN,ACK packet from webserver to iPXE,
while I think iPXE is supposed to sent an ACK back as last step to close
the connection?
With the patches reversed, it sends a RST,ACK.
Unmodified HEAD:
https://www.cloudshark.org/captures/263f2e1d2b5d (last part of the
dump, as the whole dump file is over 200 MB due to it downloading boot.wim)
==
122180 54.807223 192.168.178.4 192.168.178.100 TCP
66 50651→80 [ACK] Seq=92 Ack=204501041 Win=262144 Len=0
TSval=1379129 TSecr=91537
122181 54.807367 192.168.178.4 192.168.178.100 TCP
66 50651→80 [ACK] Seq=92 Ack=204502489 Win=262144 Len=0
TSval=1379129 TSecr=91537
122182 54.807518 192.168.178.4 192.168.178.100 TCP
66 50651→80 [FIN, ACK] Seq=92 Ack=204503725 Win=262144 Len=0
TSval=1379129 TSecr=91537
122183 54.807575 192.168.178.100 192.168.178.4 TCP 66
80→50651 [FIN, ACK] Seq=204503725 Ack=93 Win=5792 Len=0 TSval=91538
TSecr=1379129
122184 55.039909 192.168.178.100 192.168.178.4 TCP 66
[TCP Retransmission] 80→50651 [FIN, ACK] Seq=204503725 Ack=93 Win=5792
Len=0 TSval=91562 TSecr=1379129
122185 55.520612 192.168.178.100 192.168.178.4 TCP 66
[TCP Retransmission] 80→50651 [FIN, ACK] Seq=204503725 Ack=93 Win=5792
Len=0 TSval=91610 TSecr=1379129
122186 55.732866 CadmusCo_23:27:ac Broadcast ARP 60 Who
has 192.168.178.99? Tell 192.168.178.4
122187 56.479844 192.168.178.100 192.168.178.4 TCP 66
[TCP Retransmission] 80→50651 [FIN, ACK] Seq=204503725 Ack=93 Win=5792
Len=0 TSval=91706 TSecr=1379129
122188 58.399843 192.168.178.100 192.168.178.4 TCP 66
[TCP Retransmission] 80→50651 [FIN, ACK] Seq=204503725 Ack=93 Win=5792
Len=0 TSval=91898 TSecr=1379129
==
With patches reversed:
https://www.cloudshark.org/captures/9dc3df8dfbca
==
153034 45.413516 192.168.178.4 192.168.178.100 TCP
66 57516→80 [ACK] Seq=92 Ack=204501041 Win=262144 Len=0
TSval=1393839 TSecr=172239
153035 45.413622 192.168.178.4 192.168.178.100 TCP
66 57516→80 [ACK] Seq=92 Ack=204502489 Win=262144 Len=0
TSval=1393839 TSecr=172239
153036 45.413717 192.168.178.4 192.168.178.100 TCP
66 57516→80 [FIN, ACK] Seq=92 Ack=204503725 Win=262144 Len=0
TSval=1393839 TSecr=172239
153037 45.413765 192.168.178.100 192.168.178.4 TCP 66
80→57516 [FIN, ACK] Seq=204503725 Ack=93 Win=5792 Len=0 TSval=172239
TSecr=1393839
153038 45.649074 192.168.178.100 192.168.178.4 TCP 66
[TCP Retransmission] 80→57516 [FIN, ACK] Seq=204503725 Ack=93 Win=5792
Len=0 TSval=172263 TSecr=1393839
153039 46.129038 192.168.178.100 192.168.178.4 TCP 66
[TCP Retransmission] 80→57516 [FIN, ACK] Seq=204503725 Ack=93 Win=5792
Len=0 TSval=172311 TSecr=1393839
153040 46.371632 CadmusCo_23:27:ac Broadcast ARP 60 Who
has 192.168.178.99? Tell 192.168.178.4
153041 46.371648 CadmusCo_23:27:ac Broadcast ARP 60 Who
has 192.168.178.100? Tell 192.168.178.4
153042 46.371653 CadmusCo_98:e8:ee CadmusCo_23:27:ac ARP
42 192.168.178.100 is at 08:00:27:98:e8:ee
153043 46.372105 192.168.178.4 192.168.178.100 TCP
60 57516→80 [RST, ACK] Seq=93 Ack=204503725 Win=0 Len=0
153044 46.372129 192.168.178.4 192.168.178.100 TCP
60 57516→80 [RST, ACK] Seq=93 Ack=204503725 Win=0 Len=0
153045 46.372133 192.168.178.4 192.168.178.100 TCP
60 57516→80 [RST, ACK] Seq=93 Ack=204503725 Win=0 Len=0
153046 85.887963 Synology_26:ac:0e Broadcast ARP 60 Who
has 192.168.178.4? Tell 192.168.178.99
153047 86.885641 Synology_26:ac:0e Broadcast ARP 60 Who
has 192.168.178.4? Tell 192.168.178.99
==
Yours sincerely,
Floris Bos
_______________________________________________
ipxe-devel mailing list
[email protected]
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
