Displaying 1 50 of 27,598 commits (0.053s)

pfSense — etc/inc system.inc

add missing )
Delta File
+1 -1 etc/inc/system.inc
+1 -1 1 file

pfSense — etc/inc globals.inc

Include net.key.preferred_oldsa in the sysctl list, set to 0 (disable) so
it doesn't fall through to the default (1).
Delta File
+1 -0 etc/inc/globals.inc
+1 -0 1 file

pfSense — etc/inc globals.inc

Include net.key.preferred_oldsa in the sysctl list, set to 0 (disable) so
it doesn't fall through to the default (1).
Delta File
+1 -0 etc/inc/globals.inc
+1 -0 1 file

pfSense — usr/local/www status_rrd_graph.php

Merge pull request #1587 from Gertjanpfsense/master
∈ Phil Davis - 8e2a5adf - 2015-03-23 17:15:57
    RRD Graph Custom Tab display friendly description
    
    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.

pfSense — etc/inc unbound.inc

Merge pull request #1581 from phil-davis/patch-1
∈ Phil Davis - 383dd72d - 2015-03-26 00:51:16
    Always include general setup DNS servers in unbound.conf
    
    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.
Delta File
+6 -6 etc/inc/unbound.inc
+6 -6 1 file

pfSense — etc/inc system.inc

Merge pull request #1586 from phil-davis/patch-6
∈ Phil Davis - 11fd072b - 2015-03-25 18:14:59
    Only list nameservers once in resolv.conf
    
    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.
Delta File
+5 -3 etc/inc/system.inc
+5 -3 1 file

pfSense — usr/local/www status_dhcp_leases.php

Merge pull request #1584 from phil-davis/patch-2
∈ Renato Botelho - 33d40fb0 - 2015-03-26 14:20:09
Merge pull request #1582 from k-paulius/fix-get_possible_traffic_source_addresses
∈ Renato Botelho - a5bc12f0 - 2015-03-26 14:13:46
Merge pull request #1575 from k-paulius/misc-dhcp6c
∈ Phil Davis - 6eb5191b - 2015-03-13 08:33:15
Status DHCP Leases handle expire never

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
Delta File
+16 -6 usr/local/www/status_dhcp_leases.php
+16 -6 1 file

pfSense — etc/inc system.inc

Merge pull request #1559 from phil-davis/status-dhcp-leases
∈ Phil Davis - 4ad1ddf2 - 2015-03-25 18:14:59
    Only list nameservers once in resolv.conf
    
    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.
Delta File
+4 -3 etc/inc/system.inc
+4 -3 1 file

pfSense — usr/local/captiveportal index.php

Voucher messages using wrong config field name

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']
Delta File
+3 -3 usr/local/captiveportal/index.php
+3 -3 1 file

pfSense — etc/inc unbound.inc

    Always include general setup DNS servers in unbound.conf
    
    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.
Delta File
+6 -6 etc/inc/unbound.inc
+6 -6 1 file

pfSense — etc/inc unbound.inc

    Always include general setup DNS servers in unbound.conf
    
    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.
Delta File
+6 -7 etc/inc/unbound.inc
+6 -7 1 file

pfSense — etc/inc system.inc

    Only list nameservers once in resolv.conf
    
    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.
Delta File
+4 -3 etc/inc/system.inc
+4 -3 1 file

pfSense — etc/inc system.inc

    Only list nameservers once in resolv.conf
    
    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.
Delta File
+5 -3 etc/inc/system.inc
+5 -3 1 file

pfSense — usr/local/www diag_dns.php

    Fixes an issue wherein an alias could be added only if some other alias already exists 
in the system.
Delta File
+6 -4 usr/local/www/diag_dns.php
+6 -4 1 file

pfSense — etc rc.openvpn

    Eliminate the "this_device" test from the resync check in rc.openvpn.
    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 
https://github.com/pfsense/pfsense/commit/4aefcf915112b38784b06abc8dd9a26d9a4960b3
Delta File
+4 -9 etc/rc.openvpn
+4 -9 1 file

pfSense — etc rc.openvpn

    Eliminate the "this_device" test from the resync check in rc.openvpn.
    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 
https://github.com/pfsense/pfsense/commit/4aefcf915112b38784b06abc8dd9a26d9a4960b3
Delta File
+4 -8 etc/rc.openvpn
+4 -8 1 file

pfSense — etc rc.openvpn

    The logic of this test seems to be incorrect.
    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.
Delta File
+2 -1 etc/rc.openvpn
+2 -1 1 file

pfSense — etc rc.openvpn

    The logic of this test seems to be incorrect.
    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.
Delta File
+2 -1 etc/rc.openvpn
+2 -1 1 file

pfSense — usr/local/www diag_logs_settings.php diag_ping.php

    Commit 89f171b changed result returned by get_possible_traffic_source_addresses() from 
indexed to associative array. Updating affected code.

pfSense — etc/inc interfaces.inc

    Supress errors when opening custom DHCP config file and check if content was 
successfully retrieved. Prevents PHP from throwing error in case file does not exist.
Delta File
+7 -3 etc/inc/interfaces.inc
+7 -3 1 file

pfSense — etc/inc interfaces.inc

Log to syslog and get rid of useless variable.
Delta File
+2 -3 etc/inc/interfaces.inc
+2 -3 1 file

pfSense — usr/local/www status_rrd_graph.php

    RRD Graph Custom Tab display friendly description
    
    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.

pfSense — usr/local/www status_rrd_graph.php

    RRD Graph Custom Tab display friendly description
    
    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.

pfSense — etc/inc service-utils.inc

Merge pull request #1580 from phil-davis/patch-1
∈ Phil Davis - a3fb1412 - 2015-03-23 14:34:26
    Be consistent about Unbound service descriptive name
    
    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
Delta File
+1 -1 etc/inc/service-utils.inc
+1 -1 1 file

pfSense — etc/inc service-utils.inc

    Be consistent about Unbound service descriptive name
    
    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
Delta File
+1 -1 etc/inc/service-utils.inc
+1 -1 1 file

pfSense — usr/local/www getserviceproviders.php graph.php

Merge pull request #1577 from k-paulius/fix-dhcp6-validation
∈ Renato Botelho - cd94a9a8 - 2015-03-23 13:18:55
Add missing encoding, as suggested by yakar

pfSense — usr/local/www getserviceproviders.php graph.php

Add missing encoding, as suggested by yakar

pfSense — usr/local/www/installer installer.php

Merge pull request #1576 from phil-davis/patch-1
∈ Phil Davis - 8fa074af - 2015-03-21 12:23:23
    Handle release number in installer
    
    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.

pfSense — usr/local/www interfaces.php

    Use is_numericint() instead of empty() to check if value has been entered because 
empty() does not allow 0, which is a valid value.
Delta File
+4 -4 usr/local/www/interfaces.php
+4 -4 1 file

pfSense — usr/local/www interfaces.php

    Make sure 'DHCPv6 Prefix Delegation size' is provided if 'Send IPv6 prefix hint' flag 
is checked to avoid generating invalid dhcp6c configuration file.
Delta File
+3 -0 usr/local/www/interfaces.php
+3 -0 1 file

pfSense — usr/local/www interfaces.php

    Make sure 'DHCPv6 Prefix Delegation size' is provided if 'Send IPv6 prefix hint' flag 
is checked to avoid generating invalid dhcp6c configuration file.
Delta File
+3 -0 usr/local/www/interfaces.php
+3 -0 1 file

pfSense — usr/local/www/installer installer.php

    Handle release number in installer
    
    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.

pfSense — usr/local/www/installer installer.php

    Handle release number in installer
    
    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.

pfSense — etc/inc interfaces.inc, usr/local/www interfaces.php

Merge pull request #1486 from jlduran/patch-1
∈ Chris Buechler - d325e908 - 2015-03-19 04:52:46
    Add option for wireless standard "auto", to omit "mode" entirely from ifconfig. This 
shouldn't be necessary, but specifying mode has proven to trigger driver problems that 
don't exist if it's left unspecified (such as FreeBSD PR 198680). Chosing "auto" fixes 
ath(4) BSS mode issues otherwise preventing it from connecting.

pfSense — etc/inc interfaces.inc

    Supress errors when opening custom DHCP6 config file and check if content was 
successfully retrieved.
    Prevents PHP from throwing error in case file does not exist.
Delta File
+8 -3 etc/inc/interfaces.inc
+8 -3 1 file

pfSense — etc/inc interfaces.inc

    A mix of literal tabs, spaces and \t is used in dhcp6c config file code. Convert 
evertyhing to use \t.
Delta File
+11 -12 etc/inc/interfaces.inc
+11 -12 1 file

pfSense — etc/inc interfaces.inc

    DHCP6 config file override, advanced and basic settings override each other so put 
them in single
    if/else statement rather than always generating all three setting types.
Delta File
+64 -64 etc/inc/interfaces.inc
+64 -64 1 file

pfSense — etc/inc interfaces.inc, usr/local/www interfaces.php

    Add option for wireless standard "auto", to omit "mode" entirely from ifconfig. This 
shouldn't be necessary, but specifying mode has proven to trigger driver problems that 
don't exist if it's left unspecified (such as FreeBSD PR 198680). Chosing "auto" fixes 
ath(4) BSS mode issues otherwise preventing it from connecting.

pfSense — etc/inc interfaces.inc, usr/local/www interfaces.php

    Add option for wireless standard "auto", to omit "mode" entirely from ifconfig. This 
shouldn't be necessary, but specifying mode has proven to trigger driver problems that 
don't exist if it's left unspecified (such as FreeBSD PR 198680). Chosing "auto" fixes 
ath(4) BSS mode issues otherwise preventing it from connecting.

pfSense — usr/local/www/themes/_corporate/styles jquery-ui-1.11.1.css, usr/local/www/themes/code-red/styles jquery-ui-1.11.1.css

change the location of jquery-ui images in each theme's css file

pfSense — usr/local/www/themes/_corporate/styles jquery-ui-1.11.1.css, usr/local/www/themes/code-red/styles jquery-ui-1.11.1.css

change the location of jquery-ui images in each theme's css file

pfSense — etc version

Bump version to 2.2.2-DEVELOPMENT
Delta File
+1 -1 etc/version
+1 -1 1 file

pfSense — usr/local/www interfaces_vlan_edit.php

Merge pull request #1571 from phil-davis/patch-2
∈ Phil Davis - b13f7a8c - 2015-03-16 14:26:00
    Do not allow VLAN tag zero
    
    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().

pfSense — usr/local/www system_usermanager.php

Merge pull request #1569 from phil-davis/patch-1
∈ Phil Davis - 926e0a2f - 2015-03-18 12:03:36
    Cleanup code path when adding a new user
    
    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

pfSense — usr/local/www system_usermanager.php

    Cleanup code path when adding a new user
    
    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

pfSense — usr/local/www interfaces_vlan_edit.php

    Do not allow VLAN tag zero
    
    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().

pfSense — usr/local/sbin pfSsh.php

Merge pull request #1564 from phil-davis/patch-2
∈ Renato Botelho - b78655a9 - 2015-03-16 11:17:03
Merge pull request #1562 from phil-davis/usr-review1
∈ Phil Davis - 06144727 - 2015-03-13 17:25:14
    pfSsh.php readline function return value
    
    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.
Delta File
+1 -1 usr/local/sbin/pfSsh.php
+1 -1 1 file

pfSense — etc/inc filter.inc

Merge pull request #1561 from phil-davis/patch-1
∈ Renato Botelho - bd17a303 - 2015-03-16 11:13:41
Merge pull request #1560 from phil-davis/get_possible_traffic_source_addresses
∈ Phil Davis - 44b9fbdc - 2015-03-14 14:39:25
    Use subnet address in OPT net rules
    
    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.
Delta File
+6 -6 etc/inc/filter.inc
+6 -6 1 file

pfSense — etc/inc filter.inc

    Use subnet address in OPT net rules
    
    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.
Delta File
+11 -9 etc/inc/filter.inc
+11 -9 1 file

pfSense — sbin dhclient-script, tmp post_upgrade_command.php

Code Style sbin tmp usr

Bits and pieces from sbin tmp and usr but not yet usr/local/www