It is not always necessary to add a host route for the gre peer address.
This introduces a new config option 'nohostroute' (similar to the
option introduced for wireguard in d8e2e19) to allow to disable
the creation of those routes explicitely.
Signed-off-by: Fabian Bläse <fabian@blaese.de>
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com> [PKG_RELEASE increase]
There are two problems with this behaviour that the zone is set to wan
if no zone config option is defined in the interface section.
* The zone for the interface is "normally" specified in the firewall
config file. So if we have defined "no" zone for this interface zone
option is set now to "wan" additonaly if we add the interface in the firewall
config section to the "lan" zone, the interface is added to lan and wan at once.
iptables-save | grep <iface>
This is not what I expect.
* If I do not want to set a zone to this interface it is not possible.
Remove the default assigment to wan if no zone option is defined.
If some one need the option it stil possible to define this option.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com> [PKG_RELEASE increase]
Make inclusion of the destination option header containing the tunnel
encapsulation limit configurable for IPv6 GRE packets.
Setting the uci parameter encaplimit to ignore; allows to disable the
insertion of the destination option header in the IPv6 GRE packets.
Otherwise the tunnel encapsulation limit value can be set to a value
from 0 till 255 by setting the encaplimit uci parameter accordingly.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
The split-up into packages gre, grev4 and grev6 causes confusion for the
users as reported in FS#1399.
As IPv4 and IPv6 are considered now as bundled; squash the grev4 and grev6
packages into the gre package and let gre provide both grev4 and grev6.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Fix multiple syntax errors in shelscripts (of packages only)
These errors were causing many conditions to not working properly
Signed-off-by: Lorenzo Santina <lorenzo.santina@edu.unito.it>
[increase PKG_RELEASE, drop command substitution from directip.sh]
Signed-off-by: Mathias Kresin <dev@kresin.em>
This commit modifies the /lib/netifd/proto/gre.sh script so that, when
GRE-TAP tunnels are created, either IPv4 or IPv6, the prefix before the chosen
interface name contains the "tap" substring, to differentiate them from non-TAP
GRE tunnels.
Right now, both GRE and GRE-TAP tunnel (either IPv4 or IPv6) interfaces defined
in /etc/config/network are named equally ("gre-"+$ifname or "grev6"+$ifname)
upon creation. For instance, the following tunnels:
config interface 'tuna'
option peeraddr '172.30.22.1'
option proto 'gre'
config interface 'tunb'
option peeraddr '192.168.233.4'
option proto 'gretap'
config interface 'tunc'
option peer6addr 'fdc5:7c9e:e93d:45af::1'
option proto 'grev6'
config interface 'tund'
option peer6addr 'fdc0:6071:1348:31ff::2'
option proto 'grev6tap'
are named, respectively, "gre-tuna", "gre-tunb", "grev6-tunc" and "grev6-tund".
The current change makes that each GRE tunnel interface of the four different
types available (gre, gretap, grev6 and grev6tap) gets a different prefix.
Therefore, the abovementioned tunnels will be named, respectively:
"gre4-tuna", "gre4t-tunb", "gre6-tunc" and "gre6t-tund".
This is coherent with other types of virtual interfaces (i.e. PPP, PPPoE, PPPoA)
where the whole protocol name is used. For instance, a PPPoA interface named
"p1" and a PPPoE interface named "p2" will respectively appear as "pppoa-p1"
and "pppoe-p2", not as "ppp-p1" and "ppp-p2").
Since Linux interfaces names are limited to 15 characters, these prefixes leave,
for the worst case (TAP tunnels), 9 characters for the actual name.
Signed-off-by: Roger Pueyo Centelles <roger.pueyo@guifi.net>
Build seems to fail with:
```
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for X:
* grev4 *
* opkg_install_cmd: Cannot install package X
```
After adding an empty install rule, the failure goes away.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
UCI paramater multicast is added which allows to toggle multicast support on gre interfaces.
By default multicast support is enabled as gre tunnels are often used in combination with
routing protocols using multicast.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Signed-off-by: Nick Podolak <nicholas.podolak@dtechlabs.com>
SVN-Revision: 48596
Source package gre was depending on kmod-ip6-gre, however the actual
kernel module package that is created is kmod-gre6. Therefore
update (source) package gre for ipv6 gre support.
Signed-off-by: Daniel Dickinson <openwrt@daniel.thecshore.com>
SVN-Revision: 48100
Since r46834, IPv6 support is builtin if selected. Therefor, dependencies
on kmod-ipv6 can no longer be fulfilled, since it is not a module anymore.
Signed-off-by: Arjen de Korte <arjen+openwrt@de-korte.org>
SVN-Revision: 47022
Tos support is added as a generic grev4/grev6 parameter which can have the following values :
-inherit (outer header inherits the tos value of the inner header)
-hex value
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
SVN-Revision: 42700
The package supports Generic Routing Encapsulation support by registering following protocol kinds:
-gre
-gretap
-grev6
-grev6tap
Following options are valid for gre and gretap kinds:
-ipaddr
-peeraddr
-df
-mtu
-ttl
-tunlink
-zone
-ikey
-okey
-icsum
-ocsum
-iseqno
-oseqno
The gretap kind supports additionally the network option
Following options are valid for grev6 and grev6tap kinds:
-ip6addr
-peer6addr
-weakif
-mtu
-ttl
-tunlink
-zone
-ikey
-okey
-icsum
-ocsum
-iseqno
-oseqno
The grev6tap kind supports additionally the network option
Typical network config for a GREv4 tunnel :
config interface 'gre'
option peeraddr '172.16.18.240'
option mtu '1400'
option proto 'gre'
option tunlink 'wan'
option zone 'tunnel'
Typical network config for a GREv4 tap tunnel :
config interface 'gretap'
option peeraddr '195.207.5.79'
option mtu '1400'
option proto 'gretap'
option zone 'tunnel'
option tunlink 'wan'
option network 'wlan_ap'
I added myself as maintainer for the moment; feel free to change.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
SVN-Revision: 41897
