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.
When enabling or disabling a route by using the enable/disable button on the Routes page, the destination network was not being put in the config change description, although the code intended it to be there.
This fixes it.
The Traffic Graphs widget puts a graph object for every interface into
the HTML of the widget. Underneath the graph object for every interface
makes the call to graph.php to get data for the graph, and the refresh
interval also keeps happening, which keeps gathering the data every
refresh interval for every interface.
This wastes a lot of CPU back on the pfSense box gathering data
repeatedly if the system has a lot of interfaces and only has the
Traffic Graph enabled for 1 or a few of them. e.g. on my poor little
Alix at home I had setup 6 VLANs to test some stuff, so I had WAN, LAN,
OPT1 and 6 tagged VLANS - 9 interfaces. When I enable the Traffic Graphs
widget on the dashboard, the Alix CPU is driven 100% trying to keep up
with gathering data for 9 interfaces every 10 seconds, even though I
only have 1 graph actually opened!
I couldn't see a way to enable/disable the graph.php object from
executing. So this change puts the object in and out of the HTML:
a) At first display the graph.php object HTML is only put in the
relevant "div" if the graph is actually set to be shown in the config.
b) When a graph is opened by the user, the Java Script puts the
necessary graph.php object HTML into the div. The graph data then starts
being requested...
c) When a graph is minimised by the user, the Java Script removes the
graph.php object HTML from the div. The actions of graph.php stop
happening.
I can see the difference by just watching "top" from the command line on
a low-power system and open/minimizing the graphs on the dashboard.
If there is a better way to enable/disable an object like this I am
happy to learn about it.
when the page is first displayed.
This has annoyed me a few times and it annoyed me again just now. I had some settings in one of the advanced boxes that were no longer wanted, but when the services_dhcp page is shown the contents of advanced settings are not shown to the user - the user has to click on each advanced button to see if there are any settings already there.
This change displays the settings automatically, if there is something already specified. It works the same way as the Firewall Rules advanced boxes.
