@jimp Ok, is that possible to implement multitabs Dashboard conception in pfSense theme?

@jimp Legend, thanks heaps ! Exactly what i was after, the first one.

With the new snapshots this issues has gone away.

@jimp said in PHP errors with 2.7.0-DEVELOPMENT-amd64-20220512-1201 snapshot: So it probably didn't actually restore the lease data then. We'll look into it https://redmine.pfsense.org/issues/13157 Thanks, I am available to reinstall and test, when the fix reaches a snapshot.

@louis2 Cool, thanks!

Oh, I think it's because I'm testing a private snapshot and this has already been fixed: https://redmine.pfsense.org/issues/13126

Redmine issue created: https://redmine.pfsense.org/issues/13132

@jimp Thank you.

Looks like that's from a recent change for https://redmine.pfsense.org/issues/4259. I've added a note there.

@jimp said in Non exposed openvpn dhcp-option NBDD option: Fixing the GUI option seems better at the moment, since it's partway to working. There may be someone out there who still needs it and OpenVPN itself hasn't deprecated it yet. Please look at this PR https://redmine.pfsense.org/issues/13085?next_issue_id=13084 I am just not comfortable with pfsense using !(empty() for testing text/numeric form fields. This causes the value of 0 to be actually saved in settings, but it will not be exposed in GUI for example under NTP and WINS servers I implemented the proper way for php to validate this type of checks and added it to the CSC page only. But the problem is probably across all GUI pages. Using empty() is probably safe under most circumstances, but it is not very clean in the way it is implemented. I posted a gist with the php samples: https://gist.github.com/PhilZ-cwm6/4676368b77fc01d478f42b5c94f26a66

@notyouritmanager Also got this crash report after reboot: Crash report begins. Anonymous machine information: amd64 12.3-STABLE FreeBSD 12.3-STABLE devel-12-n227340-ba430b15563 pfSense Crash report details: PHP Errors: [14-Apr-2022 10:21:14 America/New_York] PHP Fatal error: Uncaught Error: Call to undefined function restart_packages() in /usr/local/www/interfaces.php:506 Stack trace: #0 {main} thrown in /usr/local/www/interfaces.php on line 506 No FreeBSD crash data found.

@gertjan I agree that IPv6 support in OSes has been solid for a long time. However, what has not been solid is prefix delegation and router announcement. My ISP uses Alcatel/Nokia and Juniper equipment and requires the use of "Do not wait for a RA". I was one of the early testers of this switch. This has been broken numerous times over the years, which is why I keep an eye on IPv6.

@tquade Yea, I had put a head on the system to figure out what was going on. But once I looked at it it was an easy fix.

Hi, I'm on 2.7.0 Dev, and run into this issue with haproxy. Upgraded from 2.6.0 to 2.7.0 Dev. [image: 1648394448092-f738ad9d-5c4f-4ee9-b86b-6b5527fe2419-image.png]

@netblues said in The last Snapshot for which VLANs are working is pfSense-CE-memstick-2.7.0-DEVELOPMENT-amd64-20220314-1916: I'm not saying that testing is not needed. On the contrary. What I'm saying is that the dev team definitely has its own mechanisms to test. Having said that, reading about an issue in a public forum is one thing, responding to it is another. Especially when something is hard to replicate, or is a corner situation. Since you (and I) most probably didn't sign up to a tester's program I hardly expect anyone to respond to our findings unless there is a reason to. And that's at his own discretion. I was guiding by Open Source principles here: https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution Anyone can contribute, you don't have to be on the "Schindler's list" or something. In order to raise an issue, you first discuss about it, have feedback about it, decide if it's a defect or not, otherwise you risk opening a Redmine issue that will be pushed back forever. And most importantly abide by community ways of working. So I can understand if in this stage, help from general audience is not needed.

I'm running 2.7.0-DEVELOPMENT (amd64) built on Fri Mar 11 06:21:33 UTC 2022 and it will not update. I tried restarting unbound, but it made no difference. Any suggestions? UPDATE: I tried to update from the console and this time it worked.

This has been merged and will be in snapshots soon. For those who would like to try it out, even on 22.01/2.6.0, install the System Patches package and then create entries for 961f240c18f8421b0a28ee192ffa041e754e8f8e and then 8ddf2b5a999772754080825f07acf9b6326f1f04 to apply the fix. Apply 961f240c18f8421b0a28ee192ffa041e754e8f8e first followed by 8ddf2b5a999772754080825f07acf9b6326f1f04

Anyone having the same issue? It looks like it's not only isolated to CF. I tried adding a custom DDNS client and it's all over the place, really.