some people seem to miss the numbers, since the top host graph uses the same information over time, it wouldn't hurt to add a tab containting the raw numbers for the selected interfaces.
The current version doesn't limit the number of results, we might need to add a limit at some point in time, depending on how many results iftop samples.
general remarks:
o total amount of traffic is not being displayed, although we could count the "cumulative" from iftop, the numbers would always be flawed (since sampled with an interval)
o no reverse lookups, maybe for a future version, let's first see if this helps.
o hosts not seen for 120 seconds will automatically be removed from the list (fixed ttl)
when an interface offers multiple addresses, we should at least try to bind to the address which can access the gateway, for example an interface with the following addresses configured:
10.0.1.1/24
10.0.2.1/24
10.0.3.1/24
and a gateway configured on 10.0.2.100 should try to bind on 10.0.2.1. when we can't find a candidate, fall back to the first. closes https://github.com/opnsense/core/pull/4221
o cache user id's so we don't have to traverse the config again
o limit the number of (string) type casts, since on larger quantities they really do cost time...
closes https://github.com/opnsense/core/issues/4508
* DHCPv6: Fix sorting of IPv6 static mappings
The ipcmp() function doesn't seem to return a correct result for IPv6 addresses. That's why the DHCPv6 static mappings are shown in the order they were added. This commit introduces ip6cmp() function and fixes sorting of IPv6 static mappings.
* DHCPv6: Fix sorting of IPv6 static mappings
Move ip6cmp() approach to ipcmp(), use single function for both IPv4 and IPv6.
* DHCPv6: Fix sorting of IPv6 static mappings
Oops, fixed a typo in ipcmp()
o feedback matched policy so we can easily find affective choice in the rule tab
o remove installed_action, installed_status since these values aren't valid anymore
o while here, set <pre/> tag width to a maximum to avoid overflow in alert page
Since values need to be persisted in order to return on query requests, single rule edits can lead to a bit odd behaviour (not toggling until after apply), since modifications are advised to be performed using policies, we will keep this for now.
(the alternative is to hook apply after these changes, which also isn't a great solution)
* IPsec: cleanup phase2 parsing and implement per reqid spd policies. for https://github.com/opnsense/core/issues/4460
* IPsec: persist reqid and (try to) maintain previous choices for route-based IPsec while doing so.
In order for this to work we need a legacy config migration, which we stick to the IPsec model used to store key-pairs. (trigger via /usr/local/opnsense/mvc/script/run_migrations.php)
The phase2 edit should (try to) assure new and modified entries are being equipt with a reqid, in order to use them in the policy mappings and interface generation (route-based).
Ideally we should add this feature when a new kernel arrives since changing reqid's on existing connections and setkey policies will likely have side-affects.
------
Sponsored by m.a.x. it
When investigating log files it's often practical to see the context of a message after searching for it. This feature offers the ability to go to the page in question by clicking on a filtered result.
