So far any changes with ebtables will reset the state of limit rules,
leading to spikes in traffic. This is especially noticeable if changes
are done frequently, for instance via a daemon.
This patch fixes this by bailing out from (re)setting if the limit
rule was initialized before.
When sending
In case almost or all available ports are taken, clash resolution can
take a very long time, resulting in soft lockup.
This can happen when many to-be-natted hosts connect to same
destination:port (e.g. a proxy) and all connections pass the same SNAT.
Pick a random offset in the acceptable range,
Sorry already patched. Ignore this.
Il giorno sab 8 dic 2018 alle ore 20:29 Ansuel Smith
ha scritto:
>
> Think is triggerd with nftables support
>
> In file included from
> /home/daniel/Build/openwrt-ath79/staging_dir/toolchain-mips_24kc_gcc-7.3.0_musl/include/net/ethernet.h:10:0,
>
Think is triggerd with nftables support
In file included from
/home/daniel/Build/openwrt-ath79/staging_dir/toolchain-mips_24kc_gcc-7.3.0_musl/include/net/ethernet.h:10:0,
from ../iptables/nft-bridge.h:8,
from libebt_vlan.c:18:
/home/daniel/Build/openwrt-ath79/stag
Xiaozhou Liu wrote:
> > + for (i = 0; i < attempts; ++off) {
> > *portptr = htons(min + off % range_size);
> > - if (++i != range_size && nf_nat_used_tuple(tuple, ct))
> > + if (nf_nat_used_tuple(tuple, ct))
> > continue;
> > if (!(
On Sat, Dec 08, 2018 at 11:07:44AM +0100, Florian Westphal wrote:
> Pablo,
>
> this will unfortunately result in a nf-next merge conflict
> due to *rover removal in nf-next.
> I can send a patch vs. nf-next instead if you prefer.
>
> net/netfilter/nf_nat_proto_common.c | 26 +
In case almost or all available ports are taken, clash resolution can
take a very long time, resulting in soft lockup.
This can happen when many to-be-natted hosts connect to same
destination:port (e.g. a proxy) and all connections pass the same SNAT.
Pick a random offset in the acceptable range,
