Open Orycterope opened 1 year ago
I ended up looking at RouteAddRequest and NeighbourGetRequest, and had an idea for a design that I implemented in #23. Let me know if it's ok with you.
Could we please return to this issue? I think it is really useful and I also think I would be able to fix the related pull request.
I'm trying to find out the best route to a given ip destination.
Normally, I would get this information with
ip route get to 1.1.1.1
, and iproute2 obtains it by sending aRTM_GETROUTE
request with a Destination Nla of1.1.1.1
, and with only theNLM_F_REQUEST
flag set, to which the kernel responds with a single route which it found out to be the best route to the destination we specified.This crate doesn't seem to support this scenario: even though thanks to
message_mut()
the user can manually add a destination Nla to the message, callingexecute()
will always create a dump request instead, by setting the flags toNLM_F_DUMP
in the netlink header, over which the user has no control. This results in the kernel simply dumping all routes and completely ignoring the Nlas we passed.Because of this, the RouteGetRequest only supports dumping the route tables, but not actually querying them.
While it would technically be feasible for the user to simply dump all routes and filter the best one in userspace, which is what iproute2 does in
ip neigh show to 192.168.1.1
for example, it would mean implementing the same route selection algorithm the kernel uses but in userspace, which is not a trivial task and error prone. The smart thing to do here is to let the kernel do the route selection by itself.I'd be happy to add support for this, but I don't have any ideas for a good API that would fit well the current design of
RouteGetRequest
, and with the rest of the crate. Do you already have any opinion about this ?In the mean time, to work around this issue, I created a very ugly patch that checks for Nlas in the request before adding the
NLM_F_DUMP
flag: https://github.com/JustRustThings/rtnetlink/commit/87fd692d2665ab35da9ddccac1ec39fe76c7c9de