* [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support
@ 2019-07-08 8:29 wenxu
2019-07-08 8:29 ` [PATCH nf-next 2/3] netfilter: nft_chain_nat: add nft_chain_nat_bridge support wenxu
` (3 more replies)
0 siblings, 4 replies; 8+ messages in thread
From: wenxu @ 2019-07-08 8:29 UTC (permalink / raw)
To: pablo, fw; +Cc: netfilter-devel, netdev
From: wenxu <wenxu@ucloud.cn>
Add nf_nat_bridge_ops to do nat in the bridge family
Signed-off-by: wenxu <wenxu@ucloud.cn>
---
include/net/netfilter/nf_nat.h | 3 ++
net/netfilter/nf_nat_proto.c | 63 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 66 insertions(+)
diff --git a/include/net/netfilter/nf_nat.h b/include/net/netfilter/nf_nat.h
index 423cda2..0c2d326 100644
--- a/include/net/netfilter/nf_nat.h
+++ b/include/net/netfilter/nf_nat.h
@@ -101,6 +101,9 @@ int nf_nat_icmpv6_reply_translation(struct sk_buff *skb, struct nf_conn *ct,
int nf_nat_inet_register_fn(struct net *net, const struct nf_hook_ops *ops);
void nf_nat_inet_unregister_fn(struct net *net, const struct nf_hook_ops *ops);
+int nf_nat_bridge_register_fn(struct net *net, const struct nf_hook_ops *ops);
+void nf_nat_bridge_unregister_fn(struct net *net, const struct nf_hook_ops *ops);
+
unsigned int
nf_nat_inet_fn(void *priv, struct sk_buff *skb,
const struct nf_hook_state *state);
diff --git a/net/netfilter/nf_nat_proto.c b/net/netfilter/nf_nat_proto.c
index 888292e..652a71e 100644
--- a/net/netfilter/nf_nat_proto.c
+++ b/net/netfilter/nf_nat_proto.c
@@ -1035,3 +1035,66 @@ void nf_nat_inet_unregister_fn(struct net *net, const struct nf_hook_ops *ops)
}
EXPORT_SYMBOL_GPL(nf_nat_inet_unregister_fn);
#endif /* NFT INET NAT */
+
+#if defined(CONFIG_NF_TABLES_BRIDGE) && IS_ENABLED(CONFIG_NFT_NAT)
+static unsigned int
+nf_nat_bridge_in(void *priv, struct sk_buff *skb,
+ const struct nf_hook_state *state)
+{
+ switch (skb->protocol) {
+ case htons(ETH_P_IP):
+ return nf_nat_ipv4_in(priv, skb, state);
+ case htons(ETH_P_IPV6):
+ return nf_nat_ipv6_in(priv, skb, state);
+ default:
+ return NF_ACCEPT;
+ }
+}
+
+static unsigned int
+nf_nat_bridge_out(void *priv, struct sk_buff *skb,
+ const struct nf_hook_state *state)
+{
+ switch (skb->protocol) {
+ case htons(ETH_P_IP):
+ return nf_nat_ipv4_out(priv, skb, state);
+ case htons(ETH_P_IPV6):
+ return nf_nat_ipv6_out(priv, skb, state);
+ default:
+ return NF_ACCEPT;
+ }
+}
+
+const struct nf_hook_ops nf_nat_bridge_ops[] = {
+ /* Before packet filtering, change destination */
+ {
+ .hook = nf_nat_bridge_in,
+ .pf = NFPROTO_BRIDGE,
+ .hooknum = NF_INET_PRE_ROUTING,
+ .priority = NF_IP_PRI_NAT_DST,
+ },
+ /* After packet filtering, change source */
+ {
+ .hook = nf_nat_bridge_out,
+ .pf = NFPROTO_BRIDGE,
+ .hooknum = NF_INET_POST_ROUTING,
+ .priority = NF_IP_PRI_NAT_SRC,
+ },
+};
+
+int nf_nat_bridge_register_fn(struct net *net, const struct nf_hook_ops *ops)
+{
+ if (WARN_ON_ONCE(ops->pf != NFPROTO_BRIDGE))
+ return -EINVAL;
+
+ return nf_nat_register_fn(net, ops->pf, ops, nf_nat_bridge_ops,
+ ARRAY_SIZE(nf_nat_bridge_ops));
+}
+EXPORT_SYMBOL_GPL(nf_nat_bridge_register_fn);
+
+void nf_nat_bridge_unregister_fn(struct net *net, const struct nf_hook_ops *ops)
+{
+ nf_nat_unregister_fn(net, ops->pf, ops, ARRAY_SIZE(nf_nat_bridge_ops));
+}
+EXPORT_SYMBOL_GPL(nf_nat_bridge_unregister_fn);
+#endif
--
1.8.3.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH nf-next 2/3] netfilter: nft_chain_nat: add nft_chain_nat_bridge support
2019-07-08 8:29 [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support wenxu
@ 2019-07-08 8:29 ` wenxu
2019-07-08 8:29 ` [PATCH nf-next 3/3] netfilter: nft_nat: add nft_bridge_nat_type support wenxu
` (2 subsequent siblings)
3 siblings, 0 replies; 8+ messages in thread
From: wenxu @ 2019-07-08 8:29 UTC (permalink / raw)
To: pablo, fw; +Cc: netfilter-devel, netdev
From: wenxu <wenxu@ucloud.cn>
Add nft_chan_nat_bridge to handle nat rule in bridge family
Signed-off-by: wenxu <wenxu@ucloud.cn>
---
net/netfilter/nft_chain_nat.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/net/netfilter/nft_chain_nat.c b/net/netfilter/nft_chain_nat.c
index 2f89bde..2ae3fbb 100644
--- a/net/netfilter/nft_chain_nat.c
+++ b/net/netfilter/nft_chain_nat.c
@@ -104,6 +104,23 @@ static void nft_nat_inet_unreg(struct net *net, const struct nf_hook_ops *ops)
};
#endif
+#ifdef CONFIG_NF_TABLES_BRIDGE
+static const struct nft_chain_type nft_chain_nat_bridge = {
+ .name = "nat",
+ .type = NFT_CHAIN_T_NAT,
+ .family = NFPROTO_BRIDGE,
+ .owner = THIS_MODULE,
+ .hook_mask = (1 << NF_INET_PRE_ROUTING) |
+ (1 << NF_INET_POST_ROUTING),
+ .hooks = {
+ [NF_INET_PRE_ROUTING] = nft_nat_do_chain,
+ [NF_INET_POST_ROUTING] = nft_nat_do_chain,
+ },
+ .ops_register = nf_nat_bridge_register_fn,
+ .ops_unregister = nf_nat_bridge_unregister_fn,
+};
+#endif
+
static int __init nft_chain_nat_init(void)
{
#ifdef CONFIG_NF_TABLES_IPV6
@@ -115,6 +132,9 @@ static int __init nft_chain_nat_init(void)
#ifdef CONFIG_NF_TABLES_INET
nft_register_chain_type(&nft_chain_nat_inet);
#endif
+#ifdef CONFIG_NF_TABLES_BRIDGE
+ nft_register_chain_type(&nft_chain_nat_bridge);
+#endif
return 0;
}
@@ -130,6 +150,9 @@ static void __exit nft_chain_nat_exit(void)
#ifdef CONFIG_NF_TABLES_INET
nft_unregister_chain_type(&nft_chain_nat_inet);
#endif
+#ifdef CONFIG_NF_TABLES_BRIDGE
+ nft_unregister_chain_type(&nft_chain_nat_bridge);
+#endif
}
module_init(nft_chain_nat_init);
@@ -142,3 +165,6 @@ static void __exit nft_chain_nat_exit(void)
#ifdef CONFIG_NF_TABLES_IPV6
MODULE_ALIAS_NFT_CHAIN(AF_INET6, "nat");
#endif
+#ifdef CONFIG_NF_TABLES_BRIDGE
+MODULE_ALIAS_NFT_CHAIN(AF_BRIDGE, "nat");
+#endif
--
1.8.3.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH nf-next 3/3] netfilter: nft_nat: add nft_bridge_nat_type support
2019-07-08 8:29 [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support wenxu
2019-07-08 8:29 ` [PATCH nf-next 2/3] netfilter: nft_chain_nat: add nft_chain_nat_bridge support wenxu
@ 2019-07-08 8:29 ` wenxu
2019-07-08 14:17 ` [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support Florian Westphal
2019-07-09 7:04 ` kbuild test robot
3 siblings, 0 replies; 8+ messages in thread
From: wenxu @ 2019-07-08 8:29 UTC (permalink / raw)
To: pablo, fw; +Cc: netfilter-devel, netdev
From: wenxu <wenxu@ucloud.cn>
Add nft_bridge_nat_type to configure nat rule in bridge family
Signed-off-by: wenxu <wenxu@ucloud.cn>
---
net/netfilter/nft_nat.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 47 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nft_nat.c b/net/netfilter/nft_nat.c
index c3c93e9..ba396851 100644
--- a/net/netfilter/nft_nat.c
+++ b/net/netfilter/nft_nat.c
@@ -136,7 +136,9 @@ static int nft_nat_init(const struct nft_ctx *ctx, const struct nft_expr *expr,
return -EINVAL;
family = ntohl(nla_get_be32(tb[NFTA_NAT_FAMILY]));
- if (ctx->family != NFPROTO_INET && ctx->family != family)
+ if (ctx->family != NFPROTO_INET &&
+ ctx->family != NFPROTO_BRIDGE &&
+ ctx->family != family)
return -EOPNOTSUPP;
switch (family) {
@@ -318,6 +320,40 @@ static void nft_nat_inet_module_exit(void)
static void nft_nat_inet_module_exit(void) { }
#endif
+#ifdef CONFIG_NF_TABLES_BRIDGE
+static const struct nft_expr_ops nft_nat_bridge_ops = {
+ .type = &nft_nat_type,
+ .size = NFT_EXPR_SIZE(sizeof(struct nft_nat)),
+ .eval = nft_nat_eval,
+ .init = nft_nat_init,
+ .destroy = nft_nat_destroy,
+ .dump = nft_nat_dump,
+ .validate = nft_nat_validate,
+};
+
+static struct nft_expr_type nft_bridge_nat_type __read_mostly = {
+ .name = "nat",
+ .family = NFPROTO_BRIDGE,
+ .ops = &nft_nat_bridge_ops,
+ .policy = nft_nat_policy,
+ .maxattr = NFTA_NAT_MAX,
+ .owner = THIS_MODULE,
+};
+
+static int nft_nat_bridge_module_init(void)
+{
+ return nft_register_expr(&nft_bridge_nat_type);
+}
+
+static void nft_nat_bridge_module_exit(void)
+{
+ nft_unregister_expr(&nft_bridge_nat_type);
+}
+#else
+static int nft_nat_bridge_module_init(void) { return 0; }
+static void nft_nat_bridge_module_exit(void) { }
+#endif
+
static int __init nft_nat_module_init(void)
{
int ret = nft_nat_inet_module_init();
@@ -325,15 +361,24 @@ static int __init nft_nat_module_init(void)
if (ret)
return ret;
+ ret = nft_nat_bridge_module_init();
+ if (ret) {
+ nft_nat_inet_module_exit();
+ return ret;
+ }
+
ret = nft_register_expr(&nft_nat_type);
- if (ret)
+ if (ret) {
+ nft_nat_bridge_module_exit();
nft_nat_inet_module_exit();
+ }
return ret;
}
static void __exit nft_nat_module_exit(void)
{
+ nft_nat_bridge_module_exit();
nft_nat_inet_module_exit();
nft_unregister_expr(&nft_nat_type);
}
--
1.8.3.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support
2019-07-08 8:29 [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support wenxu
2019-07-08 8:29 ` [PATCH nf-next 2/3] netfilter: nft_chain_nat: add nft_chain_nat_bridge support wenxu
2019-07-08 8:29 ` [PATCH nf-next 3/3] netfilter: nft_nat: add nft_bridge_nat_type support wenxu
@ 2019-07-08 14:17 ` Florian Westphal
2019-07-09 2:56 ` wenxu
2019-07-09 7:04 ` kbuild test robot
3 siblings, 1 reply; 8+ messages in thread
From: Florian Westphal @ 2019-07-08 14:17 UTC (permalink / raw)
To: wenxu; +Cc: pablo, fw, netfilter-devel, netdev
wenxu@ucloud.cn <wenxu@ucloud.cn> wrote:
> From: wenxu <wenxu@ucloud.cn>
>
> Add nf_nat_bridge_ops to do nat in the bridge family
Whats the use case for this?
The reason I'm asking is that a bridge doesn't know about IP,
Bridge netfilter (the call-iptables thing) has a lot of glue code
to detect dnat rewrites and updates target mac address, including
support for redirect (suddently packet has to be pushed up the stack)
or changes in the oif to non-bridge ports (it even checks forward sysctl
state ..) and so on.
Thats something that I don't want to support in nftables.
For NAT on bridge, it should be possible already to push such packets
up the stack by
bridge input meta iif eth0 ip saddr 192.168.0.0/16 \
meta pkttype set unicast ether daddr set 00:11:22:33:44:55
then normal ip processing handles this and nat should "just work".
If above doesn't work for you I'd like to understand why.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support
2019-07-08 14:17 ` [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support Florian Westphal
@ 2019-07-09 2:56 ` wenxu
2019-07-09 10:42 ` Florian Westphal
0 siblings, 1 reply; 8+ messages in thread
From: wenxu @ 2019-07-09 2:56 UTC (permalink / raw)
To: Florian Westphal; +Cc: pablo, netfilter-devel, netdev
On 7/8/2019 10:17 PM, Florian Westphal wrote:
> wenxu@ucloud.cn <wenxu@ucloud.cn> wrote:
>> From: wenxu <wenxu@ucloud.cn>
>>
>> Add nf_nat_bridge_ops to do nat in the bridge family
> Whats the use case for this?
>
> The reason I'm asking is that a bridge doesn't know about IP,
> Bridge netfilter (the call-iptables thing) has a lot of glue code
> to detect dnat rewrites and updates target mac address, including
> support for redirect (suddently packet has to be pushed up the stack)
> or changes in the oif to non-bridge ports (it even checks forward sysctl
> state ..) and so on.
>
> Thats something that I don't want to support in nftables.
>
> For NAT on bridge, it should be possible already to push such packets
> up the stack by
>
> bridge input meta iif eth0 ip saddr 192.168.0.0/16 \
> meta pkttype set unicast ether daddr set 00:11:22:33:44:55
yes, packet can be push up to IP stack to handle the nat through bridge device.
In my case dnat 2.2.1.7 to 10.0.0.7, It assume the mac address of the two address
is the same known by outer. So The bridge can just do nat( without modify mac address or oif).
But in This case modify the packet dmac to bridge device, the packet push up through bridge device
Then do nat and route send back to bridge device.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support
2019-07-09 2:56 ` wenxu
@ 2019-07-09 10:42 ` Florian Westphal
2019-07-09 13:38 ` wenxu
0 siblings, 1 reply; 8+ messages in thread
From: Florian Westphal @ 2019-07-09 10:42 UTC (permalink / raw)
To: wenxu; +Cc: Florian Westphal, pablo, netfilter-devel, netdev
wenxu <wenxu@ucloud.cn> wrote:
> > For NAT on bridge, it should be possible already to push such packets
> > up the stack by
> >
> > bridge input meta iif eth0 ip saddr 192.168.0.0/16 \
> > meta pkttype set unicast ether daddr set 00:11:22:33:44:55
>
> yes, packet can be push up to IP stack to handle the nat through bridge device.
>
> In my case dnat 2.2.1.7 to 10.0.0.7, It assume the mac address of the two address
> is the same known by outer.
I think that in general they will have different MAC addresses, so plain
replacement of ip addresses won't work.
> But in This case modify the packet dmac to bridge device, the packet push up through bridge device
> Then do nat and route send back to bridge device.
Are you saying that you can use the send-to-ip-layer approach?
We might need/want a more convenient way to do this.
There are two ways that I can see:
1. a redirect support for nftables bridge family.
The redirect expression would be same as "ether daddr set
<bridge_mac>", but there is no need to know the bridge mac address.
2. Support ebtables -t broute in nftables.
The route rework for ebtables has been completed already, so
this needs a new expression. Packet that is brouted behaves
as if the bridge port was not part of the bridge.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support
2019-07-09 10:42 ` Florian Westphal
@ 2019-07-09 13:38 ` wenxu
0 siblings, 0 replies; 8+ messages in thread
From: wenxu @ 2019-07-09 13:38 UTC (permalink / raw)
To: Florian Westphal; +Cc: pablo, netfilter-devel, netdev
在 2019/7/9 18:42, Florian Westphal 写道:
> wenxu <wenxu@ucloud.cn> wrote:
>>> For NAT on bridge, it should be possible already to push such packets
>>> up the stack by
>>>
>>> bridge input meta iif eth0 ip saddr 192.168.0.0/16 \
>>> meta pkttype set unicast ether daddr set 00:11:22:33:44:55
>> yes, packet can be push up to IP stack to handle the nat through bridge device.
>>
>> In my case dnat 2.2.1.7 to 10.0.0.7, It assume the mac address of the two address
>> is the same known by outer.
> I think that in general they will have different MAC addresses, so plain
> replacement of ip addresses won't work.
>
>> But in This case modify the packet dmac to bridge device, the packet push up through bridge device
>> Then do nat and route send back to bridge device.
> Are you saying that you can use the send-to-ip-layer approach?
>
> We might need/want a more convenient way to do this.
> There are two ways that I can see:
>
> 1. a redirect support for nftables bridge family.
> The redirect expression would be same as "ether daddr set
> <bridge_mac>", but there is no need to know the bridge mac address.
>
> 2. Support ebtables -t broute in nftables.
> The route rework for ebtables has been completed already, so
> this needs a new expression. Packet that is brouted behaves
> as if the bridge port was not part of the bridge.
This is my senario:
For a virtual machine example with address 10.0.0.7 and internet address 2.2.1.7 default router
10.0.0.1. There are both the east-west and south-north traffic. So the outer vnet0 connect to bridge
br0 which with address 10.0.0.1. The bridge also add an flow-based/metadata_dst vxlan device vxlan0.
So there are three kinds traffic to handle:
1. 10.0.0.7 <-----> 10.0.0.8: both ingress and egress packet gothrough the bridge with vlanid to vni feature.
2. 10.0.0.7 <-----> 10.0.1.8: The egress packet push up to stack through br0 to do route. And the route send packet through
vxlan0 to peer with static mac(Maybe the route can send through br0); The ingress packet always gothrough the bridge to VM.
3. 10.0.0.7 <----> 1.1.1.7: The egress The egress packet push up to stack through br0 to do route and nat. And the route send
packet through vxlan0 to router. With this patche, The router assume is the same mac address for 10.0.0.7 and 2.2.1.7. so it can do
nat under bridge and send to VM.
I think the most big problem is that the only vxlan0 device is alyways attach on br0. For L3( do route) traffic the egress packet will push
up to stack do route through br0. The ingress I hope only gothrough the bridge to VM for all the three kinds traffic above.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support
2019-07-08 8:29 [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support wenxu
` (2 preceding siblings ...)
2019-07-08 14:17 ` [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support Florian Westphal
@ 2019-07-09 7:04 ` kbuild test robot
3 siblings, 0 replies; 8+ messages in thread
From: kbuild test robot @ 2019-07-09 7:04 UTC (permalink / raw)
To: wenxu; +Cc: kbuild-all, pablo, fw, netfilter-devel, netdev
[-- Attachment #1: Type: text/plain, Size: 2475 bytes --]
Hi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on nf-next/master]
url: https://github.com/0day-ci/linux/commits/wenxu-ucloud-cn/netfilter-nf_nat_proto-add-nf_nat_bridge_ops-support/20190709-070304
base: https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next.git master
config: x86_64-randconfig-s1-07091425 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-9) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
net/netfilter/nf_nat_proto.c: In function 'nf_nat_bridge_in':
>> net/netfilter/nf_nat_proto.c:1048:10: error: implicit declaration of function 'nf_nat_ipv6_in'; did you mean 'nf_nat_ipv4_in'? [-Werror=implicit-function-declaration]
return nf_nat_ipv6_in(priv, skb, state);
^~~~~~~~~~~~~~
nf_nat_ipv4_in
net/netfilter/nf_nat_proto.c: In function 'nf_nat_bridge_out':
>> net/netfilter/nf_nat_proto.c:1062:10: error: implicit declaration of function 'nf_nat_ipv6_out'; did you mean 'nf_nat_ipv4_out'? [-Werror=implicit-function-declaration]
return nf_nat_ipv6_out(priv, skb, state);
^~~~~~~~~~~~~~~
nf_nat_ipv4_out
cc1: some warnings being treated as errors
vim +1048 net/netfilter/nf_nat_proto.c
1038
1039 #if defined(CONFIG_NF_TABLES_BRIDGE) && IS_ENABLED(CONFIG_NFT_NAT)
1040 static unsigned int
1041 nf_nat_bridge_in(void *priv, struct sk_buff *skb,
1042 const struct nf_hook_state *state)
1043 {
1044 switch (skb->protocol) {
1045 case htons(ETH_P_IP):
1046 return nf_nat_ipv4_in(priv, skb, state);
1047 case htons(ETH_P_IPV6):
> 1048 return nf_nat_ipv6_in(priv, skb, state);
1049 default:
1050 return NF_ACCEPT;
1051 }
1052 }
1053
1054 static unsigned int
1055 nf_nat_bridge_out(void *priv, struct sk_buff *skb,
1056 const struct nf_hook_state *state)
1057 {
1058 switch (skb->protocol) {
1059 case htons(ETH_P_IP):
1060 return nf_nat_ipv4_out(priv, skb, state);
1061 case htons(ETH_P_IPV6):
> 1062 return nf_nat_ipv6_out(priv, skb, state);
1063 default:
1064 return NF_ACCEPT;
1065 }
1066 }
1067
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 34307 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-07-09 13:39 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-08 8:29 [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support wenxu
2019-07-08 8:29 ` [PATCH nf-next 2/3] netfilter: nft_chain_nat: add nft_chain_nat_bridge support wenxu
2019-07-08 8:29 ` [PATCH nf-next 3/3] netfilter: nft_nat: add nft_bridge_nat_type support wenxu
2019-07-08 14:17 ` [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support Florian Westphal
2019-07-09 2:56 ` wenxu
2019-07-09 10:42 ` Florian Westphal
2019-07-09 13:38 ` wenxu
2019-07-09 7:04 ` kbuild test robot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).