| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) A disabled gateway can always be enabled - no extra validation
needed.
2) When disabling an enabled gateway, check to see that the gateway is
not used in any gateway group or enabled static route (similar tests to
what is already checked before deleting a gateway).
3) A static route can always be disabled - no extra checks needed.
4) When enabling a static route, check that the selected gateway is
enabled - you cannot have a static route enabled on a disabled gateway.
5) Do the address family cross-check between static route and gateway
even when the static route is disabled - we do not want to save
mismatched IP address families in any case.
This covers all the cases I can see to ensure that the enable/disable
status combinations of Gateways and Static Routes is always valid.
|
|
|
|
|
|
|
| |
and other random stuff I noticed.
I think this finishes messing with code style. The codebase should match
the developer style guide closely enough that 99.9% of changes will not
feel the need to also massage the formatting.
|
| |
|
|
|
|
| |
statuses that are not up. Ticket #4502
|
|
|
|
|
|
|
|
| |
In gwlb.inc at line 676 and 779 I added an extra set of brackets. In the
"if" clause as a whole there were a mix of && and || used that were
relying on the PHP standard that && has precedence over ||
In actual fact the original code should have been working fine, the
extra brackets make sure that the intention is clear.
|
| |
|
| |
|
| |
|
|
|
|
| |
changes and upgrade code
|
|
|
|
|
|
|
| |
When a dynamic gateway is disabled (by the user through the webGUI), it was still being returned by return_gateways_array(). But when called like that, disabled gateways should not be returned. The first part of the routine was correctly skipping disabled gateways, but then the later part would effectively re-generate those dynamic gateways on-the-fly and not realise they should be skipped because they were disabled.
This code now remembers gateway details of all the gateways, including skipped ones, so the dynamic gateway code can easily realise all gateways that have been already processed, even those that were processed and skipped.
Forum: https://forum.pfsense.org/index.php?topic=86565.0
It fixes Gateway Status Widget - now if a dynamic gateway is disabled, it does not appear on the display.
This will also stop disabled dynamic gateways from being returned to other callers. So there may/will be impacts on other parts of the system when a user disables a dynamic gateway. e.g. filter.inc - a gateway that has been disabled by a user canot be used in rules any more.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When an interface is waiting to get DHCP, but the cable is physically-electrically connected to the upstream device, the interface has an IPv4 address 0.0.0.0 - that was getting past here and, if the interface gateway had a monitor IP specified, that monitor IP was being put into apinger.conf and being monitored. Because the interface has not got a gateway yet, no static route is added to force the traffic for the monitor IP out the particular interface. So the traffic to the monitor IP can follow the default route and perhaps succeed in getting out another WAN to the monitor IP.
The downstream results of this were:
1) Gateway status appears up and reports real RTT and Loss statistics, even though the interface is down.
2) Generation of rules for a gateway group that has this gateway as tier1 will think it is up, and thus try to policy-route traffic to it - which then does not get anywhere.
3) DynDNS status of a gateway group that has this gateway as tier1 shows the cached IP in red - it thinks the interface/gateway is up and tries to find the public IP by trying to get to checkip.dyndns.com through the interface/gateway. That of course fails.
4) I'm sure there are other things that depend on checking gateway and gateway group status that would also be getting it wrong in this condition, because apinger is being told to monitor, and manages to successfully monitor, an interface/gateway that has not yet got DHCP.
When waiting for DHCP, ifconfig shows like this on my system (WAN is on a cable to a VLAN switch):
vr0_vlan70: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:0d:b9:24:59:c0
inet6 fe80::20d:b9ff:fe24:59c0%vr0_vlan70 prefixlen 64 scopeid 0xf
inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
vlan: 70 vlanpcp: 0 parent interface: vr0
From what I can see, this little 2-line fix ends up correcting all the downstream effects I listed above.
Should fix RedMine #4094
|
|/
|
|
|
| |
and module names and other bits of formatting and typos in header
comment sections.
|
|
|
|
| |
https://forum.pfsense.org/index.php?topic=84451.0
|
|
|
|
| |
than one pppoe has the same gateway. Also kill states when reloading apinger to catch up with new route
|
|
|
|
| |
and change permissions on these paths
|
|
|
|
|
|
| |
Stops error:
ERROR: opening '/var/db/rrd/WAN_DHCP-quality.rrd': No such file or directory
in system log during boot.
Forum: https://forum.pfsense.org/index.php?topic=84627.0
|
|
|
|
| |
that doing the right checks
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
necessarily correct, there are many circumstances where this runs where it wasn't there to begin with, and is potentially misleading.
|
|
|
|
| |
with roubleshooting issues
|
| |
|
| |
|
|
|
|
| |
wrong source IP when a monitor gateway has been set.
|
|
|
|
| |
being a dynamically assigned PPoE interface.
|
|\
| |
| | |
Fix gateway quality RRD to have the correct granularity and be consistent with the pfSense graphs set.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
with the pfSense graphs set.
Create gateway quality RRD with settings suitable for pfSense graph set, since apinger uses default step (300) and other settings that are not so good/consistent with the pfSense graphs set.
Originally Submitted as Pull Request #672.
Resubmitting to Master.
|
|\ \
| | |
| | | |
Return GWG IP protocol (version) when no gateway IP
|
| |/
| |
| | |
This is a resubmit of an older pull request I had closed. It came up again in the forum, with a user setting up a VM environment and wondering why he cannot make policy-routing rules to a gateway group. The gateway group names did not display because all his WANs were down at the time and so the existing code was too dumb to determine the IP protocol (version 4 or 6) when none of the WANs in the gateway group actually have an IP address yet.
|
| |
| |
| |
| | |
IP version, leave it more simple using only 'dynamic'. It helps #3484
|
| | |
|
| | |
|
| |
| |
| |
| | |
same. GRE seems to need the prefixlen 128 specified all the time so do it explicitly to be on safe side
|
|/
|
|
| |
on firewall rules etc. The guide for setting up this tunnels on docs need to change to leave the gif interface as none type. People upgrading need to fix this themselves with a not on release notes. This can be fixed if the kernel condition is relaxed to allow setting the prefixlen on the tunnel as ipv4
|
|
|
|
|
|
|
|
|
| |
Exposes 3 additional apinger configuration options in the gateway monitor advanced section which can either be set manually, calculated based on interval, or use the hard coded defaults.
1) Avg Delay Samples
2) Avg Loss Samples
3) Avg Loss Delay Samples
The current hard coded defaults are okay for a short interval such as the 1 second default. But do not work well when a longer interval is required.
|
| |
|
|
|
|
| |
called with $disabled == false
|
| |
|
|
|
|
| |
interface doesn't exist. Default behavior didn't change. Also check the new gateway parameter (disabled) when filtering
|
| |
|