The origin of the link-local allow rule for DHCPv6 traffic is a bit weird and
the rule itself is probably dysfunctional, see pfsense/pfsense@dbcddabcdf
It has never been edited again and remains the same in OPNsense and pfSense
today. Typically server client traffic exchanges exclusively over port 546 and
547 so the original one may have been a typo.
Now as witnessed by #7527 the server port could be random, but should
always come from link-local so we can merge both rules into one without
causing much problems. Works fine locally on my network too.
While here make it possible to go back to the original MAC address by
providing the "hwaddr" field of ifconfig back to link command.
This operates under the constraint that the interface where the MAC
address changes is the same as the interface where IPv6 is running
so that we do not perform useless or problematic configuration.
The case for VLANs and parent MACs is probably also quite tricky, but
since it has never been considered before do not start now.
This commit should improve responsiveness of the sessions screen, since we needed to parse the full data in the previous version as well before returning it, this shouldn't be much slower on initial load.
Only risk is the size of the generated json output, by moving the label parsing we replicate less data and reduce total size.
* update the recordset passed in $filter_funct, similar to what the model search supports
* optional $search_clauses to overwrite post `searchPhrase` in cases we want to filter these from the controller.
While SSE promises to be properly multiplexed over HTTP/2, it seems browsers
still hit a hard limit when opening >6 connections. Since the streams are not
critical, it's fine to abstract the eventsource logic to the base widget class
where it manages open/closing connections based on tab visiblity.
If we need more than 6 parallel streams, we need to revamp the logic
to multiplex multiple event types in the backend ourselves, but this is not
necessary for now.
We have to revoke being able to set "random" here for now, but
it's not a huge issue since the fallback is now in the daemon.
The daemon also supports the full unsigned long long range but
does not allow hex input which means we are stuck with losing the
highest bit for now if we store in integer in PHP.
We could store a string, but then cannot verify it and it would
not be a hex value. Meh.
basically this just offers the option to remove the SourceFile reference and keep the configd action, the call overhead of using configd is quite low anyway and #7515 implements generic caching (which was the intend of the file handle)
Add a generic time based cache option for configd sscript action events, example usage:
[action]
command:/path/to/my/command
type:script_output
cache_ttl=5
cache_ttl is specified in seconds after last started execution.
For some reason it convinces me further that we should fix the
ifid default case with a fallback in dhcp6c because users will
not necessarily make that connection and just raise a bug report.
This commit improves alias save/validate performance by fixing two main issues:
1) Faster unique constraint handling using caching, in order to prevent nested loops we should cache our results while still in the validation cycle.
This required an attribute to count validation cycles so we know the model could not have changed in between, getValidationSequence() helps to reach that goal
2) Alias::getByName() more optimistic caching, also prevening nested loops when locating aliases.
Although this is slighly more optimistic than the previous construction, in practice when validating data the set won't change, if there is a risk of mutations, we should flush the set using the "flush" parameter (same as before, but a bit more sensitive).
Let the user decide on the password and use root as the default,
but then also allow these to be seen on the GUI and stop flapping
options when a header can do the same job now.