A recent change (b26399283a) introduced an upper limit for the preferred
and valid lifetimes, so the statically configured addresses on the client
interface do not result in infinite lifetimes.
This upper bound is derived from the dhcp lease time. However, the
preferred lifetime is unexpectedly bound by an explicit configuration
option in recent versions of odhcpd. Due to our short dhcp leasetime,
the default value of this option is higher than the lease time, which
results preferred lifetimes longer than the valid lifetime.
As this behavior is rather unintuitive, a proper fix for it should be
done upstream (see #238). Until then, lower the preferred lifetime
option to the same value as our leasetime.
Signed-off-by: Fabian Bläse <fabian@blaese.de>
Reviewed-by: Christian Dresel <freifunk@dresel.systems>
When advertising network prefixes gathered from the interface, odhcpd
sets the preferred and valid lifetime of those prefixes in the router
advertisement to the values set for those addresses on the interface.
When prefixes are configured statically (as done in our firmware), this
means that odhcp announces these prefixes for SLAAC with infinite
preferred and valid lifetimes.
While this does not seem like a problem at first, it hurts significantly
when configuration errors are made or cables are plugged into the wrong
ports, because those addresses never vanish from devices anymore, as long
as they are powered up. Also, it makes it impossible to change prefixes
without gracefully shutting down the RA server, so it can announce zero
lifetimes for previously announced prefixes.
Sadly, odhcp does not have an option to configure these lifetimes
explicitly, but it is possible to limit these lifetimes to the lease
time configured and used for the DHCP functionality of odhcpd.
Enable the appropriate 'ra_useleasetime' option to reduce impact of the
before mentioned problems.
Fixes: #142
Signed-off-by: Fabian Bläse <fabian@blaese.de>
Reviewed-by: Christian Dresel <freifunk@dresel.systems>
Reviewed-by: Robert Langhammer <rlanghammer@web.de>
The name br-mesh is actually quite misleading, since the bridge
actually includes the "client" interfaces. In order to make this
obvious, and to prevent confusion with the properly named wXmesh
interfaces, rename them to br-client.
Note that br-mesh is also particularly disturbing for the layer 3
firmware without batman-adv.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Acked-by: Fabian Bläse <fabian@blaese.de>
Acked-by: Christian Dresel <freifunk@dresel.systems>
Reviewed-by: Robert Langhammer <rlanghammer@web.de>
uci-defaults scripts are supposed to be run once after firstboot
and then removed. However, the removal only takes place if the
subshell created for the sourced scripts returns exit code 0.
For some of the files, the last command returned a different exit
code, though, leading to the script remaining in its location and
being executed for every boot.
To prevent cases like the latter, this adds an "exit 0" to all
uci-defaults files in our package store. While at it, remove the
shebang for all these files since they are sourced (and not
executed).
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Reviewed-by: Fabian Bläse <fabian@blaese.de>
This Package adds a router advertisement daemon and
appropriate Freifunk Franken specific configuration for it.
The ra_default option is set to '2' to force the default flag,
even if no default route for ipv6 is present.
This is necessary, because otherwise fc00::/7 targets would be
unreachable, since odhcpd is unable to send specific routes inside a RA.
This won't affect clients ability to reach hosts which have a dual stack
connection, typical network stacks prefer IPv4 over IPv6 ULA when no
public IPv6 address is available.
Signed-off-by: Fabian Bläse <fabian@blaese.de>
Reviewed-by: Christian Dresel <fff@chrisi01.de>
Fabian Bläse
Adrian Schmutzler