| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
| |
functions
|
| | |
|
| |
|
|
| |
The code at line 759 emitted a warning because of the bare '%' in the string.
Other changes are to clarify and tidy up some other sprintf strings.
|
| | |
|
| | |
|
| |
|
|
| |
Fix several sprintf errors by escaping '%'s and removing '[ ]' which had been use to pass arguments to setHelp as an array.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
// Validate a network address
// $addr: the address to validate
// $type: IPV4|IPV6|IPV4V6
// $label: the label used by the GUI to display this value. Required to compose an error message
// $err_msg: pointer to the callers error message array so that error messages can be added to it here
// $alias: are aliases permitted for this address?
function validateipaddr(&$addr, $type, $label, &$err_msg, $alias=false)
This is indented to provide a single method of validating IP addresses of all types and composing a suitable error message
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
without disabling gateway monitoring.
This allows the user to continue to monitor the gateway with dpinger, so
they can see how it is performing, but for the system not to take any
real action if the latency/loss exceeds the given limits.
A typical use case for this would be on a single-WAN system. There is no
failover option, so there is no point taking any real action when the
latency/loss is high. Having stuff try to failover (and stop/start
stuff...) is just disruptive.
In ths case the use could have disabled monitoring completely, but then
they get no feedback abut gateway performance.
|
| |
|
|
| |
default then remove the corresponding default route to respect the user's decision. Fixes #6659
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Use case:
1) Edit a gateway that has no advanced settings (i.e. the Advanced section does not need to open on page load) - that works fine.
2) Modify the Gateway IP Address to something invalid like 1:2::z
3) Press Save
The error is shown - "A valid gateway IP address must be specified" - good.
The Advanced section is shown - not good.
The problem is that after POSTing the page, and the resulting validation, finding an input error, and re-displaying the page, each of the $pconfig keys is set, even though set to the empty string "". So the isset() tests are true, and it gets the wrong idea.
We only care about these parameters if they are not "". In this case !empty() gives the correct result, because although a value of 0 will be considered empty, 0 is not allowed by the front-end of the UI anyway (as it happens, these parameters are not allowed to be 0), so we never get that case. And by the way, I generally hate empty() because of having to think of all its quirks.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The usage of require() and require_once() throughout the system is
inconsistent, and "bugs" come up now and then when the order of
"requires" is a bit different and some require() happens after the
include file is already included/required.
It seems to me that there is no harm at all in always using
require_once().
|
| | |
|
| | |
|
| |
|
|
| |
Remove "you" personalizations.
|
| |
|
|
|
|
| |
As per what was done for https://github.com/pfsense/pfsense/pull/2765 -
do it to the rest of them.
Seems to work OK.
|
| | |
|
| |
|
|
|
| |
This reverts commit a32bed49516f3df3d104a5026a5b2c74451f348f, reversing
changes made to 9ec9978267a5d1985d6da8ba35d52b7174239d2f.
|
| |\ |
|
| | | |
|
| | |
| |
| |
| | |
Tidy up missing semi-colon in non-breaking space
|
| |\ \ |
|
| | |/
| |
| |
| |
| |
| | |
The text of a Form_Button is not translated internally. Some Form_Button
calls already had the button text enclosed in gettext(), this does it
for the remaining ones.
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
creating too long of a route-to line. Related to pull request 1614
|
| |
|
|
|
| |
Add a new advanced option on gateways to allow user define data
payload. Default is 0
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
was the reason they were added, it was never finished and it's not being used
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This does what I can think of so far:
1) Make sure low latency < high latency, low loss < high loss
2) Loss interval must be at least latencyhigh otherwise every packet that was high latency would be counted as lost before it came back. (see note below)
3) averaging time period must be at least 2 times probe interval - it is not much of an "average" if it averages less than 2 probes :)
4) alert interval must be at least probe interval - there is no point recalculating the average latency and loss more often than once every probe interval.
5) Criteria for showing or hiding the advanced options on page load fixed up to account for all the fields now in the advanced section.
6) Additional information - I have written some stuff that I think is now helpful.
Note: Currently the default loss interval is 500 and latencyhigh is also 500. This makes no sense to me. If a probe comes back in > 500ms then the thread that is waiting for the reply will have given up (loss interval has expired). So any packets with an RTT > 500ms will be considered lost. Therefore there will be no packets recorded with an RTT > 500ms. Therefore the average latency can never exceed latencyhigh.
It seems to me that "loss interval" needs to be reasonably higher than "latencyhigh" in any sensible configuration.
Thoughts?
|
| |\ |
|
| | | |
|
| |/
|
|
| |
The packet loss thresholds must still be in % ? milliseconds does not look valid.
Other things are minor formatting.
|
| | |
|
| | |
|
