* [PATCH nft v5] meta: add ibrpvid and ibrvproto support
@ 2019-08-23 13:45 wenxu
2019-08-26 10:26 ` Pablo Neira Ayuso
0 siblings, 1 reply; 6+ messages in thread
From: wenxu @ 2019-08-23 13:45 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel
From: wenxu <wenxu@ucloud.cn>
This allows you to match the bridge pvid and vlan protocol, for
instance:
nft add rule bridge firewall zones meta ibrvproto 0x8100
nft add rule bridge firewall zones meta ibrpvid 100
Signed-off-by: wenxu <wenxu@ucloud.cn>
---
src/meta.c | 6 ++++++
tests/py/bridge/meta.t | 2 ++
tests/py/bridge/meta.t.json | 26 ++++++++++++++++++++++++++
tests/py/bridge/meta.t.payload | 9 +++++++++
4 files changed, 43 insertions(+)
diff --git a/src/meta.c b/src/meta.c
index 5901c99..d45d757 100644
--- a/src/meta.c
+++ b/src/meta.c
@@ -442,6 +442,12 @@ const struct meta_template meta_templates[] = {
[NFT_META_OIFKIND] = META_TEMPLATE("oifkind", &ifname_type,
IFNAMSIZ * BITS_PER_BYTE,
BYTEORDER_HOST_ENDIAN),
+ [NFT_META_BRI_IIFPVID] = META_TEMPLATE("ibrpvid", &integer_type,
+ 2 * BITS_PER_BYTE,
+ BYTEORDER_HOST_ENDIAN),
+ [NFT_META_BRI_IIFVPROTO] = META_TEMPLATE("ibrvproto", ðertype_type,
+ 2 * BITS_PER_BYTE,
+ BYTEORDER_HOST_ENDIAN),
};
static bool meta_key_is_unqualified(enum nft_meta_keys key)
diff --git a/tests/py/bridge/meta.t b/tests/py/bridge/meta.t
index 88e819f..d9fb681 100644
--- a/tests/py/bridge/meta.t
+++ b/tests/py/bridge/meta.t
@@ -4,3 +4,5 @@
meta obrname "br0";ok
meta ibrname "br0";ok
+meta ibrvproto 0x8100;ok
+meta ibrpvid 100;ok
diff --git a/tests/py/bridge/meta.t.json b/tests/py/bridge/meta.t.json
index 5df4773..0a5e64a 100644
--- a/tests/py/bridge/meta.t.json
+++ b/tests/py/bridge/meta.t.json
@@ -23,3 +23,29 @@
}
}
]
+
+# meta ibrvproto 0x8100
+[
+ {
+ "match": {
+ "left": {
+ "meta": { "key": "ibrvproto" }
+ },
+ "op": "==",
+ "right": "0x8100"
+ }
+ }
+]
+
+# meta ibrpvid 100
+[
+ {
+ "match": {
+ "left": {
+ "meta": { "key": "ibrpvid" }
+ },
+ "op": "==",
+ "right": 100
+ }
+ }
+]
diff --git a/tests/py/bridge/meta.t.payload b/tests/py/bridge/meta.t.payload
index 0f0d101..e5793a9 100644
--- a/tests/py/bridge/meta.t.payload
+++ b/tests/py/bridge/meta.t.payload
@@ -8,3 +8,12 @@ bridge test-bridge input
[ meta load bri_iifname => reg 1 ]
[ cmp eq reg 1 0x00307262 0x00000000 0x00000000 0x00000000 ]
+# meta ibrvproto 0x8100
+bridge test-bridge input
+ [ meta load bri_iifvproto => reg 1 ]
+ [ cmp eq reg 1 0x00008100 ]
+
+# meta ibrpvid 100
+bridge test-bridge input
+ [ meta load bri_iifpvid => reg 1 ]
+ [ cmp eq reg 1 0x00000064 ]
--
2.15.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH nft v5] meta: add ibrpvid and ibrvproto support
2019-08-23 13:45 [PATCH nft v5] meta: add ibrpvid and ibrvproto support wenxu
@ 2019-08-26 10:26 ` Pablo Neira Ayuso
2019-08-26 13:51 ` wenxu
0 siblings, 1 reply; 6+ messages in thread
From: Pablo Neira Ayuso @ 2019-08-26 10:26 UTC (permalink / raw)
To: wenxu; +Cc: netfilter-devel
On Fri, Aug 23, 2019 at 09:45:28PM +0800, wenxu@ucloud.cn wrote:
> From: wenxu <wenxu@ucloud.cn>
>
> This allows you to match the bridge pvid and vlan protocol, for
> instance:
>
> nft add rule bridge firewall zones meta ibrvproto 0x8100
> nft add rule bridge firewall zones meta ibrpvid 100
When running python nft-tests.py with -j, I get this here:
bridge/meta.t: WARNING: line 7: '{"nftables": [{"add": {"rule":
{"table": "test-bridge", "chain": "input", "family": "bridge", "expr":
[{"match": {"op": "==", "right": "0x8100", "left": {"meta": {"key":
"ibrvproto"}}}}]}}}]}': '[{"match": {"left": {"meta": {"key":
"ibrvproto"}}, "op": "==", "right": "0x8100"}}]' mismatches
'[{"match": {"left": {"meta": {"key": "ibrvproto"}}, "op": "==",
"right": 33024}}]'
/tmp/nftables/tests/py/bridge/meta.t.json.output.got:
WARNING: line 2: Wrote JSON output for rule meta ibrvproto 0x8100
Then, if I type:
nft rule x y meta protocol vlan
Then, printing shows:
table ip x {
chain y {
meta protocol vlan
}
}
However, with:
nft rule x y meta ibrvproto vlan
I get this:
table bridge x {
chain y {
meta ibrvproto 0x8100
}
}
I think the problem the endianess in the new key definitions are not
correct.
The br_vlan_get_proto() in the kernel returns a value in network byte
order.
I think this does not match either then? Because bytecode is
incorrect?
Thanks.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH nft v5] meta: add ibrpvid and ibrvproto support
2019-08-26 10:26 ` Pablo Neira Ayuso
@ 2019-08-26 13:51 ` wenxu
2019-08-26 14:37 ` Pablo Neira Ayuso
0 siblings, 1 reply; 6+ messages in thread
From: wenxu @ 2019-08-26 13:51 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel
在 2019/8/26 18:26, Pablo Neira Ayuso 写道:
> On Fri, Aug 23, 2019 at 09:45:28PM +0800, wenxu@ucloud.cn wrote:
>> From: wenxu <wenxu@ucloud.cn>
>>
>> This allows you to match the bridge pvid and vlan protocol, for
>> instance:
>>
>> nft add rule bridge firewall zones meta ibrvproto 0x8100
>> nft add rule bridge firewall zones meta ibrpvid 100
> When running python nft-tests.py with -j, I get this here:
>
> bridge/meta.t: WARNING: line 7: '{"nftables": [{"add": {"rule":
> {"table": "test-bridge", "chain": "input", "family": "bridge", "expr":
> [{"match": {"op": "==", "right": "0x8100", "left": {"meta": {"key":
> "ibrvproto"}}}}]}}}]}': '[{"match": {"left": {"meta": {"key":
> "ibrvproto"}}, "op": "==", "right": "0x8100"}}]' mismatches
> '[{"match": {"left": {"meta": {"key": "ibrvproto"}}, "op": "==",
> "right": 33024}}]'
> /tmp/nftables/tests/py/bridge/meta.t.json.output.got:
> WARNING: line 2: Wrote JSON output for rule meta ibrvproto 0x8100
>
> Then, if I type:
>
> nft rule x y meta protocol vlan
>
> Then, printing shows:
>
> table ip x {
> chain y {
> meta protocol vlan
> }
> }
>
> However, with:
>
> nft rule x y meta ibrvproto vlan
>
> I get this:
>
> table bridge x {
> chain y {
> meta ibrvproto 0x8100
> }
> }
>
> I think the problem the endianess in the new key definitions are not
> correct.
>
> The br_vlan_get_proto() in the kernel returns a value in network byte
> order.
>
> I think this does not match either then? Because bytecode is
> incorrect?
The br_vlan_get_proto returns vlan_proto in host byte order.
>
> Thanks.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH nft v5] meta: add ibrpvid and ibrvproto support
2019-08-26 13:51 ` wenxu
@ 2019-08-26 14:37 ` Pablo Neira Ayuso
2019-08-27 3:10 ` wenxu
0 siblings, 1 reply; 6+ messages in thread
From: Pablo Neira Ayuso @ 2019-08-26 14:37 UTC (permalink / raw)
To: wenxu; +Cc: netfilter-devel
On Mon, Aug 26, 2019 at 09:51:57PM +0800, wenxu wrote:
>
> 在 2019/8/26 18:26, Pablo Neira Ayuso 写道:
> > On Fri, Aug 23, 2019 at 09:45:28PM +0800, wenxu@ucloud.cn wrote:
> >> From: wenxu <wenxu@ucloud.cn>
> >>
> >> This allows you to match the bridge pvid and vlan protocol, for
> >> instance:
> >>
> >> nft add rule bridge firewall zones meta ibrvproto 0x8100
> >> nft add rule bridge firewall zones meta ibrpvid 100
> > When running python nft-tests.py with -j, I get this here:
> >
> > bridge/meta.t: WARNING: line 7: '{"nftables": [{"add": {"rule":
> > {"table": "test-bridge", "chain": "input", "family": "bridge", "expr":
> > [{"match": {"op": "==", "right": "0x8100", "left": {"meta": {"key":
> > "ibrvproto"}}}}]}}}]}': '[{"match": {"left": {"meta": {"key":
> > "ibrvproto"}}, "op": "==", "right": "0x8100"}}]' mismatches
> > '[{"match": {"left": {"meta": {"key": "ibrvproto"}}, "op": "==",
> > "right": 33024}}]'
> > /tmp/nftables/tests/py/bridge/meta.t.json.output.got:
> > WARNING: line 2: Wrote JSON output for rule meta ibrvproto 0x8100
> >
> > Then, if I type:
> >
> > nft rule x y meta protocol vlan
> >
> > Then, printing shows:
> >
> > table ip x {
> > chain y {
> > meta protocol vlan
> > }
> > }
> >
> > However, with:
> >
> > nft rule x y meta ibrvproto vlan
> >
> > I get this:
> >
> > table bridge x {
> > chain y {
> > meta ibrvproto 0x8100
> > }
> > }
> >
> > I think the problem the endianess in the new key definitions are not
> > correct.
> >
> > The br_vlan_get_proto() in the kernel returns a value in network byte
> > order.
> >
> > I think this does not match either then? Because bytecode is
> > incorrect?
>
> The br_vlan_get_proto returns vlan_proto in host byte order.
Then, that's why ethertype datatype does not work, because it expects
this network byteorder.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH nft v5] meta: add ibrpvid and ibrvproto support
2019-08-26 14:37 ` Pablo Neira Ayuso
@ 2019-08-27 3:10 ` wenxu
2019-08-28 8:30 ` Pablo Neira Ayuso
0 siblings, 1 reply; 6+ messages in thread
From: wenxu @ 2019-08-27 3:10 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel
On 8/26/2019 10:37 PM, Pablo Neira Ayuso wrote:
> On Mon, Aug 26, 2019 at 09:51:57PM +0800, wenxu wrote:
>> 在 2019/8/26 18:26, Pablo Neira Ayuso 写道:
>>> On Fri, Aug 23, 2019 at 09:45:28PM +0800, wenxu@ucloud.cn wrote:
>>>> From: wenxu <wenxu@ucloud.cn>
>>>>
>>>> This allows you to match the bridge pvid and vlan protocol, for
>>>> instance:
>>>>
>>>> nft add rule bridge firewall zones meta ibrvproto 0x8100
>>>> nft add rule bridge firewall zones meta ibrpvid 100
>>> When running python nft-tests.py with -j, I get this here:
>>>
>>> bridge/meta.t: WARNING: line 7: '{"nftables": [{"add": {"rule":
>>> {"table": "test-bridge", "chain": "input", "family": "bridge", "expr":
>>> [{"match": {"op": "==", "right": "0x8100", "left": {"meta": {"key":
>>> "ibrvproto"}}}}]}}}]}': '[{"match": {"left": {"meta": {"key":
>>> "ibrvproto"}}, "op": "==", "right": "0x8100"}}]' mismatches
>>> '[{"match": {"left": {"meta": {"key": "ibrvproto"}}, "op": "==",
>>> "right": 33024}}]'
>>> /tmp/nftables/tests/py/bridge/meta.t.json.output.got:
>>> WARNING: line 2: Wrote JSON output for rule meta ibrvproto 0x8100
>>>
>>> Then, if I type:
>>>
>>> nft rule x y meta protocol vlan
>>>
>>> Then, printing shows:
>>>
>>> table ip x {
>>> chain y {
>>> meta protocol vlan
>>> }
>>> }
>>>
>>> However, with:
>>>
>>> nft rule x y meta ibrvproto vlan
>>>
>>> I get this:
>>>
>>> table bridge x {
>>> chain y {
>>> meta ibrvproto 0x8100
>>> }
>>> }
>>>
>>> I think the problem the endianess in the new key definitions are not
>>> correct.
>>>
>>> The br_vlan_get_proto() in the kernel returns a value in network byte
>>> order.
>>>
>>> I think this does not match either then? Because bytecode is
>>> incorrect?
>> The br_vlan_get_proto returns vlan_proto in host byte order.
> Then, that's why ethertype datatype does not work, because it expects
> this network byteorder.
So should I add new vlanproto datatype for this case? Or Convert the vlanproto to network byteorder in kernel like what NFT_META_PROTOCOL did?
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH nft v5] meta: add ibrpvid and ibrvproto support
2019-08-27 3:10 ` wenxu
@ 2019-08-28 8:30 ` Pablo Neira Ayuso
0 siblings, 0 replies; 6+ messages in thread
From: Pablo Neira Ayuso @ 2019-08-28 8:30 UTC (permalink / raw)
To: wenxu; +Cc: netfilter-devel
On Tue, Aug 27, 2019 at 11:10:29AM +0800, wenxu wrote:
>
> On 8/26/2019 10:37 PM, Pablo Neira Ayuso wrote:
> > On Mon, Aug 26, 2019 at 09:51:57PM +0800, wenxu wrote:
> >> 在 2019/8/26 18:26, Pablo Neira Ayuso 写道:
[...]
> >> The br_vlan_get_proto returns vlan_proto in host byte order.
> > Then, that's why ethertype datatype does not work, because it expects
> > this network byteorder.
>
> So should I add new vlanproto datatype for this case? Or Convert
> the vlanproto to network byteorder in kernel like what
> NFT_META_PROTOCOL did?
Yes please, send me a patch to fix for nf.git to get
NFT_META_BRI_IIFVPROTO in sync with NFT_META_PROTOCOL, ie. use network
byte order.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-08-28 8:30 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-23 13:45 [PATCH nft v5] meta: add ibrpvid and ibrvproto support wenxu
2019-08-26 10:26 ` Pablo Neira Ayuso
2019-08-26 13:51 ` wenxu
2019-08-26 14:37 ` Pablo Neira Ayuso
2019-08-27 3:10 ` wenxu
2019-08-28 8:30 ` Pablo Neira Ayuso
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).