meta priority is local, it again changes nothing on the wire.
I found another indication that 802.1Q VLAN packets can be filtered by specifying device eth1.
table netdev t {
set s {
typeof ether saddr . vlan id
size 2048
flags dynamic,timeout
timeout 1m
}
chain c {
type filter hook ingress device eth0 priority 0; policy accept;
ether type != 8021q update @s { ether daddr . 123 } counter
}
}
Source: https://lore.kernel.org/netdev/ZA931rfLiLHx1KjD@salvia/T/
In the above snippet, we can see device eth0 not device eth0.vid. Then, we can see ether type != 8021q. This implies the existence of 802.1Q frames in the chain c with device eth0, otherwise it would make no sense to check that the frame is not of type 802.1Q.
1 Like
You are permitted to use fw4 includes. Actually first example is great for rule (dscp target is last in list)
There is absolutely no win in duplicating fib in lowest level hook.
Hi
Basically, each table has its own purpose.
At the lower level ( netdev ) the Ethernet packets are not yet fully ready, they could be fragment .
The dcsp marking is done usually at mangle level, this means at inet level.
I'm not sure which answer you are looking for, but at netdev level, even though the sintaxis allow to do that, I would not expect a rule is dealing with dcsp actually work
1 Like
It can set ethernet PCP, the earlier you start the more accurately kernel does implicit processing ordered - PCP, DSCP, WMM class.
AF packets cannot be filtered without the egress hook. It allows to filter raw packets. It's needed for a DHCPv4 client. Indeed, my ISP requires DHCP packets encapsulated in frames with priority code point 6 (PCP) using VLAN 832.
My question is relatively simple to understand.
Is it possible to filter packets encapsulated in an 802.1Q frame with device eth1 (and not device eth1.vid) specified in a chain with the egress hook in a netdev table?
Yes or no? Why or why not?
Please, provide an explanation!
Fairly simple, use raw_output oif wan.832 and set dscp. Output is misnomer, it goes after ct meta is released and all other postroutings in ct are done. priority is local version of dscp that does not alter packets.
Add counters between filter conditions to get most selective first.
s/priority/dscp/1
This issue drives me crazy! I have also tried to filter from br-lan to test payload expression combinations in the rule.
gilaro@OpenWrt:~$ sudo nft list table netdev pcp
table netdev pcp {
chain egress {
type filter hook egress device "br-lan" priority filter; policy accept;
vlan id 10 vlan type ip6 tcp sport 22 meta priority set 0:6 counter packets 135 bytes 61020
}
}
I'm seeing in the tcpdump capture that the rule sets the PCP to 6 in the SSH packets. When I set the egress_qos_mapping in the LuCi GUI, the configuration created a new device br-lan with 8021q, vid to 10 and egress_qos_mapping to 6:6. In my previous configuration, the interface br-lan.10 was defined with bridge-vlan and vlan set to 10.
Note: to test the following code, I upgraded nftables (v1.1.0) and libnftnl to their newest versions.
It will not cover the full range of your problem, but it will solve the half of it
It's comom from ISP to use vlan , you could create a bridge, and inside that bridge create the vlan with the ID that you need, it's easy and flexible do the vlan with the vlan bridge filtering. To the bridge you could add any interface and choose if it will attend the traffic with or without tags. This solves half of problem .
I've chosen a new approach to solve this issue. I'd have to separate out all the potential sources of error and then redo my tests. I'm obliged to do this because I haven't had a clear answer, if any at all. So first I'll see if I can get a working Internet connection and then I'll come back to this issue.
I managed to connect in IPv6 with the skpriority option. I tried to specify a rule to change the PCP to 6 of DHCPv4 packets without success.
Do not work:
table netdev filter {
chain egress {
type filter hook egress device eth1 priority filter; policy accept;
vlan id 832 meta priority set ip saddr { 0.0.0.0 : 0:6 } ip dscp set cs6
}
}
table netdev filter {
chain egress {
type filter hook egress device eth1 priority filter; policy accept;
meta priority set ip saddr { 0.0.0.0 : 0:6 } ip dscp set cs6
}
}
On the other hand, I see that DSCP is correctly modified, which could mean that the feature to modify the internal priority of packets encapsulated in 802.1Q frames does not exist.
However, it has been reported to work when the following rule is injected at startup after the eth1.832 virtual interface has been created.
table netdev filter {
chain egress {
type filter hook egress device eth1.832 priority filter; policy accept;
udp dport 67 meta priority set 0:6 ip dscp set cs6 comment "Set CoS value to 6 for DHCPv4 packets"
}
}
See also my other thread: How do I create an interface before fw4 starts?
meta priority is inherited when you set dscp, and you can set later via normal traffic rules?
Sorry, I don't understand what you're saying.
ip dscp set cs6 is enough.
Tell that to my ISP. DHCPv4 packets encapsulated in frames that do not have a PCP with a value of 6 are dropped.
I'm tired of repeating myself. Make sure you read the whole messages.
Attach PCAP of "acceptable" dhcp excange. I dont get you want PCP or ToS set depending on time of day.
Hi!
My issue is that netifd creates interfaces and launches protocols. I'll need to inject firewall rules after the interfaces have been created but before netifd launches the DHCP clients.
I need to inject firewall rules after the WAN virtual network interfaces have been created to modify the priority of 802.1Q frames encapsulating the DHCP packets (Priority Code Point) in an egress chain of a netdev table (device eth1.832). The 802.1Q frames must have a PCP set to 6 because this is a requirement of my ISP.
netifd is launched at startup by the network service.
Is it possible to do so?