| Message ID | 20220228213730.1102620-1-hauke@hauke-m.de |
|---|---|
| State | Superseded |
| Delegated to: | Hauke Mehrtens |
| Headers | show |
| Series | [1/2] realtek: Use firewall4 | expand |
Petr Štetiar <ynezz@true.cz> writes: > Sander Vanheule <sander@svanheule.net> [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
On Tue, Mar 01, 2022 at 09:51:32PM +0100, Bjørn Mork wrote: > Petr Štetiar <ynezz@true.cz> writes: > > > Sander Vanheule <sander@svanheule.net> [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.
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
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. > On Mar 1, 2022, at 4:11 PM, Daniel Golle <daniel@makrotopia.org> wrote: > > On Tue, Mar 01, 2022 at 09:51:32PM +0100, Bjørn Mork wrote: >> Petr Štetiar <ynezz@true.cz> writes: >> >>> Sander Vanheule <sander@svanheule.net> [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
Daniel Golle <daniel@makrotopia.org> [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
On Tue, 2022-03-01 at 09:09 +0100, Petr Štetiar wrote: > Sander Vanheule <sander@svanheule.net> [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
Hi everyone, On Thu, 2022-03-03 at 15:58 +0100, Petr Štetiar wrote: > Daniel Golle <daniel@makrotopia.org> [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
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
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
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
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))
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 <hauke@hauke-m.de> --- target/linux/realtek/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)