Re: realtek: remove firewall and other core components? [Was: Re: [PATCH 1/2] realtek: Use firewall4]
Hi, 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. Ah, so they are complementary, thanks for that explanation. The layer 2 stuff that is done with flower is all implemented as HW offloaded in the driver btw for all SoCs and cursory testing seems to show it works. The QoS is missing so far. 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. Indeed this would be great, because if routing is configured and offloaded this can circumvent firewall filtering. If there is central configuration support, this is much easier to set up by users and sanity checks can be done, i.e. that the filtering rules come first, before offloading the routes as both are handled by the Packet Inspection Engine and this handles rules strictly in the sequence they are ordered in the content addressable memory. Currently this only depends on the sequence routes and tc rules are being set up. The HW would however also support re-ordering of rules even while switching packets. 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 Cheers, Birger ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: realtek: remove firewall and other core components? [Was: Re: [PATCH 1/2] realtek: Use firewall4]
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
Re: realtek: remove firewall and other core components? [Was: Re: [PATCH 1/2] realtek: Use firewall4]
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. 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. 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. Obviously users may still install them if they really want their switch to act as DHCP server and/or caching DNS resolver. This topic is about firewall4, so are you suggesting to post-install firewall4 package as well? Dropping dnsmasq and odhcpd-ipv6only makes more sense to me, since these are not features that are normally provided on a managed switch AFAIK. Agreed. Cheers, Birger ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: realtek: remove firewall and other core components? [Was: Re: [PATCH 1/2] realtek: Use firewall4]
Hi everyone, On Thu, 2022-03-03 at 15:58 +0100, Petr Štetiar wrote: > Daniel Golle [2022-03-01 21:11:49]: > > Hi, > > > I fully agree, none of those packages make much sense on this class of > > devices and all of them should be dropped from default installations. > > I think, that if you personaly don't care about other valid use cases, you > should at least try to consider current 21.02 users as some realtek targets > are already supported and removing firewall package has security related > implications. Since 22.03 has now been branched, I think we should decide on where we want to go with the default package selection for realtek (and other managed switches). 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. > > > Obviously users may still install them if they really want their switch to > > act as DHCP server and/or caching DNS resolver. > > This topic is about firewall4, so are you suggesting to post-install firewall4 > package as well? Dropping dnsmasq and odhcpd-ipv6only makes more sense to me, since these are not features that are normally provided on a managed switch AFAIK. Best, Sander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] realtek: Use firewall4
On Tue, 2022-03-01 at 09:09 +0100, Petr Štetiar wrote:
> Sander Vanheule [2022-02-28 23:00:34]:
>
> Hi,
>
> > Commit 9e7149f729e9 ("realtek: revert to "standard" management
> > configuration") changed
> > the
> > default port configuration for realtek devices to only have LAN ports,
> > instead of the
> > LAN/WAN VLANs that were used before.
>
> IMO default device configuration and default OS feature set are two different
> topics.
>
> > I wonder if it doesn't make more sense to drop the firewall package from the
> > default now, since there is only one interface, unless there is a different
> > reason to keep the firewall.
>
> 1. consistency
> 2. supporting more common use cases out of the box
> 3. wider testing audience of core networking components
These are valid arguments, but to me rather arguments to move the firewall from
DEFAULT_PACKAGES.router to DEFAULT_PACAKGES. That way they wouldn't have to be
added
separately on non-router devices. OpenWrt devices with DEVICE_TYPE=nas also
don't come
with a firewall by default AFAICT. I think if you feel the firewall should be
included by
default on a switch with only lan-facing ports, it would certainly make sense
to include
it on a NAS too.
Best,
Sander
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
realtek: remove firewall and other core components? [Was: Re: [PATCH 1/2] realtek: Use firewall4]
Daniel Golle [2022-03-01 21:11:49]: Hi, > I fully agree, none of those packages make much sense on this class of > devices and all of them should be dropped from default installations. I think, that if you personaly don't care about other valid use cases, you should at least try to consider current 21.02 users as some realtek targets are already supported and removing firewall package has security related implications. > Obviously users may still install them if they really want their switch to > act as DHCP server and/or caching DNS resolver. This topic is about firewall4, so are you suggesting to post-install firewall4 package as well? Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] realtek: Use firewall4
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
> On Mar 1, 2022, at 4:11 PM, Daniel Golle wrote:
>
> On Tue, Mar 01, 2022 at 09:51:32PM +0100, Bjørn Mork wrote:
>> Petr Štetiar writes:
>>
>>> Sander Vanheule [2022-02-28 23:00:34]:
>>>
I wonder if it doesn't make more sense to drop the firewall package from
the
default now, since there is only one interface, unless there is a different
reason to keep the firewall.
>>>
>>> 1. consistency
>>
>> With what exactly? It's a switch. It doesn't need router specific
>> software.
>
> We may need to add a 'switch' DEVICE_TYPE in include/target.mk
> selecting packages relevant for this class of devices.
> ('bridge' or 'ip-full', 'ethtool', ...)
>
>>
>>> 2. supporting more common use cases out of the box
>>
>> It's just bloat. The flash size is small on many of these devices.
>
> It's rather the very limited performance of the CPU and Ethernet MAC
> used for the CPU port which makes me disregard those (layer-2)
> switches being used for anything else than that.
>
>>
>>> 3. wider testing audience of core networking components
>>
>> The firewall package is tested on most devices. This should be enough.
>>
>> I'm with Sander. Please drop the firewall package. Not sure how useful
>> dnsmasq and odhcpd-ipv6only are either? Why would I want those on my
>> switch? It's not a router, DNS server or DHCP server.
>
> Exactly. I fully agree, none of those packages make much sense on this
> class of devices and all of them should be dropped from default
> installations. Obviously users may still install them if they really
> want their switch to act as DHCP server and/or caching DNS resolver.
>
For consistency this should be applied to other switches already supported by
OpenWrt.
I am aware of a couple of non-realtek switches already supported:
Ubiquiti EdgeSwitch 5XP
Ubiquiti EdgeSwitch 8XP
Ray
signature.asc
Description: Message signed with OpenPGP
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] realtek: Use firewall4
Hi,
On 01/03/2022 22:11, Daniel Golle wrote:
We may need to add a 'switch' DEVICE_TYPE in include/target.mk
selecting packages relevant for this class of devices.
('bridge' or 'ip-full', 'ethtool', ...)Indeed, these devices are really not
routers. Let's have the right
packages for them installed, and only those. I have a couple of
the realtek switches in use and none of them is routing anything or
would need a firewall. They are really what they are sold for: smart
switches, very good with VLANs and switching across many ports.
2. supporting more common use cases out of the box
It's just bloat. The flash size is small on many of these devices.
It's rather the very limited performance of the CPU and Ethernet MAC
used for the CPU port which makes me disregard those (layer-2)
switches being used for anything else than that.
The RTL93xx based devices are probably a bit more powerful and have layer 3
offload support, but it will take some time until I would trust them at
the edge of a network. At that point probably other packages are needed than
software-based firewalling. So in my opinion, let's drop firewall and DHCP/DNS
server packages.
Cheers,
Birger
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] realtek: Use firewall4
On Tue, Mar 01, 2022 at 09:51:32PM +0100, Bjørn Mork wrote:
> Petr Štetiar writes:
>
> > Sander Vanheule [2022-02-28 23:00:34]:
> >
> >> I wonder if it doesn't make more sense to drop the firewall package from
> >> the
> >> default now, since there is only one interface, unless there is a different
> >> reason to keep the firewall.
> >
> > 1. consistency
>
> With what exactly? It's a switch. It doesn't need router specific
> software.
We may need to add a 'switch' DEVICE_TYPE in include/target.mk
selecting packages relevant for this class of devices.
('bridge' or 'ip-full', 'ethtool', ...)
>
> > 2. supporting more common use cases out of the box
>
> It's just bloat. The flash size is small on many of these devices.
It's rather the very limited performance of the CPU and Ethernet MAC
used for the CPU port which makes me disregard those (layer-2)
switches being used for anything else than that.
>
> > 3. wider testing audience of core networking components
>
> The firewall package is tested on most devices. This should be enough.
>
> I'm with Sander. Please drop the firewall package. Not sure how useful
> dnsmasq and odhcpd-ipv6only are either? Why would I want those on my
> switch? It's not a router, DNS server or DHCP server.
Exactly. I fully agree, none of those packages make much sense on this
class of devices and all of them should be dropped from default
installations. Obviously users may still install them if they really
want their switch to act as DHCP server and/or caching DNS resolver.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] realtek: Use firewall4
Petr Štetiar writes: > Sander Vanheule [2022-02-28 23:00:34]: > >> I wonder if it doesn't make more sense to drop the firewall package from the >> default now, since there is only one interface, unless there is a different >> reason to keep the firewall. > > 1. consistency With what exactly? It's a switch. It doesn't need router specific software. > 2. supporting more common use cases out of the box It's just bloat. The flash size is small on many of these devices. > 3. wider testing audience of core networking components The firewall package is tested on most devices. This should be enough. I'm with Sander. Please drop the firewall package. Not sure how useful dnsmasq and odhcpd-ipv6only are either? Why would I want those on my switch? It's not a router, DNS server or DHCP server. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] realtek: Use firewall4
Sander Vanheule [2022-02-28 23:00:34]:
Hi,
> Commit 9e7149f729e9 ("realtek: revert to "standard" management
> configuration") changed the
> default port configuration for realtek devices to only have LAN ports,
> instead of the
> LAN/WAN VLANs that were used before.
IMO default device configuration and default OS feature set are two different
topics.
> I wonder if it doesn't make more sense to drop the firewall package from the
> default now, since there is only one interface, unless there is a different
> reason to keep the firewall.
1. consistency
2. supporting more common use cases out of the box
3. wider testing audience of core networking components
to name a few.
Cheers,
Petr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] realtek: Use firewall4
Hauke Mehrtens [2022-02-28 22:37:29]: > The realtek target is not a router, but basic device, see DEVICE_TYPE. > The basic device type does not come with firewall by default, see > include/target.mk for details. The realtek target extended > DEFAULT_PACKAGES manually with firewall. > > This changes the defaults to take firewall4 and nftables instead of > firewall and iptables. This also adds the additional package > kmod-nft-offload. > The only difference to the router type is the missing ppp and > ppp-mod-pppoe package. > > This increases the compressed image size by about 260KBytes. > > Signed-off-by: Hauke Mehrtens Acked-by: Petr Štetiar ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] realtek: Use firewall4
On 2/28/22 23:00, Sander Vanheule wrote:
Hi Hauke,
On Mon, 2022-02-28 at 22:37 +0100, Hauke Mehrtens wrote:
The realtek target is not a router, but basic device, see DEVICE_TYPE.
The basic device type does not come with firewall by default, see
include/target.mk for details. The realtek target extended
DEFAULT_PACKAGES manually with firewall.
This changes the defaults to take firewall4 and nftables instead of
firewall and iptables. This also adds the additional package
kmod-nft-offload.
The only difference to the router type is the missing ppp and
ppp-mod-pppoe package.
This increases the compressed image size by about 260KBytes.
Signed-off-by: Hauke Mehrtens
Commit 9e7149f729e9 ("realtek: revert to "standard" management configuration")
changed the
default port configuration for realtek devices to only have LAN ports, instead
of the
LAN/WAN VLANs that were used before. I wonder if it doesn't make more sense to
drop the
firewall package from the default now, since there is only one interface,
unless there is
a different reason to keep the firewall.
We can also remove firewall4 support from the realtek target. Probably
most people will not use it for routing and if so they can install
firewall4 manually. I just do not want to ship firewall3 by default.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] realtek: Use firewall4
Hi Hauke,
On Mon, 2022-02-28 at 22:37 +0100, Hauke Mehrtens wrote:
> The realtek target is not a router, but basic device, see DEVICE_TYPE.
> The basic device type does not come with firewall by default, see
> include/target.mk for details. The realtek target extended
> DEFAULT_PACKAGES manually with firewall.
>
> This changes the defaults to take firewall4 and nftables instead of
> firewall and iptables. This also adds the additional package
> kmod-nft-offload.
> The only difference to the router type is the missing ppp and
> ppp-mod-pppoe package.
>
> This increases the compressed image size by about 260KBytes.
>
> Signed-off-by: Hauke Mehrtens
Commit 9e7149f729e9 ("realtek: revert to "standard" management configuration")
changed the
default port configuration for realtek devices to only have LAN ports, instead
of the
LAN/WAN VLANs that were used before. I wonder if it doesn't make more sense to
drop the
firewall package from the default now, since there is only one interface,
unless there is
a different reason to keep the firewall.
Best,
Sander
> ---
> target/linux/realtek/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/linux/realtek/Makefile b/target/linux/realtek/Makefile
> index 704242a000a0..91af5fbcfce1 100644
> --- a/target/linux/realtek/Makefile
> +++ b/target/linux/realtek/Makefile
> @@ -18,7 +18,7 @@ endef
> include $(INCLUDE_DIR)/target.mk
>
> DEFAULT_PACKAGES += uboot-envtools ethtool kmod-gpio-button-hotplug \
> - dnsmasq firewall ip6tables iptables odhcp6c odhcpd-ipv6only \
> + dnsmasq firewall4 nftables kmod-nft-offload odhcp6c odhcpd-ipv6only \
> ip-full ip-bridge tc
>
> $(eval $(call BuildTarget))
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
