net: tcp: Remove incorrect logging of "ACK errors"

Case #1: If ACK received and our retransmit (i.e. unacked) queue is
empty, it's error. It's incorrect because TCP requires ACK to set for
every packet of established connection. For example, if we didn't
send anything to peer, but it sends us new data, it will reuse the
older ack number. It doesn't acknowledge anything new on our side,
but it's not an error in any way.

Case #2: If retransmit queue is only partially acknowledged, it's an
error. Consider that we have 2 packets in the queue, with sequence
numbers (inclusive) 100-199 and 200-399. There's nothing wrong if
we receive ACK with number 200 - it just acknowledges first packet,
we can remove and finish processing. Second packet remains in the
queue to be acknowledged later.

Fixes: zephyrproject-rtos#5504

Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>

Author: pfalcon

subsys/net/ip/tcp.c

@@ -920,11 +920,6 @@ bool net_tcp_ack_received(struct net_context *ctx, u32_t ack)
 		return false;
 	}
 
-	if (IS_ENABLED(CONFIG_NET_STATISTICS_TCP) &&
-	    sys_slist_is_empty(list)) {
-		net_stats_update_tcp_seg_ackerr();
-	}
-
 	while (!sys_slist_is_empty(list)) {
 		struct net_tcp_hdr hdr, *tcp_hdr;
 
@@ -945,7 +940,6 @@ bool net_tcp_ack_received(struct net_context *ctx, u32_t ack)
 		seq = sys_get_be32(tcp_hdr->seq) + net_pkt_appdatalen(pkt) - 1;
 
 		if (!net_tcp_seq_greater(ack, seq)) {
-			net_stats_update_tcp_seg_ackerr();
 			break;
 		}