Delete tunnel on 6rd interface teardown.
Should solve problem related to tunnel stuck on restart loop
with "Unknown Command" on tunnel restart due to wan connection drop.
This patch is similar to the one written by Ansuel on Aug 2, 2021
but the 6rd teardown produces the same symptoms when the network
service is restarted.
Signed-off-by: David Lam <david@thedavid.net>
Delete tunnel on 6in4 interface teardown.
Should solve problem related to tunnel stuck on restart loop
with "Unknown Command" on tunnel restart due to wan connection drop.
Fixes: FS#3690
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Placeholder DHCP user scripts were added recently.
These files make package-based installations of such scripts more difficult.
Pull user callbacks from directories instead to allow packages and users to
install co-existing scripts more easily.
References:
b4f3d93b5 odhcp6c: add a odhcp6c.user placeholder script
Signed-off-by: Leon M. George <leon@georgemail.eu>
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com> [PKG_RELEASE increase]
Document the existence of this feature. This allows the user to execute a script
at each DHCPv6 event. This is useful, for example, as an ad-hoc way to update a
DDNS entry when (and only when) required.
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
53f07e9 ra: fix routing loop on point to point links
2b6959d ra: align ifindex resolving
Tested-by: Karl Vogel <karl.vogel@gmail.com>
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
faed29a dhcpv6: only refresh timers when reconfigure is valid
9c50975 dhcpv6: fix printing identity association id
a7b2221 dhcpv6: avoid sending continuous renew/rebind messages
d7afa2b dhcpv6: add extra syslog info traces
f5728e4 odhcp6c_find_entry: exclude priority from the list of fields that must match
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
"type" is already used as a common option for all protocols types, so
using the same option name for the map type makes the configuration
ambiguous. Luci in particular adds controls for both options and sees
errors when reading the resulting configuration.
Use "maptype" instead, but still fallback to "type" if "maptype" is not
set. This allows configurations to migrate without breaking old
configurations.
This addresses FS#3287.
Signed-off-by: Remi NGUYEN VAN <remi.nguyenvan+openwrt@gmail.com>
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com> [PKG_RELEASE increase]
The legacy map version based on the IPv6 Interface Identifier in
draft-ietf-softwire-map-03 was typically used by uncommenting the LEGACY
variable in the map.sh file, which is not ideal. A proper configuration
option is needed instead.
The IPv6 Interface Identifier format described in the draft was
eventually changed in RFC7597, but is still used by some major ISPs,
including in Japan.
Signed-off-by: Remi NGUYEN VAN <remi.nguyenvan+openwrt@gmail.com>
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com> [PKG_RELEASE increase]
In the package guidelines, PKG_VERSION is supposed to be used as
"The upstream version number that we're downloading", while
PKG_RELEASE is referred to as "The version of this package Makefile".
Thus, the variables in a strict interpretation provide a clear
distinction between "their" (upstream) version in PKG_VERSION and
"our" (local OpenWrt trunk) version in PKG_RELEASE.
For local (OpenWrt-only) packages, this implies that those will only
need PKG_RELEASE defined, while PKG_VERSION does not apply following
a strict interpretation. While the majority of "our" packages actually
follow that scheme, there are also some that mix both variables or
have one of them defined but keep them at "1".
This is misleading and confusing, which can be observed by the fact
that there typically either one of the variables is never bumped or
the choice of the variable to increase depends on the person doing the
change.
Consequently, this patch aims at clarifying the situation by
consistently using only PKG_RELEASE for "our" packages. To achieve
that, PKG_VERSION is removed there, bumping PKG_RELEASE where
necessary to ensure the resulting package version string is bigger
than before.
During adjustment, one has to make sure that the new resulting composite
package version will not be considered "older" than the previous one.
A useful tool for evaluating that is 'opkg compare-versions'. In
principle, there are the following cases:
1. Sole PKG_VERSION replaced by sole PKG_RELEASE:
In this case, the resulting version string does not change, it's
just the value of the variable put in the file. Consequently, we
do not bump the number in these cases so nobody is tempted to
install the same package again.
2. PKG_VERSION and PKG_RELEASE replaced by sole PKG_RELEASE:
In this case, the resulting version string has been "version-release",
e.g. 1-3 or 1.0-3. For this case, the new PKG_RELEASE will just
need to be higher than the previous PKG_VERSION.
For the cases where PKG_VERSION has always sticked to "1", and
PKG_RELEASE has been incremented, we take the most recent value of
PKG_RELEASE.
Apart from that, a few packages appear to have developed their own
complex versioning scheme, e.g. using x.y.z number for PKG_VERSION
_and_ a PKG_RELEASE (qos-scripts) or using dates for PKG_VERSION
(adb-enablemodem, wwan). I didn't touch these few in this patch.
Cc: Hans Dedecker <dedeckeh@gmail.com>
Cc: Felix Fietkau <nbd@nbd.name>
Cc: Andre Valentin <avalentin@marcant.net>
Cc: Matthias Schiffer <mschiffer@universe-factory.net>
Cc: Jo-Philipp Wich <jo@mein.io>
Cc: Steven Barth <steven@midlink.org>
Cc: Daniel Golle <dgolle@allnet.de>
Cc: John Crispin <john@phrozen.org>
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
"[[" is a bash extension for test. As the ash-implementation is not
fully compatible we drop its usage.
Signed-off-by: Sven Roederer <devel-sven@geroedel.de>
This is a precursor to adding proper support for multiple
6in4 tunnels with the already programmed tunlink parameter.
This is an essential sanity check so as to not break existing
and working behind NAT setups.
Signed-off-by: Sean Kenny <skenny@wfap.ca>
6in4: add myip he.net api parameter logic
This is to add proper support for multiple 6in4 tunnels
with the already programmed tunlink parameter.
As it stands before this commit, if there is a multi wan setup that
consists of dynamic ips, there is no way to use the
dynamic update feature as the he.net api is implicitly using
the ip address of the caller. This will explicitly use the
ipaddr specified in the interface config OR the ip of the
tunlink interface specified in the dynamic update api call instead
ONLY if the final resolved ipaddr variable is not an rfc1918 address.
Signed-off-by: Sean Kenny <skenny@wfap.ca>
Don't set the default firewall zone to wan if not specified to keep the
behavior aligned with other tunnel protocols like gre and 6rd.
If the interface zone is not specified try to get it from the firewall config
when constructing the procd firewall rule.
While at it only add procd inbound/outbound firewall rules if a zone is specified.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Don't set the default firewall zone to wan if not specified to keep the
behavior aligned with other tunnel protocols like gre and 6rd.
If the interface zone is not specified try to get it from the firewall config
when constructing the procd firewall rule.
While at it only add a procd inbound firewall rule if a zone is specified.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
d2e247d odhcp6c: align further with RFC8415
ce83a23 dhcpv6: avoid parsing unncessary IAs
b079733 dhcpv6: set cnt to correct IOV enum
41494da dhcpv6: get rid of request_prefix
f7437e4 dhcpv6: sanitize option request list
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Setting encaplimit to a numerical value results into the value being
included as tunnel encapsulation limit in the destination option header
for tunneled packets.
Several users have reported interop issues as not all ISPs support the
destination option header containing the tunnel encapsulation limit
resulting into broken map connectivity.
Therefore drop the default encaplimit value for map tunnels so
no destination option header is included by default.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Setting encaplimit to a numerical value results into the value being
included as tunnel encapsulation limit in the destination option header
for tunneled packets.
Several users have reported interop issues as not all ISPs support the
destination option header containing the tunnel encapsulation limit
resulting into broken ds-lite connectivity.
Therefore drop the default encaplimit value for ds-lite tunnels so
no destination option header is included by default.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Allowing DHCPV6_CLIENT_FQDN and DHCPV6_ACCEPT_RECONFIGURE to be turned off.
Defaulting to false, former behavior remains unchanged.
Signed-off-by: pacien <pacien.trangirard@pacien.net>
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com> [PKG_RELEASE increase]
Apply IPv6/ND configuration before proto_send_update so that all config info
is available when netifd is handling the notify_proto ubus call.
In particular this fixes an issue when netifd is updating the downstream IPv6 mtu
as netifd was still using the not yet updated upstream IPv6 mtu to set the
downstream IPv6 mtu
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Fix broken DHCPv6 servers which provide the server unicast option but
do not reply on DHCPv6 renew messages directed to the IPv6 address
contained in the server unicast option whihc results in broken IPv6
connectivity.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Be compatible with ISPs which don't support the destination option header containing
the tunnel encapsulation limit as reported in FS#1501.
Setting the uci parameter encaplimit to ignore; allows to disable the insertion
of the destination option header in the map-e packets.
Otherwise the tunnel encapsulation limit value can be set to a value from 0 till 255
by setting the encaplimit uci parameter accordingly.
If no encaplimit value is specified the default value is 4 as before.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Be compatible with ISPs which don't support the destination option header containing
the tunnel encapsulation limit as reported in FS#1501 for dynamic created ds-lite/map
interfaces.
Setting the uci parameter encaplimit_dslite/map to ignore; allows to disable the insertion
of the destination option header for the dynamic created ds-lite/map interface.
Otherwise the tunnel encapsulation limit value can be set to a value from 0 till 255
by setting the encaplimit_dslite/map uci parameter accordingly.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Be compatible with ISPs which don't support the destination option header containing
the tunnel encapsulation limit as reported in FS#1501.
Setting the uci parameter encaplimit to ignore; allows to disable the insertion
of the destination option header in the ds-lite packets.
Otherwise the tunnel encapsulation limit value can be set to a value from 0 till 255
by setting the encaplimit uci parameter accordingly.
If no encaplimit value is specified the default value is 4 as before.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
74b5a3 script: fix possible negative delay
473f248 dhcpv6: always trigger script update in case of IA updates
ea18935 ra: rework route information option handling
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Fix psidlen becomes negative in case embedded address bit lenght is smaller than
IPv4 suffix length.
While at it improve parameter checking making the code more logical and
easier to read.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Support configuration in the form...
list ip6prefix 2001:db8:1234::/64
list ip6prefix 2001:db8:5678::/64
... to allow specifying multiple routed IPv6 prefixes.
Implements feature request FS#1361.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Acked-by: Hans Dedecker <dedeckeh@gmail.com>
Support configuration in the form...
list ip6prefix 2001:db8:1234::/64
list ip6prefix 2001:db8:5678::/64
... to allow specifying multiple additional IPv6 prefixes.
Implements feature request FS#1361.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Don't append an empty sendopts value as odhcp6c bails out
immediately on an empty -x option triggering an infinite start
loop of odhcp6c
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Commit a26045049b added support for sendopts as a string; since multiple
sendopts values can be specified it makes more sense to model it as a
list of strings.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
By default odhcp6c asks for a default list of options; the config option
defaultreqopts allows to tweak this behavior.
When set to 0 odhcp6c will not ask for any options except for the options
specified in the reqopts config option.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Add sendopts config support allowing to add options in sent DHCPv6 packets.
Options can be configured as follows :
uci set network.wan6.sendopts="sntpservers:3001:3001::1,3001:3001::2 11:00000000000000000000006674692F 0x3e8:ABCDEF"
Based on a patch by Frank Andrieu <fandrieu@gmail.com>
See https://git.openwrt.org/?p=project/odhcp6c.git;a=commit;h=510aaf6d528210c5e8a6159f9b80b32615e88c5f
for a more detailed description.
Latest git changes :
1f93bd4 dhcpv6: rework option passthrough logic
a477e95 odhcp6c: rework userclass and vendorclass command handling
510aaf6 odhcp6c: add -x opt:val support
ab75be1 treewide: update copyrights to 2018
f3a4609 odhcp6c: let odhcp6c_add_state return a success/failure indication
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Instead of grepping for NETWORK after calling ipcalc.sh; pass ipcalc.sh as
argument to eval allowing to use $NETWORK to retrieve the IPv4 prefix
(ip4prefix).
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Extendprefix is typically used to extend an IPv6 RA prefix from a mobile
wan link to the LAN; such scenario requires correct RA prefix settings
like the on link flag not being set.
However some mobile manufacter set the RA prefix on link flag which breaks
basic IPv6 routing.
Work around this issue by filtering out the route being equal to the
extended prefix.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
