realtek: remove firewall and other core components? [Was: Re: [PATCH 1/2] realtek: Use firewall4]

[Hauke Mehrtens]

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