On 03/04/2018 10:40 AM, Florian Westphal wrote: > Matthias Schiffer <mschiffer@xxxxxxxxxxxxxxxxxxxx> wrote: >> I recently found myself in a situation that required me to filter IGMP >> packets of certain types on a bridge. Switching to nftables is >> unfortunately not an option at the moment because of hardware constraints, >> in particular regarding code size; > > Is there anything we can do on nftables side to make switch more viable? > Our system (the open mesh network framework Gluon) is based on OpenWrt, and our non-ebtables firewall is implemented as a ruleset for the OpenWrt firewall fw3, which is based on iptables. Porting fw3 to libnftnl is planned, but I don't expect it to be happening any time soon. Switching from ebtables to nftables without also dropping iptables from Gluon is definitely out of the question, which leaves us with two options for the switch to nftables: waiting for (or working on) the fw3 port, or replacing fw3 altogether (which would also force users of Gluon to work with lower-level rules when making custom changes to the firewall of their deployment). Because of the above challenges, I have not looked into the nftables userspace components in much detail yet. libnftnl is ~45KB (MIPS, LZMA-compressed), libmnl another ~6KB, which is acceptable if we can throw out all of iptables and ebtables. I noticed that more than 25% of binary size of libnftnl are made up of snprintf functions. Having these in a library with the goal to abstract the netlink interface of nftables seems questionable to me, but I have no idea if it would be viable to move these functions to nft or to a separate library. The size of the nft binary is much more problematic (~165KB compressed); I assume we will have to create our own specialized replacement based on libnftnl. Kind regards, Matthias
Attachment:
signature.asc
Description: OpenPGP digital signature
