what we know at this point. https://blog.pfsense.org/?p=1514

Confirmed, ticket opened. https://redmine.pfsense.org/issues/4131

thank you! looking forward for the fix

Yes, it is intentional. Snapshots are not signed currently. Only images we "release" such as a full -RELEASE or an announced -RC get signed. Eventually we may have a "snapshots" key to sign such interim updates but that's not in place just yet.

Thanks for the confirmation. Some work (funded by Netgate) was done on the hash alg in part of pf which got merged into FreeBSD (newer than 10.1), and the patch set we included was wrong, only hashing a quarter of the bytes. It's a nice little performance improvement (when it's included correctly). In circumstances like the one you described where you didn't have significantly more CPU than necessary for the job at hand, that slowed things down dramatically.

Didn't see where the switch was changed, but if that's the case, especially given it's a managed switch, there can be issues introduced by your cable modem from seeing traffic the switch is sending and treating its MAC as the device authorized to use the Internet. I had a cable modem that'd see STP, LACP, CDP or similar traffic from a directly-connected managed switch and pick that MAC as the one it'd let out. Even if the switch wasn't changed, it could just happen to have hit that circumstance by chance where it didn't before.

It should be there already, no need to do anything. The HPN-related options are accepted in sshd_config, and default is enabled. https://github.com/freebsd/freebsd/blob/master/crypto/openssh/README.hpn I think you're just expecting behavior that only exists in the patch set, and not the later merged implementation in FreeBSD.

Thanks, should be fixed. https://redmine.pfsense.org/issues/4126

At that point the code has not checked for enabled/disabled status of each OpenVPN instance. The message is emitted if there are any OpenVPN instances defined. If they happen to be all disabled, then as the code loops through each it will ignore all the disabled instances. So in your case with all disabled, no action will be needed/taken.

Hi, I have the same issue (but with queues RRD) on my 2.1.5-RELEASE (amd64) built on Mon Aug 25 07:44:45 EDT 2014 The wan connexion is 100Mbps symetric, and there were no clients at all in the lan network (both are different vlans on same interface), since the pikes on the graphs seems synchronized, something is going on somehere .. just can't figure what it is. Strangely, no spikes at all on the trafic graphs. I know I'm in the wrong category, but it's the only topic I found about this. Note that I saw those kind of artifact as long as I used pfsense (from version 1.8 or 1.9 I think) [image: lan2-status_rrd_graph_img.png] [image: lan-status_rrd_graph_img.png] [image: wan-status_rrd_graph_img.png] [image: lan2-status_rrd_graph_img.png_thumb] [image: lan-status_rrd_graph_img.png_thumb] [image: wan-status_rrd_graph_img.png_thumb]

I put a fix for the logging issue. It will behave better now since it was not properly configuring silent.

I got that message back in September too. It's just a warning that when something goes wrong, you won't receive any support until you upgrade the Gues OS's Integration Services. Till then, don't worry too much.

2nd. confirmation: Positively tested on a Sony Vaio PCG-K315S  ( which is Pentium IV aera ) , running from CD-boot straigt away. Thanks.

Awesome!  I can tell I need to spend some time going through the details of each page so I can get a feel for new options / changes. I did find some unnecessary (and potentially harmful) routes being setup in the OpenVPN config, which I have removed.  I'm not sure how to attempt to trigger the buffer issue, so I'll keep an eye on this and update the subject line to resolved if I don't see it again in the next 10 day or so. Thanks for the guidance and the features!

The amdtemp kernel module in FreeBSD 10.1 has support for k8 - k15 (https://www.freebsd.org/cgi/man.cgi?query=amdtemp%284%29&sektion=). Some users are reporting that they need to add some temperature adjustments to the numbers.

Have you php-fpm[67182]: /rc.start_packages: The command '/usr/pbi/squid-i386/local/sbin/squid -f /usr/pbi/squid-i386/local/etc/squid/squid.conf' returned exit code '1', the output was 'Shared object "libmd5.so.0" not found, required by "squid"'  in your log  ? May be you can try this solution… it works for me... https://forum.pfsense.org/index.php?topic=84638.msg466448#msg466448

Seems like the current values seen in the IPSec Advanced screen (possible after upgrade) is not actual values. I also tried to change some values and back to silent and then the log got quiet. Does anyone know how to get similar default logging as in 2.1.5 with racoon ?  A new good standard setting with moderate logging of the most important stuff would be nice. The debug logging of Strongswan contains so many more areas and several options per area so it is difficult to find an optimal level with enough "good" info but not too much. Dan Lundqvist MRZAZ.COM Stockholm, Sweden

Added bug report: https://redmine.pfsense.org/issues/4118 Note that this replaces the prior report of USB issues which was due to the start up script attempting to use the old install of NUT from FreeBSD 8.3 rather than the new one from 10.1.