Which makes it even more simple, here is how it was changed: https://github.com/pfsense/pfsense/commit/fa5f513658f7f1aba530e76e01dfbc021605c3ad

Yeah, it's already been fixed for 2.3.1.

Most interface names aren't nearly long enough to show that, OpenVPN is an anomaly in that regard. Yeah that's something that won't be changed in the SVG graphs. Their replacement should address that.

Not sure where you would do gui, but a simple look at the /etc/sshd file you will see that they look for /etc/sshd_extra So if you put a banner config in there, and then create your banner file that will be added to the sshd_config [image: sshd_extra.png] [image: sshd_extra.png_thumb] [image: banner.png] [image: banner.png_thumb]

@coachmark2: ….  it tries to resolve against itself. Which hits the unbound service. Which sends requests out all interfaces by default. Which includes the pfSync interface. Which has no DNS servers. :( .... It will also hit your WAN which should have a link to all these 12 (13 ?) root DNS servers …. Normally, from what I understood, you should inform unbound which interface(s) are outbound, and which are 'local' or 'LAN' or inside (inbound)- so things will work right away. Also, the WAN I use, pppoe, when connecting, will attribute 2 DNS servers from my ISP which unbound uses right away. Anyway, whatever 'WAN' connection you offer to pfSense, unbound will do the job as advertised. To explain the "60 sec delay", you need something really bad in your network setup.

If scrolling drop down menu when Top Navigation Fixed is not easy then consider fly out menus or multi column. Currently, I have to use the keyboard and bubble help to select the off screen items.

That's possible too, but I would try and exhaust the options on getting the cores in first. If someone wants to take a stab at it they can, I haven't messed with inputting into RRD yet. I think the file you want to look at is /etc/inc/rrd.inc.

Yes, they will fallback to local users when the LDAP server specified for login doesn't work. This came in handy earlier this week when the certificate on our domain controller expired and it couldn't complete the LDAP over SSL bind correctly. Put in username admin and the password that we had changed it to and updated the appropriate information

Thanks, will wait for the new release.

Big thank you for responding. Sounds good sir, awesome job!

I'm not using 2.2.6 anymore (its 2.3 show time now for me) , but I guess the code is still the same; /usr/local/www/services_captiveportal.php : /* Clear up unselected interfaces */ $newifaces = explode(",", $newcp['interface']); $toremove = array_diff($oldifaces, $newifaces); if (!empty($toremove)) { foreach ($toremove as $removeif) { $removeif = get_real_interface($removeif); mwexec("/sbin/ipfw zone {$cpzoneid} mdel {$removeif}"); } } Your error indicates me that $removeif contains nothing : ipfw will bail out. This means that $removeif = get_real_interface($removeif); will return nothing ….. because it's is "non-real" interface. Have a look at the interfaces you selected for your captive portal : all are ok and do exist ? You swapped NIC's recently ? Use https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting to check of the $cpzoneid ("2" in your case) is correct.

You didn't copy the patch correctly, and provoked a PHP error. Undo your path - and you'll be fine. edit :  https://github.com/pfsense/pfsense/commit/905e1156680129b3c49fe380b4e821f9eb02362 == strange. This was already 'solved' 7 month ago : https://redmine.pfsense.org/issues/4625…. edit : it's even worse : the 'patch' is present in 2.3.0. Why are you trying to apply something very, very old : https://github.com/pfsense/pfsense/commit/905e1156680129b3c49fe380b4e821f9eb02362  (NOT valid for this pfsense version) ??????

Thanks for finding this. The separator text is now wrapped in a CDATA block before being saved and you sample sequence now works as expected.

When I set that it puts the zero line in the middle.  Allowing for negative users.  Number of users can never be negative.

I had one of my pfBlockerNG beta testers run into this issue, when UBlock was blocking a FA icon. Info here: https://github.com/chrisaljoudi/uBlock/issues/428 https://github.com/gorhill/uBlock/issues/15

Thanks for the feedback. We might find a better solution for mobile nav in the future.

Is pfSense doing a DNS query for my.local.domain.com? Do you have SOA for my.local.domain.com?

Just a suggestion, no idea if this will work. Try two backslashes '\' or three '\' or four '\\' it might be escapable.