| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
since we can sometimes provide a useful description from that config
data also.
Fill the $iplookup array with host or FQDN data if description is blank
or host or FQDN was requested. Then we can use $iplookup in all cases
where we have local data. It simplifies some logic a bit.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is handy at sites where lots of the LAN clients have static-mapped
DHCP IP addresses. Depending on the site host naming conventions, host
names can be a bit obtuse - may not tell you where the client device
might actually be in the building. We put other useful stuff in the
description - "Jane Doe - Reception".
This enhancement allows the user of Traffic Graph to select
"Description" in the "Display" dropdown. Then, for IP addresses that are
static mapped, the description from the config is shown, rather than the
host name.
When a client device is noticed hogging bandwidth, it is easy to go
straight to "Jane Doe - Reception" and ask why they are doing some huge
download.
Might be useful for for others?
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | | |
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.
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
|\ \ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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
|
|\ \ \ \ \
| |_|/ / /
|/| | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
Fix delete Java Script to match valid HTML ID
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
html id's not permitted to begin with a number.
html id's not permitted to contain '/'
add prefix (entry_) and replace slash with hyphen.
table entry id format becomes: entry_<ip address>-<cidr>
replacing the format: <ip address>/<cidr>
does not change the displayed format.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
works. Ticket #4785
|
| | | | |
| | | | |
| | | | |
| | | | | |
also cert changes. Ticket #4785
|
| | | | |
| | | | |
| | | | |
| | | | | |
rereadsecrets to make sure new secretes are updated. It should fix #4785
|
| | | | |
| | | | |
| | | | |
| | | | | |
be committed after this
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
There was a regression on strongswan between 5.3.0 and 5.3.2 as reported
at [1]. To workaround this issue, add an extra line on ipsec.secrets
with right fqdn.
|
|\ \ \ \ \
| |_|/ / /
|/| | | | |
|
| | | | |
| | | | |
| | | | | |
Fix typo so get_bandwidthtype_scale can do more than default to "1".
|
| | | | |
| | | | |
| | | | |
| | | | | |
boot, but no longer applicable as session data is no longer in /var/tmp/. Credit to 'aa' on opnsense forum.
|
|/ / / /
| | | |
| | | |
| | | |
| | | | |
Conflicts:
etc/inc/vpn.inc
|
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
won't match. Ticket #4781
Conflicts:
etc/inc/vpn.inc
|
| | | |
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | | |
At the confirmation dialog after pressing the "Reinstall XML" button, the text does not distinguish between having pressed "Reinstall the whole package" and "Reinstall the GUI/XML". It would be nice if the text of this confirmation allowed the user to be confident about which button they had just pushed, before confirming the action.
Note: This stuff has no gettext() wrappers - but that can be fixed later, not get mixed up in this.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
and cause rule errors. Fixes #4772
|
| | | |
| | | |
| | | |
| | | |
| | | | |
At the confirmation dialog after pressing the "Reinstall XML" button, the text does not distinguish between having pressed "Reinstall the whole package" and "Reinstall the GUI/XML". It would be nice if the text of this confirmation allowed the user to be confident about which button they had just pushed, before confirming the action.
Note: This stuff has no gettext() wrappers - but that can be fixed later, not get mixed up in this.
|
| | | |
| | | |
| | | |
| | | | |
master branch already.
|
|\ \ \ \
| |/ / /
|/| | | |
|
|/ / /
| | |
| | |
| | |
| | | |
I thought that "reinstallxml" should do less than "reinstallpkg" but actually it was getting stuff here, then falling through "reinstalpkg" which did delete_package_xml and then install_pkg, which got the files a 2nd time and...
Maybe that was supposed to happen?
Anyway, I thought I would point this out and someone can either commit this pull request if the "break" should be there, or explain to me why "reinstallxml" is supposed to fall through executing all this code.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
attributes
|
| | | |
|