The original Receive flow of TCP stack pass the data to upper layer while the TCP state transition and response still in progress. But when upper layer received some specific data, it might send data through the current TCP connection, or close the current TCP connection. This issue makes the TCP state hard to maintain.

After we separating the xfer interface closing routines from tcp_close, we have the opportunity to handle the TCP state, and shutdown the deliver interface at different but more suitable place.

While receiving data, we deliver the data to upper layer after we FULLY updated/handled the TCP state. So that any actions that the upper layer might do to the TCP stack would be at safer timing.

The original design of TCP stack dose not distinguish passive and active close, support is to make close action more compatible with RFC 793 and having the ability to take the advantage of release all resources when passive closing.

gPXE did not check the ACK number while receiving a response from remote server with ACK flag set. gPXE assumes the remote server ACKed the SYN/FIN sent by gPXE if ANY received a packet from remote server with ACK flag set. The error might occur when the packet is out-of-order.

If the retransmit timer was fired due to ACK to remote host and without data, we should send the latest ACK(force_send) update to remote host instead of ignoring it.

While using scripts, if the downloaded image is not bootable, the gPXE exits faster than it have the opportunity to gracefully closing the TCP connection. Which might lead the TCP state of remote server not closed.

This commit waits for TCP to fully close by polling remaining ACKs from remote server and let the gPXE reply the correct response before shutdown the xfer interface.

It is somehow hacky, hoping we can find better solution.

To reduce possible TCP port collision.