Example: LAN IP 10.0.1.1/24 OPT1 IP 10.0.2.1/24
Rules with SRC or DST LANnet correctly have 10.0.0.0/24 (the subnet base address) in /tmp/rules.debug
Rules with SRC or DST OPT1net have 10.0.2.1/24 (the OPT1 IP address with OPT1 net mask) in /tmp/rules.debug
It still works (I think) because actually 10.0.2.1/24 and 10.0.2.0/24 interpreted as a subnet still describes the same set of IP addresses, but it looks odd, as reported by: https://forum.pfsense.org/index.php?topic=90096.msg498474#msg498474
Same issue with IPv6 for OPT1net rules.
This fixes the rule generation to that OPT1net uses the base subnet address in the rule, in the same way that LANnet and WANnet does.
Looking at where this is nested inside various if statements, I do not think this error did too much harm - only to the $mac['descr'] - in this particular code flow $username is not used for important stuff after this point.
Conflicts:
etc/inc/captiveportal.inc
I was testing code and just doing stuff like:
require_once("zeromq.inc");
in Diagnostics->Command Prompt, PHP Execute
That brings an error because underneath that PHP Execute code it has already included auth.inc
I guess zeromq.inc is used quite separately to the rest of the system, and must be OK just having a "require" here. But it seems safer to always use require_once, just in case it gets called in a new way/sequence.
Comments welcome.
This code looked silly the way it was, with the construct:
$var = $var;
unset($var);
Seems it was accidentally changed to this way many years ago by 588a183b0e
IMHO we want to do the conversion to $config['system']['gateway'] here so that later config conversion will then process it as expected.
Note that in a current (2.2) config there is not $config['system']['gateway'] but that is switched over later in upgrade_021_to_022 - which switches back to $config['interfaces']['wan']['gateway'] and then later config conversions do their thing with that.
I guess this will only effect people who upgrade from some really old config (or monowall?)
This routine seems to go looking to see if the passed-in interface is PPP-style. At the end, if it is not PPP-style then it calls pfsense_ngctl_detach.
This foreach loop in its current state will always exit after the first iteration that is not mode "server". But it looks like it should look through all the 'pppoe' entries until it finds the interface or gets to the end.
In theory the code will sometimes miss setting $found = true when it should have. And thus pfsense_ngctl_detach would get called later for a PPP-style interface.
I noticed this while reviewing for code style guide - it is an example where the indenting shows the intention but there are no curlies to implement it.
