Hi, > On 15 Nov 2020, at 13:36, Matthias Fischer wrote: > > Hi, > > On 13.11.2020 17:57, Matthias Fischer wrote: >> On 13.11.2020 15:23, Michael Tremer wrote: > > [Slightly shortened, kept the relevant parts] > >>> ... >> >>>> - Where (E.g: firewall init script, rules.pl, wirelessctrl.c, ...) >>>> should the necessary iptables rules be processed? >>>> [Some ideas how this could be done, but no "breakthrough". Current >>>> option-settings are processed in several scripts. Which one to use!?] >>> >>> This would probably go into /etc/init.d/firewall. > > Sorry, but *which* line? I'm really not sure. I suppose somewhere after > line 179f which read: > ... > iptables -t nat -N CUSTOMPREROUTING > iptables -t nat -A PREROUTING -j CUSTOMPREROUTING > ... > > I don't want to mess things up - especially in *this* script! > We need an "if"-query to check for ON/OFF there, ok. > But the more often I read this script the less sure I am where this code > can be inserted best. Where? Hints? If we do not go with the generic redirection option, I would suggest to put this before the CAPTIVE_PORTAL chain and create another chain with the redirection rules. > Besides, deactivating these rules would need a complete reboot!? Or do I > overlook something? Yes, this would be true. We could otherwise create a extra script that is only executed when this is enabled like we do with the captive portal. > Because if this should be the case then on the firewall options page the > entries that require a restart should be *marked* to make things easier > and more clearly. Otherwise you switch ON <-> OFF or vice versa without > *really* realising that your changes "need a reboot". The notice "Some > options need a reboot to take effect" is not sufficiently meaningful. > "Some options..."!? Which? Yes, I find this quite annoying… Maybe we should in general move these things to not require a reboot? I believe reloading the whole firewall is something we can support right now. -Michael > Best, > Matthias