You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 a RTM_GETROUTE request with a Destination Nla of 1.1.1.1, and with only the NLM_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, calling execute() will always create a dump request instead, by setting the flags to NLM_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: JustRustThings@87fd692
The text was updated successfully, but these errors were encountered:
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.
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: JustRustThings@87fd692The text was updated successfully, but these errors were encountered: