This contains roughly the same configuration items as our current isc-dhcp6 alternative, with the exception of not trying to implement dynamic ranges based on data received from dhclient6.
In terms of target audience, dynamic environments (receiving their "wan" type addressess via dhcp), should logically use dnsmasq for client configuration. Large (enterprise) setups usually are static by nature and may require prefix deligation to routers behind the primary one. In these cases Kea will be the tool of choice.
Both v4 and v6 share the same rc scripts underneath, which means reconfiguration happens per package (eventhough two services are registered).
Existing hooks for v4 have been extended with v6 data (firewall rules and staticmaps).
Advanced configurations can still opt out of config file generation and supply their own json config, same as implemented for v4.
The lease view still needs to be implemented, but that's likely a minor addition.
The level key words are easy to find in the source code, but knowing
which verbose description they belong to is difficult without pulling
up our source code as well. Make it explicit.
This prevents validation errors when interfaces are temporarily
disabled. Other device components received similar fixes in the
past due to this "glitch" of not offering valid devices and selectpickers
would lose their correct value on save too (the field is a bit different
here but the same principle applies).
When attaching a GIF tunnel to an IPv6 device it's more likely a LAN
device but that is being missed when WAN is reloaded here. Much of the
other code still accounts for this so this merely goes with the flow
and since we only operate in IPv6 scope that is ok.
* dhcp6: key lease map by type in addition to duid
* Update src/opnsense/scripts/dhcp/get_leases6.py
Co-authored-by: Ad Schellevis <AdSchellevis@users.noreply.github.com>
---------
Co-authored-by: Ad Schellevis <AdSchellevis@users.noreply.github.com>
In the old situation, one would need explicit pf rules on top of
this feature to make this work. With the removal of IPFW,
those rules are now enough to make the same happen.
Usually log lines start with a line ending, which means the first hit is always an empty line with reading things backwards.
This empty line has no relevance, but only indicates we're at the end of the file.
This commits stores the file starting position in all cases and ignores the output when we trying to yield the end of the file.
* Interfaces: Devices: Bridge - refactor to MVC for https://github.com/opnsense/core/issues/8353
* move existing properties to model which overlays existing config path
* add a simple wrapper script for [re]configuration which diffs and applies using the new _interfaces_bridge_configure() implementation
* Update src/opnsense/mvc/app/models/OPNsense/Interfaces/Bridge.xml
Co-authored-by: Franco Fichtner <franco@opnsense.org>
---------
Co-authored-by: Franco Fichtner <franco@opnsense.org>
In order to plan->do->act we need the current settings of the existing bridge, which is where legacy_interfaces_details() comes into play, which needs some additional parsing.
Next we can diff per type of setting and apply when changed.
