Data corruption - tcp packets dropped in the receive path #93
Description
Note: the issue was created automatically with bugzilla2github tool
Bugzilla Bug ID: 93
Date: 2016-09-06 23:27:23 +0200
From: Jason Preston <jpreston@infinite.io>
To: openfastpath@list.openfastpath.org
CC: sorin.vultureanu@enea.com
Last updated: 2016-12-09 10:07:16 +0100
Bugzilla Comment ID: 177
Date: 2016-09-06 23:27:23 +0200
From: Jason Preston <jpreston@infinite.io>
Using v1.1
I've hit a problem where data received in a tcp connection is silently dropped. It occurs when the socket so_rcv doesn't have room to hold the new socket. In this case ofp_sockbuf_put_last() fails and drops the packet, returning -1. This return code is not propagated back up because ofp_sbcompress returns void. The caller (ofp_tcp_do_segment, ofp_tcp_reass, etc) generates an ACK for the data that was dropped.
So the data is correct on the wire and is acknowledged, but there are gaps in the stream coming out of ofp_recv. I have confirmed that the gaps correspond to times when I see messages like this on the console:
E 4970 2:4044535552 ofp_uipc_sockbuf.c:132] No more room, next=14
Bugzilla Comment ID: 209
Date: 2016-11-22 16:17:45 +0100
From: Jason Preston <jpreston@infinite.io>
Created attachment 11
Proposed fix
I had previously submitted this patch to the mailing list. It adds a check for space before trying to add to the so_rcv sockbuf. If there is no space the packet is dropped and not acked.
Attached file: ofp_rx.patch (text/plain, 4952 bytes)
Description: Proposed fix
Bugzilla Comment ID: 217
Date: 2016-12-09 10:07:16 +0100
From: Sorin Vultureanu <sorin.vultureanu@enea.com>
tcp: Fix data dropped when receive sockbuf is full.
Packets can be dropped if the receive sockbuf is full.
This happens after data has been acked.
Socket buffer space check was added before trying to add data to the sockbuf.
If there is no space the packet is dropped and ack the previous data to trigger
a retransmit.
Fixes: #93 Data corruption - tcp packets dropped in the receive path
Patch-by: Jason Preston jpreston@infinite.io
Signed-off-by: Sorin Vultureanu Sorin.Vultureanu@enea.com
Reviewed-by: Jere Leppänen jere.leppanen@nokia.com