[ipxe-devel] Windows having problems parsing iBFT from recent iPXE versions?

Fri Oct 31 22:07:35 UTC 2014

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