Some users might want to prefer one babel implementation over another
for various reasons. Having to compile the firmware from scratch can be
quite tedious in that case.
Instead, make the babel implementation switchable at runtime.
The implementation can be switched manually using the uci option
`babelimpl.impl.impl`, which currently is not upgrade-safe.
Signed-off-by: Fabian Bläse <fabian@blaese.de>
Acked-by: Christian Dresel <freifunk@dresel.systems>
To be able to swap out babeld for a different babel implementation in
the future, this splits all fff-specific configuration into a seperate
fff-babel package.
Implementation specific configuration is done in
/lib/functions/fff/babeldaemon, which is included with every selectable
babel implementation. It contains functions, which are called by the
fff-specific code, and therefore allows to configure the implementation
specific parts.
The babel implementation is provided by implementation-specific
fff-packages, which provide 'fff-babel-implementation'. At the moment,
only fff-babeld is supported for use as babel implementation.
Signed-off-by: Fabian Bläse <fabian@blaese.de>
Acked-by: Christian Dresel <freifunk@dresel.systems>
If a prefix is used for a client interface utilizing snat, it shall
not be publicly reachable, so it can be reused across multiple routers.
To prevent such prefixes from leaking, create appropriate babel filters
if snat is used.
Fixes: #196
Signed-off-by: Fabian Bläse <fabian@blaese.de>
Reviewed-by: Christian Dresel <freifunk@dresel.systems>
The removal of CIDR masks from ip addresses is changed to utilize
variable substitutions, which simplifies the expression.
Signed-off-by: Fabian Bläse <fabian@blaese.de>
Reviewed-by: Johannes Kimmel <fff@bareminimum.eu>
The router_ip option can be a list of multiple ip addresses. It is also
possible to specify a subnet using a CIDR mask.
Only a single ip is required for peering interfaces, so select only the
first list entry and remove the CIDR mask.
Fixes: #197
Signed-off-by: Fabian Bläse <fabian@blaese.de>
For some purposes (e.g. SNAT, vxlan) it might be necessary to have an
additional address just for the router which is not attached to any
interfaces. Addresses like this are typically added to the loopback
interface.
The new options "router_ip" and "router_ip6" are added to the gateway
config to allow the user to configure such addresses. It is possible to
both specify the address with or without a subnet size.
The default configuration contains the IPv4 loopback address
(127.0.0.1/8) explicitly, but this is not necessary. These addresses are
configured automatically, even if they are not present in the
configuration, so they can safely be removed, if present.
The filters of our routing daemon babeld are adjusted accordingly, so
the newly added addresses are announced correctly.
Signed-off-by: Fabian Bläse <fabian@blaese.de>
Reviewed-by: Christian Dresel <freifunk@dresel.systems>
Reviewed-by: Johannes Kimmel <fff@bareminimum.eu>
When neither peer_ip nor ipaddr are set, no ipv4 address for peering
interfaces is available. Therefore, no IPv4 routes can be advertised.
Other than that, a configuration like this is perfectly valid and
configuration is already continued. Therefore, the "FATAL" message might
be misleading so it is replaced with "WARNING" and clarified slightly.
Signed-off-by: Fabian Bläse <fabian@blaese.de>
Reviewed-by: Johannes Kimmel <fff@bareminimum.eu>
[bump PKG_RELEASE]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
babeld filters routes before announcing them with the
redistribute filters.
Users might add unknown public subnets to the client interface,
so redistribute filters have to be generated for these addresses.
Signed-off-by: Fabian Bläse <fabian@blaese.de>
Reviewed-by: Robert Langhammer <rlanghammer@web.de>
Tested-by: Fabian Bläse <fabian@blaese.de>
Various things have to be done for every interface on
which babeld shall run.
Those procedures are moved into functions to reduce duplicate code.
Signed-off-by: Fabian Bläse <fabian@blaese.de>
Reviewed-by: Robert Langhammer <rlanghammer@web.de>