Hi,

On Tue, Oct 25, 2022 at 02:36:35PM +0200, Michael Lilja wrote:

Hi,

No problem. Here is a snippet of the rulesets in play. I simplified it because there are a lot of devices and a lot of schedules per device. The ‘mark’ is set by userspace so not all flow types are offloaded, that is controlled by userspace:

- - - - snip start - - - - 
table inet fw4 {
	flowtable ft {
	hook ingress priority filter
	devices = { lan1, lan2, wan }
	flags offload
}

 chain mangle_forward {
	type filter hook forward priority mangle; policy
	meta mark set ct mark
	meta mark 0x00000000/16 queue flags bypass to 0
 }


chain my_devices_rules {
	ether saddr 96:68:97:a7:e8:a7 jump fw_p0_dev0 comment “Device match”
}

chain fw_p0_dev0 {
	meta time >= "2022-10-09 18:46:50" meta time < "2022-10-09 19:16:50" counter packets 0 bytes 0 drop comment "!Schedule OFFLINE override"
	meta day “Tuesday" meta hour >= "06:00" meta hour < "07:00" drop
}

chain forward {
	 type filter hook forward priority filter; policy accept;
	jump my_devices_rules
}

chain my_forward_offload {
	type filter hook forward priority filter + 1; policy accept;
	meta mark != 0x00000000/16 meta l4proto { tcp, udp } flow add @ft
}

chain mangle_postrouting {
	type filter hook postrouting priority mangle; policy accept;
	ct mark set meta mark
}
- - - - snip end - - - -

The use case is that I have schedules per device to control when
they are allowed access to the internet and if the flows are
offloaded they will not get dropped once the schedule kicks in.

Thanks for explaining.

I suggest to move your 'forward' chain to netdev/ingress using priority

      filter - 1

so the time schedule evaluation is always done before the flowtable
lookup, that is, schedules rules will be always evaluated.

In your example, you are using a linear ruleset, which might defeat
the purpose of the flowtable. So I'm attaching a new ruleset
transformed to use maps and the ingress chain as suggested.