| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
/etc/version all around
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\ |
|
| |
| |
| |
| |
| | |
among all widget forms.
Traffic Graphs widget already uses the vanilla name "iform". Reusing that name causes Traffic Graphs widget graph display state (show/hide) not to be saved if GW widget was also displayed on the dashboard.
This fixes it.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This change adds a setting for the Gateways dashboard widget so the user
can choose to display the Gateway IP, Monitor IP or both.
If "both" is chosen and the Gateway IP is the Monitor IP, then only the
Gateway IP is shown - i.e. the same IP address is not repeated on the
widget display.
If "both" is chosen and the Monitor IP is different to the Gateway IP
then the Monitor IP is shown in () brackets after the Gateway IP.
If "Monitor IP" is chosen and there is no special Monitor IP defined,
then the Gateway IP is displayed (which is also the Monitor IP).
If "Gateway IP" is chosen then the widget behaves as it does now.
"Gateway IP" is the default.
I find this handy because the Gateways widget reports RTT (latency) and
loss figures that are actually for pings to the Monitor IP. So it seems
useful to be able to display the Monitor IP in the widget.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The log and picture widgets were both using "iforma" and "submita".
Actually it did not break anything because it was only the form name
repeated, not id. And nothing was using these names.
Traffic Graphs widget was using just "iform". That is a bit dangerous
for the future. I got tricked when cut-pasting some code to make some
settings options for the Gateways widget. I kept "iform" and then
wondered for a while why my Traffic Graphs widget show-hide settings
would not save. There was traffic graph JS that referred to just "iform"
and that started modifying the "iform" in my new Gateways widget code.
Rather than having names "iforma", "iformb"... "submita", "submitb"...
it seems much less risk of accidental duplication if these are named
like:
name_of_widget_iform
name_of_widget_submit
I don't think there is any user-visible bug in 2.2.* - so this
standardization could just go into 2.3
|
|
|
|
|
|
| |
String replacement:
s/Ermal L.../Ermal Luçi/g
|
| |
|
| |
|
|
|
|
|
|
| |
Note that advertise is spelt with an "s" in other places in the GUI, so
making it consistent in services_ntpd - but maybe Americans do spell it
"advertize" these days?
|
|
|
|
|
| |
Many thanks to Gertjan in forum https://forum.pfsense.org/index.php?topic=87504.msg484017#msg484017
Specifically setting the output encoding to latin-1 was causing the "black diamonds" for special characters in the http://blog.pfsense.org RSS feed (e.g. the registered trademark sign after pfSense did not come out).
It should all work by letting simplepie do its default stuff with the RSS feed.
|
|
|
|
| |
changes and upgrade code
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
and module names and other bits of formatting and typos in header
comment sections.
|
| |
|
|
|
|
|
| |
as mentioned in https://forum.pfsense.org/index.php?topic=84527.msg471919#msg471919
This change makes it work like similar if tests in /usr/local/wwwvpn_ipsec.php, and code in /etc/inc/vpn.inc that effectively defaults to ikev1 when iketype is not specified.
This should make the code here be executed and make $ikeid get the correct value to be used in later code.
|
|
|
|
|
|
|
|
| |
There was not even code to attempt to display the description.
Also, when I first created a phase1 and there were no phase2 yet, the widget spat out the warning for the line:
foreach ($config['ipsec']['phase2'] as $ph2ent){ ...
So I enclosed that in a block:
if (isset($config['ipsec']['phase2'])) { ... }
Tabbing that block in makes the diff look big when there really is little change - a diff ignoring spacing will look much nicer!
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| | |
If the interface had an IPv6 address but no IPv4 address, there was a blank line where the IPv4 address would have been. There is no need for that, and one day IPv4 will be old legacy and systems will routinely have no IPv4 addresses at all - they will all be IPv6. Might as well make that look ordinary on the display now.
The br goes in the div so we can put it in and out from the AJAX also.
|
| |
| |
| | |
All div for the various things need to be created here, so that later AJAX can switch the necessary things on/off and write a new IPv4 or IPv6 address into the div when an interface acquires an address.
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
the same way for the initial display and for updated rows done by Java Script. Now we receive the source IP and port, destination IP and port, all in separate fields so they can be put together in whatever combination for display.
IPv6 displayed addresses are shown inside "[ ]" so that any following port has the standard syntax like "[a:b::c:d]:123" - this makes it obvious that the last numbers are a port number, and not part of the IPv6 address.
The "title" has IP+Port - that is displayed when hovering over the box in general.
The href to diag_dns.php has hover text "Reverse Resolve with DNS" and the "?host=" sends just the IP address (without IPv6 square brackets).
The text displayed in the link is the IP address (with square brackets if an IPv6 address).
For the destination column, if there is a destinaion port, it is displayed in ordinary text ":port" after the IP address.
The blank not-displayed row at the end of the table is removed - this fixes the problem with counting the rows of the table where rows would disappear at each update.
|
|/ |
|
|
|
|
|
|
|
|
| |
Add CDATA sections to scripts
Add ALT to image tags and close image tags
DIV tag cannot be inside a STRONG tag, so swap them around
SCRIPT cannot be part of TR tag, so place the SCRIPT inside a TD tag but
hide it.
|
|
|
|
|
| |
The Gateways Widget Status was not using the listr class, and so it was missing the borders for the right and bottom of its box.
Use the listr class.
Then use javascript to explicitly set the background-color to match the status, overriding the white that is specified in listr.
|
|
|
| |
Redmine #4077
|
|
|
| |
Similar code here. Shame it was not in a subroutine called from both places, but not about to re-engineer that now:)
|
| |
|
| |
|
|
|
|
| |
to the management page.
|
|
|
|
| |
order parameter trough htmlspecialchars()
|
| |
|
|\ |
|
| |
| |
| |
| |
| | |
This counter got lost in commit https://github.com/pfsense/pfsense/commit/ee965a5c7bf37b852795e1201688e3b20bf3d8d1
But the code at line 174 was still using it to offset the start time of each shown graph by 2 seconds, which I guess helps the graph data collection requests back to the pfSense to be staggered, not all having to be serviced at almost exactly the same time.
I noticed this while having a quick look at all the traffic graph widget code to see if there was an obvious place where the 2x bandwidth graphing problem happens. The "* 2" here in line 174 has nothing to do with that!
|
| |
| |
| |
| | |
and pfSense_ipfw_getTablestats(). Also fix fieldnames for captiveportal_hostnames. It should fix #4001
|
| |
| |
| |
| | |
Ticket #3955
|
| | |
|
| |
| |
| |
| | |
the ipsec status page. Ticket #3955
|
|/ |
|
|
|
|
| |
Old code was inaccurate and also listed entries that were symlinks to other disks
|