aboutgitcodebugslistschat
path: root/Makefile
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2023-09-08 11:49:47 +1000
committerStefano Brivio <sbrivio@redhat.com>2023-09-08 09:16:04 +0200
commit7b56117dae0f19c176d852ec7ee1f01937a994c7 (patch)
treed22540a4f9b6365413cad1bc99bd09bcaad5e08f /Makefile
parent043a70b88591777f3eb0b3597c188cfc59ed03f6 (diff)
downloadpasst-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