mpa:

• Source revision:
  LEDE Reboot (HEAD, r607)

• Affected device:
  Tested on TP-LINK TD-W8980 and on a x86 VM. This issue is likely device-independent.

• Issue description:
  In firewall3, the iptables extension libxt_policy.so only works for the first (address family; table) combination and fails for all subsequent ones. Where it fails, the firewall rules containing the policy match are missing, and a warning is printed instead.
  This is a regression from OpenWrt CHAOS CALMER (15.05.1).

• Steps to reproduce:

###download and install firmware image lede-lantiq-xrx200-TDW8980-squashfs-sysupgrade.bin

fw3 -d restart

Result: firewall rules as expected

opkg install iptables-mod-ipsec

uci set "firewall.@zone[0].extra_src=-m policy --dir in --pol none"

uci set "firewall.@zone[0].extra_dest=-m policy --dir out --pol none"

fw3 -d restart

Results:

• firewall rules with "-m policy" are missing in all tables except IPv4 filter.
• repeated output: Warning: fw3_ipt_rule_append(): Can't find match 'policy'

• What you have already done to fix the problem / Any additional info you think is important

My experiments seem to confirm that this is caused by missing dlclose support in musl libc.
firewall3 uses dlclose/dlopen to reload iptables extensions for each address family and table,
and it expects the extensions' constructor functions to be called each time.
In musl, dlclose does nothing, and unloading/reloading of a shared library does not call its constructor function again.
To check my theory, I added explicit calls to the extensions' _init() functions via dlsym.
This made the policy match work again in all tables, but then firewall3 hangs on exit (tested with LEDE r289).
I don't now if it is actually allowed to call dynamic library constructor functions explicitly.

Then I considered a more complex solution, but have no code for it yet.
In short:

• split off xtables/iptc-related functions from iptables.c to run in a child process
• an RPC-like mechanism based on pipes, to call these functions
• terminate and recreate the child process at each fw3_ipt_close/fw3_ipt_open

However, I would like to hear your opinion first how this bug should best be solved.
If you want to work on this yourself, I'll step back and watch.

Regards
Mirko