Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Looking up best route to destination #22

Open
Orycterope opened this issue Jun 15, 2023 · 2 comments · May be fixed by #23
Open

Looking up best route to destination #22

Orycterope opened this issue Jun 15, 2023 · 2 comments · May be fixed by #23

Comments

@Orycterope
Copy link

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

@Orycterope Orycterope linked a pull request Jun 16, 2023 that will close this issue
@Orycterope
Copy link
Author

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.

@pseusys
Copy link
Contributor

pseusys commented May 30, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants