On 3/23/22 23:10, Birger Koblitz wrote:
Hi,
On 23/03/2022 21:09, Sander Vanheule wrote:
Hi everyone,
One extra argument in favour of keeping the firewall in the default
config, is that the
devices with more advanced stock FW also provide an ACL feature to
filter out traffic
based on MAC, IP, ethernet frame contents, etc. However, this is
offloaded to a hardware
engine in the switch, but I'm not up to date on how well this
offloading currently works
(with nftables). So, providing a firewall would put OpenWrt on the
same feature level as
more advanced vendor offerings.
The features are quite powerful, even on RTL838x devices. The problem is
that they are not
usable with nftables at least in kernel 5.10 because netfilter offload
is so limited. The offloading
works via tc flower, which has extensive offloading support. I don't
really understand how
this flow offloading can be used via nftables. There is a lot of
development ongoing,
it seems kernel 5.13 was a big step forward.
The layer 2 (MAC, VLAN, Ethernet frame contents) offloading in Linux is
normally done over tc and not nftabels. With flower you can filter,
redirect and modify packets based on VLAN IDs, VLAN PCP, MAC addresses,
.. and so on. qdisc allows to configure traffic schedulers to do advance
QoS based on Ethernet frames.
I think we backported all of the patches from flow offloading from
kernel 5.15 to our kernel 5.10.
The net/netfilter/nf_flow_table_core.c file in OpenWrt kernel 5.10 looks
very similar to upstream 5.15.
Supporting tc flower and offloading it requires however about a dozen
kernel modules and user
space tools, which is really tricky to get right. It would be great to
have these packets
on board by default, to make this feature more usable, also for people
to test it.
The tc command should be sufficient to configure the flower offloading,
but we would need some more kernel modules, which are already packed,
but not interluded by default in OpenWrt.
OpenWrt misses some central configuration service for tc flower and tc
qdisc as far as I know. We could add this to netifd.
I yesterday learned that someone was using an 838x device for OLSR with
between 200 and 300 offloaded
next-hop routes, so the hardware offload is something that interests
people who would normally
find this only in proprietary vendor solutions.>
Some of the switches which are used on normal consumer routers have some
of these features as well. The Lantiq/Maxlinear switches support for
example filtering based on VID, PCP and can also remove and add VLAN
tags. They also support different traffic scheduling algorithms.
Currently this is not implemented in the driver used in OpenWrt and I am
not sure what is supported by the Lantiq switch support by Openwrt.
Hauke
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
