[PATCH v2 0/5] Assorted small fixes for UDP
Partly in looking at flow table support, partly for other reasons, I've spotted a number of small fixes that can be made to the UDP code (in addition to the large fixes I'm still working on). These are ready to go now, so here they are. They'll go before the flow related addressing cleanups. Changes since v1: * Removed patch to unconditionally remove ACT flags, which was Just Plain Wrong. * Removed patch to sort out incorrect handling of port flags. While there's a real bug there, it interacts with at least two more bugs that I hadn't spotted, complicating the picture. I'll fix those some other day. David Gibson (5): udp: Don't attempt to translate a 0.0.0.0 source address udp: Set pif in epoll reference for ephemeral host sockets udp: Small streamline to udp_update_hdr4() udp: Fix incorrect usage of IPv6 state in IPv4 path udp: Remove unnecessary test for unspecified addr_out udp.c | 39 ++++++++++++++++++++++----------------- 1 file changed, 22 insertions(+), 17 deletions(-) -- 2.43.2
If an incoming packet has a source address of 0.0.0.0 we translate that to
the gateway address. This doesn't really make sense, because we have no
way to do a reverse translation for reply packets.
Certain UDP protocols do use an unspecified source address in some
circumstances (e.g. DHCP). These generally either require no reply, a
multicast reply, or provide a suitable reply address by other means.
In none of those cases does translating it in passt/pasta make sense. The
best we can really do here is just leave it as is.
Signed-off-by: David Gibson
The udp_epoll_ref contains a field for the pif to which the socket belongs.
We fill this in for permanent sockets created with udp_sock_init() and for
spliced sockets, however, we omit it for ephemeral sockets created for
tap originated flows.
This is a bug, although we currently get away with it, because we don't
consult that field for such flows. Correctly fill it in.
Signed-off-by: David Gibson
Streamline the logic here slightly, by introducing a 'src' temporary for
brevity. We also transform the logic for setting/clearing PORT_LOOPBACK.
This makes udp_update_hdr4() more closely match the corresponding logic
from udp_update_udp6().
Signed-off-by: David Gibson
When forwarding IPv4 packets in udp_tap_handler(), we incorrectly use an
IPv6 address test on our IPv4 address (which could cause an out of bounds
access), and possibly set our bind interface to the IPv6 interface based on
it. Adjust to correctly look at the IPv4 address and IPv4 interface.
Signed-off-by: David Gibson
If the configured output address is unspecified, we don't set the bind
address to it when creating a new socket in udp_tap_handler(). That sounds
sensible, but what we're leaving the bind address as is, exactly, the
unspecified address, so this test makes no difference. Remove it.
Signed-off-by: David Gibson
On Wed, 28 Feb 2024 16:39:24 +1100
David Gibson
Partly in looking at flow table support, partly for other reasons, I've spotted a number of small fixes that can be made to the UDP code (in addition to the large fixes I'm still working on).
These are ready to go now, so here they are. They'll go before the flow related addressing cleanups.
Changes since v1: * Removed patch to unconditionally remove ACT flags, which was Just Plain Wrong. * Removed patch to sort out incorrect handling of port flags. While there's a real bug there, it interacts with at least two more bugs that I hadn't spotted, complicating the picture. I'll fix those some other day.
David Gibson (5): udp: Don't attempt to translate a 0.0.0.0 source address udp: Set pif in epoll reference for ephemeral host sockets udp: Small streamline to udp_update_hdr4() udp: Fix incorrect usage of IPv6 state in IPv4 path udp: Remove unnecessary test for unspecified addr_out
Applied. -- Stefano
participants (2)
-
David Gibson
-
Stefano Brivio