chiark / gitweb /
tun: add hard routes even if they are currently down.
authorSimon Tatham <anakin@pobox.com>
Tue, 27 Nov 2012 19:10:24 +0000 (19:10 +0000)
committerIan Jackson <ijackson@chiark.greenend.org.uk>
Wed, 3 Jul 2013 21:58:53 +0000 (22:58 +0100)
commitefacf9e0049ac05c817a88158d0cce5ea9d81b09
treeea83409e0c16d71940d1d399c20057c07ceb0d42
parentf23763998505b60352a2395bfae16da5cac2a978
tun: add hard routes even if they are currently down.

If a netlink is configured with OPT_SOFTROUTE, we expect to be adding
and removing the kernel routing table entry as the remote site appears
and disappears, so tun_set_route should bring the route up or down
depending on route->up. However, if it isn't, then we won't be doing
that during PHASE_RUN, and therefore we should bring the route up once
and for all at startup.

Previously the state was as follows:

secnet's 'tun' netlink will add and remove kernel routing table
entries during PHASE_RUN if the OPT_SOFTROUTE option is set.
However, at startup during PHASE_GETRESOURCES it will set up routes
for a site only if that site lists an address. So if you have a site
in your sites file with no address but also haven't enabled
OPT_SOFTROUTE (e.g. because you run secnet so that it drops privs),
then no route for that site will _ever_ be set up.

These two policies don't match. We should bring a site's route(s) up
at startup in any situation where we will not be prepared to do so
dynamically during run time. In other words, routes should be added
at startup time not only if they have a fixed address parameter, but
also if they do not have OPT_SOFTROUTE set.

(See also 04f92904ea6c41517ff7154910c16ef4c3bc646b, which seems to be
fixing the analogous bug for userv-ipif.  [
bdd4351ff2fc6dc8b1dad689f751ac46347636cf which seems to be the
relevant later commit is in fact empty -iwj. ]

This commit implements this fix, and causes my home secnet
implementation to be able to route to my laptop successfully
(sgo/resolution/resolution). In order to do this I've had to move the
definition of OPT_SOFTROUTE out of netlink.c into netlink.h so that
tun_set_route can see it, which suggests a possible layering
violation, but on the other hand since the netlink_client structure is
visible outside netlink.c it seems only reasonable that the bit flags
used in its 'options' field should be visible too.

Signed-off-by: Simon Tatham <anakin@pobox.com>
netlink.c
netlink.h
tun.c