Hello,
i think uIP v1.0 is not able to handle the case of an simultaneous
close of a TCP connection. Since I a have pretty high latency for my
connections this case happens quite often.
Here is an example logged at the uip side of the connection:
x+0 peer -> uip (some data) next_seq=204, ack=703
x+1 uip -> peer FIN,ACK seq=703, ack=204
x+2 peer -> uip FIN,ACK seq=204, ack=703
x+3 uip -> peer ACK seq=703, ack=205
x+4 peer -> uip FIN,ACK seq=204, ack=704
x+5 uip -> peer ACK seq=703, ack=205
...
At x+3 uip thinks that the sequence number is wrong and sends an ACK
with the "right" numbers, but it should just go into CLOSING state and
send a seq+1 and ack+1.
I use the following patch, which works for me and seems to do what the
RFC wants, though i am not really an TCP/IP expert.
if(!(((uip_connr->tcpstateflags & UIP_TS_MASK) == UIP_SYN_SENT) &&
((BUF->flags & TCP_CTL) == (TCP_SYN | TCP_ACK)))) {
if((uip_len > 0 || ((BUF->flags & (TCP_SYN | TCP_FIN)) != 0)) &&
(BUF->seqno[0] != uip_connr->rcv_nxt[0] ||
BUF->seqno[1] != uip_connr->rcv_nxt[1] ||
BUF->seqno[2] != uip_connr->rcv_nxt[2] ||
BUF->seqno[3] != uip_connr->rcv_nxt[3])) {
+ // TODO: hotfix for "simultaneous close" problem
+ if ((uip_connr->tcpstateflags & UIP_TS_MASK) == UIP_CLOSING) {
+ // assume: BUF->seqno == uip_connr->rcv_nxt + 1
+ uip_add_rcv_nxt(1);
+ //uip_connr->tcpstateflags = UIP_TIME_WAIT;
+ } else
+ // end hotfix
goto tcp_send_ack;
}
}
Beside that there is another thing i don't understand. If the
retransmission timer expires and the connection is in UIP_CLOSING
state, a FINACK will be sent. I think it should be ACK only?!
Regards,
Olaf
