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

FIX "No such device" when adding unreachable routes for kernels >= 4.16 #19

Closed
wants to merge 1 commit into from

Conversation

christf
Copy link
Contributor

@christf christf commented Aug 12, 2018

When adding unreachable routes and setting the RTNH_F_ONLINK flag, a
device is required to be specified. In Linux kernel 4.16 support for
this flag was added https://kernelnewbies.org/LinuxChanges#Linux_4.16.Networking. Until now it was ignored.
If RTNH_F_ONLINK is specified while the device is missing, newer kernels
will respond with No such device.
The result is:

  • spam in the log file
  • missing routes for both ipv4 and ipv6

This fixes #14.

This patch will mean that for unreachable routes, ONLINK is not set but in all other cases.
I am not entirely sure why the ONLINK flag is actually needed. Setting the flag in babeld was introduced in c10a4da.
Since https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc1e64e1092f62290d59151d16f9de0210e303c8 a device is required when the flag is set.

We also need this in the unicast branch. I did direct this at the master branch because running babel on modern kernels yields a broken network due to missing routes. Also it fills the harddrive rather quickly (3gb per hour on my system) with log data. It might even be justified to consider a patch release with this.

@christf christf changed the title FIX "No such device" when adding unreachable routes for kernels > 4.16 FIX "No such device" when adding unreachable routes for kernels >= 4.16 Aug 12, 2018
@christf
Copy link
Contributor Author

christf commented Aug 12, 2018

a debian package based on master containing the patch is available here:
https://dl.ffm.freifunk.net/firmware/babel/packages/babeld/babeld_1.8.2-22-1_amd64.deb

@m13253
Copy link

m13253 commented Aug 15, 2018

Patch tested on Linux 4.17.0 and 4.14.52, network with 7 nodes.
Eliminated "no such device" errors during last 3 days.

Has anyone tested compatibility with older kernels?

@christf
Copy link
Contributor Author

christf commented Aug 17, 2018

The patch does not set the onlink flag in case the route is unreachable. As your test shows this works with kernels older as well as newer than 4.16 when the behavior changed.

@mweinelt
Copy link
Contributor

Tested on 4.17.8 and it looks like no routes go missing, the errors I mentioned in #14 don't appear anymore, yay!

@christf
Copy link
Contributor Author

christf commented Sep 5, 2018

@jech is there anything wrong with that patch?

@m13253
Copy link

m13253 commented Sep 5, 2018

@jech is there anything wrong with that patch?

It seems that @jech is just offline for half a month.

@jech
Copy link
Owner

jech commented Sep 16, 2018

Why is this line needed?

+        rtm->rtm_flags = 0;

Other than that, it looks good to me.

@m13253
Copy link

m13253 commented Sep 16, 2018

Why is this line needed?

It is used to unset RTNH_F_ONLINK flag, according to the top post.
But I think it would be better if written as:

        rtm->rtm_flags &= ~RTNH_F_ONLINK;

@jech
Copy link
Owner

jech commented Sep 16, 2018 via email

@christf
Copy link
Contributor Author

christf commented Sep 16, 2018

indeed the line should not be required. I removed the line and adjusted the coding style to match the rest of the file.

edit: I have to say though, I do like { }

When adding unreachable routes and setting the RTNH_F_ONLINK flag, a
device is required to be specified. In Linux kernel 4.16 support for
this flag was added. Until now it was ignored.
If RTNH_F_ONLINK is specified while the device is missing, newer kernels
will respond with No such device.
The result is:
* spam in the log file
* missing routes for both ipv4 and ipv6
@jech
Copy link
Owner

jech commented Sep 16, 2018

Applied to master, thanks. I'll release a 1.8.3 when I've got a chance to do some more extensive testing.

@jech jech closed this Sep 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Installed IPv6 routes are not always added to kernel routing table
4 participants