@cmb: @Apathia: What's weird is I first upgraded the system and then followed it up with a fresh install after a few days of it not working. When I did the fresh install, I didn't import anything and just set up the basic things and still no go for the quality monitor. I did eventually end up importing my old config to get a few other things back to what I had. huh, yeah that's odd. The reinstall would have started with fresh rrd data files as long as the config you restored didn't include RRD data. So it shouldn't have happened in that case. Sure you didn't have RRD data in the restored config maybe? @Apathia: As far as anything in the system logs, well I'll have to check later when I have access to it. EDIT: Nothing in the logs as far as I can see, anything specific I can search for or just rrdtool? Just rrdtool would suffice. 'clog /var/log/system.log | grep rrdtool' No results when searching for rrdtool. I did have the data in my old config, but I didn't restore it right away. After the upgrade I backed it up then did a factory reset but that still didn't work so I did a fresh install. After waiting a day or two with it still not working, I did finally restore it to get the misc settings that I hadn't bothered to go through initially.

It sends a notice if the new status is different than the old status. Detecting just a change from one complete state to another would require a lot more logic. The spamminess is a side effect of it checking that status each minute. Though if it did the check less often there's a chance it could miss something important. Personally, I like the updates to know it's still progressing. If the rebuild stalled I'd know about it fairly quickly.

Weird.. i could have sworn there was no scrollbar there when i made the post yesterday(and for every other time i've tried to figure this out before posting), but after logging in today to check, there it was. Thanks.

@klou: Rename /usr/local/sbin/nginx, copy a new one in it's place, make it executable. Use at your own risk … but compiled from FreeBSD 10.3 i386. nginx version: nginx/1.8.1 built with OpenSSL 1.0.1s-freebsd  1 Mar 2016 TLS SNI support enabled configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx-error.log --user=www --group=www --with-file-aio --with-ipv6 --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx-access.log --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gzip_static_module --with-http_gunzip_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_stub_status_module --with-http_sub_module --with-pcre --with-http_spdy_module --with-mail --without-mail_imap_module --without-mail_pop3_module --without-mail_smtp_module --with-mail_ssl_module --with-http_ssl_module By using your binary I was able to get the WebGUI to work again, I went to system->update and could select the development branch and installed 2.3.1, which actually works fine now… THANK YOU!

Are you hitting your wan from a rfc1918 IP?  If so those would be blocked before any rule you added is even looked at..  If your hitting your wan IP from rfc1918 space then you have to turn off the default of blocking that.. Which would be listed very top of your wan rules. Post your wan rules, and we can take a look see to what might be wrong..

Thanks you very much.

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) ??????