[PATCH v2 0/2] Allow listen functions to return fds
For future forwarding changes, it makes more sense for the tcp and udp listen functions to return socket fds, rather than just success / failure. Make the change, fixing bug 186 along the way. Link: https://bugs.passt.top/show_bug.cgi?id=186 Changes in v2: * Fix several typos in comments and commit messages * Drop the --no-bindtodevice option, I was convinced it wasn't useful enough * Change from -EACCES to -EAFNOSUPPORT error code David Gibson (2): tcp, udp, conf: Don't silently ignore listens on unsupported IP versions tcp, udp: Make {tcp,udp}_listen() return socket fds conf.c | 24 +++++++++++++++++------- tcp.c | 13 ++++--------- udp.c | 10 ++++------ 3 files changed, 25 insertions(+), 22 deletions(-) -- 2.52.0
Currently, it's possible to explicitly ask for forwarding from an IPv4
address, while disabling IPv4:
$ pasta -t 192.0.2.1/12345 -6
or vice versa:
$ pasta -t 2001:db8::1/12345 -4
Currently, the impossible to implement forwarding option will be silently
ignored. That's potentially confusing since in a complex setup, it might
not be obvious why the requested forward isn't taking effect.
Specifically, it's ignored at a fairly low level: tcp_listen() and
udp_listen() ignore it and return 0. Those run kind of late to give a
good error message. Change the low-level functions to return
-EAFNOSUPPORT. Most callers of {tcp,udp}_listen() ignore the return code,
so this is a no-op for them. In the remaining caller,
conf_ports_range_except() check for the case explicitly, and provide a
meaningful error message.
Of itself, this bug is insignificant, but this is a roadblock to having
{tcp,udp}_listen() return socket fds, which in turn is a roadblock to my
flexible forwarding work. So, might as well fix it.
Link: https://bugs.passt.top/show_bug.cgi?id=186
Signed-off-by: David Gibson
{tcp,udp}_listen() currently return 0 on success, rather than the socket
fd they created. Historically, that was because these functions could
sometimes create multiple sockets. We've now refactored things to avoid
that, so it makes more sense for them to return the socket on success.
Signed-off-by: David Gibson
participants (1)
-
David Gibson