This doesn't invalidate the PPPoEv6 mode, but it does keep the race
between router files for different types. In this case e.g. Telekom
ISP will require the IPv6 from PPPoE to be set in order to be able
to do DHCPv6 for whatever reason.
PR: https://forum.opnsense.org/index.php?topic=31955.0
make tables responsive (by moving .table-responsive to the parent div)
workaround bootstrap "dropdowns inside responsive table" issue
don't let the buttons fall apart
The IPv6 case for PPP interfaces is a little convoluted and needs further
cleanup. For now make sure that we only fiddle with $realif default if
there is need for it instead of changing and reverting back later.
There's a bit too much trickery involving get_ppp_parent() inside
get_real_interface() which internally calls get_real_interface()
again and produces the mismatch we see.
We can safely assume that PPPoE always has a PPPoE device like the
IPv4 case and be done with it.
Turns out the are more exceptions hidden underneath so to be safe we catch all of them.
If we're unable to resolve a hostname for whatever reason, we'd like to continue on anyway.
- Increase the reporting interval for 12 & 24 hours to 10 minutes.
- Always display a list for the top (blocked) domains
- Remove block/whitelist buttons when blocklists are disabled
This include the ability to whitelist it from the same page as well. Relevant to both
the top passed/blocked domains, as well as the detailed query grid.
blocklists.py has been modified in such a way that it will detect whether it needs to
start the download process or simply administrate locally. The latter currently only happens
when custom domains for blocking have been added/removed by a user. The reasoning is
that we can easily extend/shrink the current blocklist when it comes to blocking exact
domains as this is handled on the incoming side. However, while we can modify the current
list to accomodate a new whitelist entry (which can be regex), we (currently) cannot know which domains
were skipped in the process of retrieving them in the first place if a user explicitly removes
a whitelist entry. Therefore we decide to re-run the download on a whitelist action.
furthermore, the updateBlocklistAction in the controller administrates how the model is updated
(e.g. when a blocked item is whitelisted, it should be removed from the blocklist model entry and
added to the whitelist)
In the future we could optimize the whole process by checking if a remote file has changed in
date or size.
