https://forum.pfsense.org/index.php?topic=91168.msg505273#msg505273
$config['voucher'][$cpzone]['msgnoaccess']
and
$config['voucher'][$cpzone]['msgexpired']
do not exist.
These should be
$config['voucher'][$cpzone]['descrmsgnoaccess']
and
$config['voucher'][$cpzone]['descrmsgexpired']
The other tabs of Status:RRD Graphs put the friendly description of each interface into the drop-down list for selection.
This change makes the Custom tab do that also.
when forwarding mode is on.
The General Setup setting "Allow DNS server list to be overridden by DHCP/PPP on WAN" has always been used in dnsmasq to ADD DHCP/PPP provided DNS servers to the list, while also keeping the DNS servers specified in General Setup. That behavior is needed if:
1) WAN1 static IP with upstream DNS server/s specified in General Setup and selecting the WAN1 gateway. WAN2 uses DHCP, DNS server received by DHCP from upstream. The user needs to tick "Allow DNS server list to be overridden by DHCP/PPP on WAN" to get the WAN2 DNS server to be used, but also wants the DNS server from General Setup to also be used.
2) WAN1 static IP, DNS server/s specified in General Setup. For whatever reason the user has also ticked "Allow DNS server list to be overridden by DHCP/PPP on WAN". In actual fact there are no WAN-style interfaces set to DHCP, so "allowing to be overridden" should not come into effect anyway - the DNS servers in General Setup should be used.
3) WAN1 DHCP, but the upstream DHCP does not give out any DNS server/s. "Allow DNS server list to be overridden by DHCP/PPP on WAN" is ticked. Again there are no DNS servers received via DHCP, so any "override" should not be invoked.
In all cases, it turns out that actually we want any General Setup DNS servers to be included in the DNS forwarder/resolver conf in addition to whatever (if any) DNS servers happen to be provided from a DHPC-WAN.
This change makes unbound behave that way - the same as dnsmasq already does.
I was on a test system and had an upstream DNS server IP specified in System-General Setup. WAN was setup with a static IP and a gateway to that upstream device. All good.
Then I also checked "Allow DNS server list to be overridden by DHCP/PPP on WAN" and changed WAN to be DHCP. It received by DHCP the same DNS server IP that already happened to be in General Setup (and the same gateway IP - not the issue here).
/var/etc/resolv.conf had the name server line twice with the same IP address - once from the DHCP acquired data, and once from the General Setup data.
I don't think it broke anything, but it does look odd.
This change makes sure that DNS servers from General Setup are only added to resolv.conf when they are not already there.
Note: We can let the code pass "never" (or any other unexpected stuff)
to adjust_gmt()
adjust_gmt() should anyway handle the case when strtotime() cannot
understand the input string and thus returns false. In that case we
return the input string as-is so it will be displayed as the time. That
way the user will see it and can report easily whatever other unexpected
char data was in the leases file.
It also prevents "false" (zero) being converted to the date-time string
and thus becoming the Unix epoch 1 Jan 1970 on the display.
Latest forum report of this kind of thing:
https://forum.pfsense.org/index.php?topic=90083.0
It is not necessary to check, as the only times a gateway event should trigger the VPN to restart are when the current and new devices differ.
This also allows us to simplify the code a bit and eliminate some single-use variables.
See the discussion at 4aefcf9151
If the interface is the same, this test will fail, and that's the one case that should not need a resync.
The logic in this test has been flipped and reversed a few times over the years and without comments it's difficult to discern its true purpose.
Forum: https://forum.pfsense.org/index.php?topic=91075.0
For DNS Forwarder (dnsmasq)
1) dnsmasq is the name of the service
2) DNS Forwarder is the text description
Make Unbound consistent with that, so that menu names and services status display and... work in the same way:
1) unbound is the name of the service
2) DNS Resolver is the text description
This code just looked wrong. It was considering 10.1-RELEASE-p6 to be release number "1" and comparing it to "9".
These changes to do what it seems to intend. This will make that UFS+J stuff appear, if that is of any consequence.
1) Only attempt to delete the oldusername if it actually was non-empty - at the moment errors are logged in the system log when adding a new user, because the code was trying to delete the user name "".
2) Call local_user_set() first to create (change, whatever) the user record. This makes the user record exist for a new user. Then call local_user_set_groups() to sort out what groups the user should be in or not in. The existing code would fail to add a new user to the specified group/s because local_user_set_groups() was called too early, before the user actually existed.
Typical system log errors from the old code:
Mar 18 17:10:31 php-fpm[9542]: /system_usermanager.php: Tried to remove user but got user pw instead. Bailing.
Mar 18 17:10:31 php-fpm[9542]: /system_usermanager.php: The command '/usr/sbin/pw groupmod admins -g 1999 -M '0,2003,2006,2008' 2>&1' returned exit code '67', the output was 'pw: user `2008' does not exist'
From looking at the code history, I think this has been this way for a long time, not a new bug at all.
Discussed in forum: https://forum.pfsense.org/index.php?topic=90700.msg501766#msg501766
At the moment you can make a VLAN with tag 0. The input validation does not catch it because when $_POST['tag'] = "0" that evaluates to false by PHP.
Always make the checks on 'tag' value whenever the 'tag' key is set at all. If the (required) 'tag' key is not set, then that is already checked for by do_input_validation().
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.
This just looks wrong. But I guess the code path never comes through here because function readline() already exists in the environment of this script.
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
