The xfrm_interface module will not be built if IPv6 is not enabled in
the kernel. Add this dependency in the kmod package to avoid people
wondering why it doesn't build when they disabled IPv6.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
As the name suggests, act_gact has the generic actions such as dropping
and accepting packets, so move it into kmod-sched-core.
Signed-off-by: DENG Qingfang <dqfext@gmail.com>
The link equalizer sch_teql.ko of package kmod-sched relies on a hotplug
script historically included in iproute2's tc package. In previous
discussion [1], consensus was the hotplug script is best located together
with the module in kmod-sched, but this change was deferred at the time.
Relocate the hotplug script now. This change also simplifies adding a tc
variant for minimal size with reduced functionality.
[1] https://github.com/openwrt/openwrt/pull/1627#issuecomment-447923636
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
Use NETWORK_SUPPORT_MENU like all other modules in netsupport.mk. Drop
SECTION and CATEGORY fields as they are set by default and to match
other packages in netsupport.mk. Use better TITLE for kmod-wireguard
(taken from upstream drivers/net/Kconfig).
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
On Linux 5.4, build WireGuard from backports. Linux 5.10 contains
wireguard in-tree.
Add in-kernel crypto libraries required by WireGuard along with
arch-specific optimizations.
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
Since we're now able to select CONFIG_NET_UDP_TUNNEL at will, drop the fake
dependencies.
This is a partial revert of commit d7e040f8bc
"kernel: add fake users for udptunnel and iptunnel modules".
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
Since generic has the option set to y and other targets now inherit that
choice, there is no behaviour change
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
Use in tree version of cake for kernels 4.19+ and backport features from
later kernel versions to 4.19.
Unfortunately PROVIDES dependency handling produces bogus circular
dependency warnings so whilst this package and kmod-sched-cake-oot
should be able to PROVIDE kmod-sched-cake this doesn't work.
Instead, remove the PROVIDES option and modify package sqm-scripts to
depend on the correct module independently.
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
The combination +@IPV6:kmod-ipsec6 is not valid, the +a:b
syntax implies the @. Fix it.
Fixes: 2e6b6f9fca ("kernel: add @IPv6 dependency to ipv6 modules")
Reported-by: Oldřich Jedlička (@oldium)
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
It is generally more desirable to use older kernel versions for
dependencies, as this will require less changes when newer kernels
are added (they will by default select the newer packages).
Since we currently only have two kernels (4.14 and 4.19) in master,
this patch applies this logic by converting all LINUX_4_19 symbols
to their inverted LINUX_4_14 equivalents.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
IPv6 modules should all depend on @IPV6, to avoid circular dependencies
problems, especially if they select a module that depends on IPV6 as
well. In theory, if a package A depends on IPV6, any package doing
'select A' (DEPENDS+= A) should also depend on IPV6; otherwise selecting
A will fail. Sometimes the build system is forgiving this, but
eventually, and unexpectedly, it may blow up on some other commit.
Alternatively one can conditionally add IPv6 dependencies only if
CONFIG_IPV6 is selected: (DEPENDS+= +IPV6:package6).
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
This adds the new xfrm4_mode_beet, xfrm4_mode_transport,
xfrm4_mode_tunnel and their IPv6 versions on kernel 5.4. These modules
were newly added in kernel 5.2.
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
"Whoop whoop, sound of da police"
Add an ingress capable traffic policer module configurable with tc.
From the man page:
The police action allows to limit bandwidth of traffic matched by the
filter it is attached to. Basically there are two different algorithms
available to measure the packet rate: The first one uses an internal
dual token bucket and is configured using the rate, burst, mtu,
peakrate, overhead and linklayer parameters. The second one uses an
in-kernel sampling mechanism. It can be fine-tuned using the estimator
filter parameter.
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
