From: Liping Zhang
Since Commit 64b87639c9cb ("netfilter: conntrack: fix race between
nf_conntrack proc read and hash resize") introdue the
nf_conntrack_get_ht, so there's no need to check nf_conntrack_generation
again and again to get the hash table and hash size.
But keep nf_conntrack_find
From: Liping Zhang
IP header checksum will be recalculated at ip_local_out, so
there's no need to calculated it here, remove it. Also update
code comments to illustrate it, and delete the misleading
comments about checksum recalculation.
Signed-off-by: Liping Zhang
---
net/ipv4/netfilter/nf_du
Liping Zhang wrote:
> From: Liping Zhang
>
> IP header checksum will be recalculated at ip_local_out, so
Thats only called for local packets.
> there's no need to calculated it here, remove it. Also update
> code comments to illustrate it, and delete the misleading
> comments about checksum re
Florian Westphal wrote:
> Liping Zhang wrote:
> > From: Liping Zhang
> >
> > IP header checksum will be recalculated at ip_local_out, so
>
> Thats only called for local packets.
Nevermind, nft_dup indeed uses ip_local_out, patch looks correct.
--
To unsubscribe from this list: send the line "
Michal Kubecek writes:
> There is a race condition between nf_{,un}register_hook() and
> cleanup_net() which can either trigger WARN check or cause a memory
> leak. The scenario is like this (2a and 2b are alternatives):
>
> 1. cleanup_net() removes one or more struct net from net_namespace_list
From: Xiaoping Fan
In some situations, NAT information is created after connection is
confirmed. Since 5 tuple for reply direction is changed when creating
NAT information, so we need to update hash bucket of connection.
Signed-off-by: Xiaoping Fan
---
include/net/netfilter/nf_conntrack.h | 5
From: Xiaoping Fan
In some case, bridged packet will come back again for routing. When bridge
netfilter is enabled, a null snat rule is assigned to bridged packet if no
matching in nat chain. Then nat rule matching is skipped when packet comes
back for routing. This result in private IP address e
From: Xiaoping Fan
In some situations, packet goes through Linux twice, one for bridging,
another for routing. If snat is created in bridging process, that means
snat rule only matches bridged traffic. If snat is created in routing
process, that means snat rule only matches routed traffic. If we
fxp2001640...@gmail.com wrote:
> From: Xiaoping Fan
>
> In some situations, NAT information is created after connection is
> confirmed.
That sounds like a bug.
How can this happen?
nf_nat_setup_info() is only safe for non-confirmed conntracks
(not in hash table).
--
To unsubscribe from this l