Package: passt
Version: 0.0~git20260728.f8df3f1-1
While using rootless container networking in podman I stumbled over an
irritating issue. On nearly every usable network setup variant I get
this error message:
mash@raspi4:/tmp$ podman run --rm -ti docker.io/debian:testing
Error: pasta failed with exit code 1:
netlink: Too many routes to duplicate
Couldn't set IPv4 route(s) in guest: Argument list too long
The error is caused by some questionable code design in the passt/pasta
route duplication function resp. use of netlink commands:
https://git.uninsane.org/colin/passt/src/commit/882599e18008f2c08aa5b094bae06516f8219f3d/netlink.c#L639
The program expects that all routing table entries should fit into one
single netlink recvmsg result or trigger an error.
The allocated buffer is rather big (65536) and should cover enough
routing entries in on single transmitted datagram. But that's just
wishful thinking!
In practice, we get a sequence of much smaller batch sizes. Especially
the first chunk has always just as size of 3760 bytes on my machine and
contains not more than 56 routing entries. The subsequent chunks are
much bigger but still way smaller than the reserved buffer size:
got: 3760
got: 32436
got: 13196
got: 20
in total: 49412
Well -- this issue may affect only few people because our routing tables
are usually rather small. But that's not always the case. For example
this particular little raspi device, where I noticed this defect, works
as node in an OLSR mesh network (https://karte.ffgraz.net/). It has to
handle ~700 active routing entries to peers right now.
Sure, I know, huge routing tables are not optimal for many reasons.
Nevertheless, we should improve the current implementation of
nl_route_dup, because it's not only very limited in respect to the
actual supported number of accepted entries, it also could be rather
easily used for unpleasant denial of service attacks in rootless
container environments. Just somehow add ~55 additional routes on a
shared interface and podman can't start new service instances anymore...
I still don't know, how this issue could be fixed most suitable.
We definitely should try to receive all datagrams -- concatenate the
individual chunks or store them in an array of receive buffers for
further processing.
Yes, the current implementation also doesn't scale very well in its
workaround concerning route dependencies. It could become rather slow in
case of huge routing tables, but that's still better than the current
situation.
Thanks
Martin
