Are you saying Snort is not working, or are you just fretting about the change in displayed free memory?  If Snort is working, I would say don't worry about the free memory.  There could be several reasons for that not related to Snort.  While Snort is live reloading rules (for example, after a nightly rule update) it will possibly use up to twice as much memory as normal since it temporarily holds two complete copies of the configuration in memory (including rules).  It then switches the running Snort process over to use the newly built second in-memory configuration and then destroys the old configuration.  That will account for some of the memory decrease. Bill

thanks for your reply

Acording to this it seems OK. But, ill try to do some fiddling with settings. Thanks for pointing it out for me. http://vip.asus.com/forum/view.aspx?board_id=1&model=P5GC-MX&id=20110715191107398&page=1&SLanguage=en-us

Benefit of others?  So other people with layer 8 issues like yours?  So no errors in the log, showing your config would be a simple screenshot taking 2 seconds..  But your helping others by telling them hey if dns doesn't work exactly how you think it should work go back to 2.1.5??  Yeah that is going to help thousands I think :rolleyes:

And knowing your IPs is equally useful (-;

Thanks, that gave me an excuse to move to the 64 bit install. Everything went smoothly and populated /etc/rc.d appropriately. arri

It work!  :) Thank you!

Am also facing same issue after upgrading to 2.2 from 2.1.5. event_wait interrupted system call (code=4) Please help guys..

What pfSense version is the secondary running? If the versions are sufficiently different the pfsync protocol may not be the same which will prevent syncing. See: https://doc.pfsense.org/index.php/Redundant_Firewalls_Upgrade_Guide I think you're OK between 2.0.X (8.1) and 2.1.X (8.3) though. Steve

I'm also seeing this issue, also running a 'mismatched' architecture since the host is x64 and the VMs are x86. In some cases a clean install is more difficult (since that'd leave the customer without internet access in many cases to perform the reinstall, so it requires being there), so I tried other options that could be done remotelly. I eventually found out that disabling IP compression on the advanced ipsec options seems to have fixed the issue, went from at least a crash/reboot per hour to running more than 24h stable and counting, running both IKE v1 and v2 tunnels (so that's not the source of the issue in theory). Clean reinstall on proper arch is probably the best solution long-term anyway, but if the issue is with IPcomp then disabling it might help others who are now facing issues. Will update if I see any more crashes.

If it's a USB CD-ROM, check the port it's in. If it's a USB 3.0 port, try a USB 2.0 port instead. A USB memstick would be faster/easier than a CD anyhow though

Many thanks Steve, just saw this, no, I hadn't cleared the CHS settings, I'll try again this aft if I get chance. I did set all to Auto for the drive, assuming it would rescan the disk afresh, but if it still holds that config, that would prevent boot. I'll report back with results.

Yep ^ that. You don't need to open the .img file. Once you've removed it from the gzip (.gz) you write the .img file to the USB drive. Steve