[PATCH nf-next V2] netfilter: conntrack: simplify the code by using nf_conntrack_get_ht

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

[PATCH nf-next] netfilter: nf_dup4: remove redundant checksum recalculation

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

Re: [PATCH nf-next] netfilter: nf_dup4: remove redundant checksum recalculation

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

Re: [PATCH nf-next] netfilter: nf_dup4: remove redundant checksum recalculation

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 "

Re: [PATCH RESEND nf] netfilter: avoid a race between nf_register_hook() and cleanup_net()

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

[PATCH 1/3] netfilter: nat: update hash bucket if nat changed after ct confirmed

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

[PATCH 3/3] netfilter: nat: don't assign a null snat rule to bridged traffic if no matching

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

[PATCH 2/3] netfilter: nat: snat created in route process just apply to routed traffic

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

Re: [PATCH 1/3] netfilter: nat: update hash bucket if nat changed after ct confirmed

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