WiFi Hotspot reinstall leads to doubled entries in `/etc/iptables.ipv4.nat` resp. `...ipv6.nat`

[StephanStS]

Creating a bug report/issue

• I have searched the existing open and closed issues

Required Information

• DietPi version | cat /boot/dietpi/.version

  G_DIETPI_VERSION_CORE=9
  G_DIETPI_VERSION_SUB=1
  G_DIETPI_VERSION_RC=0
  G_GITBRANCH='dev'
  G_GITOWNER='MichaIng'
  

• Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
bookworm 0
• Kernel version | uname -a
Linux pi5 6.1.0-rpi8-rpi-2712 #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 (2024-01-25) aarch64 GNU/Linux
• SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3) -> RPi5

Additional Information (if applicable)

• Software title | WiFi Hotspot
• Was the software title installed freshly or updated/migrated? -> freshly / reinstalled
• Can this issue be replicated on a fresh installation of DietPi? -> Yes

Steps to reproduce

1. dietpi-software install 60
2. dietpi-software reinstall 60

Expected behaviour

• /etc/iptables.ipv4.nat should have only one entry

  -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
  -A FORWARD -i wlan0 -o eth0 -j ACCEPT
  

  resp.

  -A POSTROUTING -o eth0 -j MASQUERADE
  

Actual behaviour

• entries occur doubled

  -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
  -A FORWARD -i wlan0 -o eth0 -j ACCEPT
  -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
  -A FORWARD -i wlan0 -o eth0 -j ACCEPT
  

  resp.

  -A POSTROUTING -o eth0 -j MASQUERADE
  -A POSTROUTING -o eth0 -j MASQUERADE
  

Extra details

• dietpi-software uninstall 60 removes both entries
• The doubled entries seem to be no real problem, but should not be

[MichaIng]

Makes sense, as we do not reset/clear iptables rules, to not break a possible VPN connection, killswitch or the connection currently used to do the reinstall, e.g. if you connect with a WiFi client already, or similar.

There are a few issues, actually:

• The doubled entries are not a big problem, but not great either. We could check iptables -L for a duplicate, before adding a rule.
• But in above cases, we do also store VPN or other hotspot/AP related rules to those files. Actually it would be better to store only those rules, which are added for the hostspot, and not anything else. Other rules are supposed to be added by the other respective application, like the VPN server, and those are supposed to start after the WiFi interface is up and has the base hostspot rules set. But it is not 100% safe either, as the hotspot is not the internet-facing interface, and hence there are clearly use cases where a VPN or other such thing is coming up first, and the hotspot interface later. In this case, it would clear any previously added rules. Ah, and more importantly: If iptables is used as firewall as well, which is usually aimed to be configured before network, of course, then it would be reverted as well.

So not 100% sure how to do best. Probably we need two iptables configs: One which runs when the WiFi interface is configured, which adds only the hotspot related rules, but does NOT clear any previously added rule. And one which removes only the hotspot related rules, but nothing else, which runs when the WiFi interface is brought down 🤔.