diff options
author | David Gibson <david@gibson.dropbear.id.au> | 2023-09-08 11:49:46 +1000 |
---|---|---|
committer | Stefano Brivio <sbrivio@redhat.com> | 2023-09-08 09:15:46 +0200 |
commit | 043a70b88591777f3eb0b3597c188cfc59ed03f6 (patch) | |
tree | cb76b07c0feb5107caaea5105b445af22e63787f /Makefile | |
parent | ee58f37db060535bee298bc98f61497eac37f152 (diff) | |
download | passt-043a70b88591777f3eb0b3597c188cfc59ed03f6.tar passt-043a70b88591777f3eb0b3597c188cfc59ed03f6.tar.gz passt-043a70b88591777f3eb0b3597c188cfc59ed03f6.tar.bz2 passt-043a70b88591777f3eb0b3597c188cfc59ed03f6.tar.lz passt-043a70b88591777f3eb0b3597c188cfc59ed03f6.tar.xz passt-043a70b88591777f3eb0b3597c188cfc59ed03f6.tar.zst passt-043a70b88591777f3eb0b3597c188cfc59ed03f6.zip |
tcp, tap: Correctly advance through packets in tcp_tap_handler()
In both tap4_handler() and tap6_handler(), once we've sorted incoming l3
packets into "sequences", we then step through all the packets in each TCP
sequence calling tcp_tap_handler(). Or so it appears.
In fact, tcp_tap_handler() doesn't take an index and always looks at packet
0 of the sequence, except when it calls tcp_data_from_tap() to process
data packets. It appears to be written with the idea that the struct pool
is a queue, from which it consumes packets as it processes them, but that's
not how the pool data structure works - they are more like an array of
packets.
We only get away with this, because setup packets for TCP tend to come in
separate batches (because we need to reply in between) and so we only get
a bunch of packets for the same connection together when they're data
packets (tcp_data_from_tap() has its own loop through packets).
Correct this by adding an index parameter to tcp_tap_handler() and altering
the loops in tap.c to step through the pool properly.
Link: https://bugs.passt.top/show_bug.cgi?id=68
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions