On Wed, Sep 10, 2025 at 11:57:26AM +0200, Stefano Brivio wrote:
> On Wed, 10 Sep 2025 12:27:12 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Tue, Sep 09, 2025 at 08:16:54PM +0200, Stefano Brivio wrote:
> > > We currently have a number of discrepancies in the tcp_tap_handler()
> > > path between the half-closed connection path and the regular one, and
> > > they are mostly a result of code duplication, which comes in turn from
> > > the fact that tcp_data_from_tap() deals with data transfers as well as
> > > general connection bookkeeping, so we can't use it for half-closed
> > > connections.
> > > 
> > > This suggests that we should probably rework it into two or more
> > > functions, in the long term, but for the moment being I'm just fixing
> > > one obvious issue, which is the lack of fast retransmissions in the
> > > TAP_FIN_RCVD path, and a potential one, which is the fact we don't
> > > handle socket flush failures.
> > > 
> > > Add fast re-transmit for half-closed connections, and handle the case
> > > of socket flush (tcp_sock_consume()) flush failure in the same way as
> > > tcp_data_from_tap() handles it.
> > > 
> > > Signed-off-by: Stefano Brivio <sbrivio@redhat.com>  
> > 
> > Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> > 
> > > ---
> > >  tcp.c | 42 +++++++++++++++++++++++++++++++++++++++---
> > >  1 file changed, 39 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/tcp.c b/tcp.c
> > > index 9c70a25..5163dbf 100644
> > > --- a/tcp.c
> > > +++ b/tcp.c
> > > @@ -1652,6 +1652,23 @@ static int tcp_data_from_sock(const struct ctx *c, struct tcp_tap_conn *conn)
> > >  	return tcp_buf_data_from_sock(c, conn);
> > >  }
> > >  
> > > +/**
> > > + * tcp_packet_data_len() - Get data (TCP payload) length for a TCP packet
> > > + * @th:		Pointer to TCP header
> > > + * @l4len:	TCP packet length, including TCP header
> > > + *
> > > + * Return: data length of TCP packet, -1 on invalid value of Data Offset field
> > > + */
> > > +static ssize_t tcp_packet_data_len(const struct tcphdr *th, size_t l4len)
> > > +{
> > > +	size_t off = th->doff * 4UL;
> > > +
> > > +	if (off < sizeof(*th) || off > l4len)
> > > +		return -1;
> > > +
> > > +	return l4len - off;
> > > +}
> > > +
> > >  /**
> > >   * tcp_data_from_tap() - tap/guest data for established connection
> > >   * @c:		Execution context
> > > @@ -2113,9 +2130,28 @@ int tcp_tap_handler(const struct ctx *c, uint8_t pif, sa_family_t af,
> > >  
> > >  	/* Established connections not accepting data from tap */
> > >  	if (conn->events & TAP_FIN_RCVD) {
> > > -		tcp_sock_consume(conn, ntohl(th->ack_seq));
> > > -		tcp_update_seqack_from_tap(c, conn, ntohl(th->ack_seq));
> > > -		if (tcp_tap_window_update(c, conn, ntohs(th->window)))
> > > +		bool retr;
> > > +
> > > +		retr = th->ack && !tcp_packet_data_len(th, l4len) && !th->fin &&  
> > 
> > Not really in scope here, but I wonder if we should log an error
> > and/or RST if we get a non-zero data length in this situation.
> 
> According to RFC 9293 we should ignore data (note: not data segments)
> in this case, see 3.10.7.4 "Other states":
> 
>   [...]
> 
>   Seventh, process the segment text:
> 
>   [...]
> 
>   CLOSE-WAIT STATE
> 
>   This should not occur since a FIN has been received from the remote side. Ignore the segment text.
> 
>   https://www.rfc-editor.org/rfc/rfc9293.html#section-3.10.7.4-2.7.2.7.1
> 
> We could add a debug() message perhaps (in a further patch), but I don't
> think we are allowed to reset the connection.

Ok, makes sense.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson