diff options
author | David Gibson <david@gibson.dropbear.id.au> | 2023-09-08 11:49:47 +1000 |
---|---|---|
committer | Stefano Brivio <sbrivio@redhat.com> | 2023-09-08 09:16:04 +0200 |
commit | 7b56117dae0f19c176d852ec7ee1f01937a994c7 (patch) | |
tree | d22540a4f9b6365413cad1bc99bd09bcaad5e08f /Makefile | |
parent | 043a70b88591777f3eb0b3597c188cfc59ed03f6 (diff) | |
download | passt-7b56117dae0f19c176d852ec7ee1f01937a994c7.tar passt-7b56117dae0f19c176d852ec7ee1f01937a994c7.tar.gz passt-7b56117dae0f19c176d852ec7ee1f01937a994c7.tar.bz2 passt-7b56117dae0f19c176d852ec7ee1f01937a994c7.tar.lz passt-7b56117dae0f19c176d852ec7ee1f01937a994c7.tar.xz passt-7b56117dae0f19c176d852ec7ee1f01937a994c7.tar.zst passt-7b56117dae0f19c176d852ec7ee1f01937a994c7.zip |
udp, tap: Correctly advance through packets in udp_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 DUP
sequence calling udp_tap_handler(). Or so it appears.
In fact, udp_tap_handler() doesn't take an index and always starts with
packet 0 of the sequence, even if called repeatedly. 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.
Correct this by adding an index parameter to udp_tap_handler() and altering
the loops in tap.c to step through the pool properly.
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