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
Commit 31214c38c8dd0f70366b523f9b0335145b9386bd removes IPv6 unneeded source-dest-routing workarounds;
as a result sourcerouting parameter is unused and can be removed.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
SVN-Revision: 45939
Note, that licensing stuff is a nightmare: many packages does not clearly
state their licenses, and often multiple source files are simply copied
together - each with different licensing information in the file headers.
I tried hard to ensure, that the license information extracted into the OpenWRT's
makefiles fit the "spirit" of the packages, e.g. such small packages which
come without a dedicated source archive "inherites" the OpenWRT's own license
in my opinion.
However, I can not garantee that I always picked the correct information
and/or did not miss license information.
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
SVN-Revision: 43155
Tos support is added as a string 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: 42747
Gives the user the control to select the correct WAN IPv4 address to be used by the 6rd tunnel when mutiple WAN interfaces are configured
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
SVN-Revision: 40566
Make the IPv4 "do not fragment" bit a configurable variable for the 6rd
tunnel interface as the bit should not be set in the encapsulating IPv4
header according to RFC3056.
On top the config variable allows to enable/disable path mtu discovery
for tunnel interfaces.
Config variable can be passed to netifd as tunnel config support is
already present for the "do not fragment" bit.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
SVN-Revision: 39370
The correct bits are now cleared in the IPv6 address as the shift
value to the correct byte in the IPv6 address was wrong. Depending
on the stack values this could result in a hanging 6rdcalc program
due to an endless loop.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
SVN-Revision: 38818
Steven Barth
John Crispin
Felix Fietkau