FS#31 - firewall3 fails to reload iptables policy extension

[openwrt-bot]

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

[openwrt-bot]

jow-:

Phew, thanks for the report. I'll investigate.

[openwrt-bot]

jow-:

I came up with a different approach which is less invasive compared to your multi process suggestion. Please give the attached patch a try and tell me if it solves your extension loading problem.

[openwrt-bot]

mpa:

Yes, the problem is solved, and your solution seems better than my idea.

The warnings are gone, and the policy matches now also appear in IPv4 nat and IPv6 filter, where they were previously missing.

Thank you. Mirko

[openwrt-bot]

jow-:

Fixed in master with http://git.lede-project.org/113544d