Although it's unlikely in practice, the guest could theoretically
reset one TCP connection then immediately start a new one with the
same addressses and ports, such that we get an RST then a SYN in the
same batch of received packets in tcp_tap_handler().
We don't correctly handle that unlikely case, because when we receive
the RST, we discard any remaining packets in the batch so we'd never
see the SYN. This could happen in either tcp_tap_handler() or
tcp_data_from_tap(). Correct that by returning 1, so that the caller
will continue calling tcp_tap_handler() on subsequent packets allowing
us to process any subsequent SYN.
Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au>
---
tcp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tcp.c b/tcp.c
index 34c27f0..a1b5a72 100644
--- a/tcp.c
+++ b/tcp.c
@@ -2337,7 +2337,7 @@ static int tcp_data_from_tap(struct ctx *c, struct tcp_tap_conn
*conn,
if (th->rst) {
conn_event(c, conn, CLOSED);
- return p->count - idx;
+ return 1;
}
len -= off;
@@ -2570,7 +2570,7 @@ int tcp_tap_handler(struct ctx *c, int af, const void *saddr, const
void *daddr,
if (th->rst) {
conn_event(c, conn, CLOSED);
- return p->count - idx;
+ return 1;
}
if (th->ack && !(conn->events & ESTABLISHED))
--
2.41.0