@fragged: I might be talking out of my ass here, but from what I know, you need PPS to get accurate and reliable time from GPS ^^ This.  Without PPS, your gps is worse than most ntp time servers on the net, unless you have a very bad & variable WAN connection. @masterd01: Over the WAN-Side i got the Timeservers of the PTB in Germany (ntp1.ptb.de, ntp2.ptb.de, ntp3.ptb.de) as fallbacl. Your screenshot shows them with 'reach' of '1', which means either you are not getting valid responses from them, or you are looking right after you (re)started ntpd. But after some time all Pears go to "False Ticker" and the NTP-Daemon is restarting. Does anybody had the same Problem? Or any ideas to got this working correctly? Bad clocks, poor peer response, etc. should not cause ntpd to restart.  More likely the restart is due to a change you made in the gui? Your best bet is to get PPS working properly; it does work with pfSense: ntpq> pee     remote          refid      st t when poll reach  delay  offset  jitter ============================================================================== oGPS_NMEA(0)    .pps.            0 l    -  16  377    0.000  -0.003  0.001 +wtf.roflcopter. 195.83.222.27    2 u  50  64  377  111.666    2.243  2.230 +108.61.194.85 ( 132.163.4.101    2 u  32  64  377  107.992  -13.892  2.647 *repos.mia.lax-n 200.98.196.212  2 u  46  64  377  55.956  -1.887  1.289 ntpq>

ok give me some time, during idle time ill try and recreate the crash and get u the report. any tunable to disable DMA and test?

I am asking if it might blackhole traffic due to the fact that the old tunnel is still active (by the looks if it from the GUI). I have not experienced that it actually will blackhole the traffic.

For this issue to be fixed wait for a snapshot of later today. The issue has been fixed just now and the status is on #4177

Dear Phil.davis Thanks for your reply.  There is no problem with $_POST['add_x']. The reason is since the button is declared as image button, what is actually sent to the server is add_x and add_y ie, position of the mouse on the image. In other word, _x and _y are added to the name of the image button. PS: I traced the code and the code in this part are executed as well. Except that there is some problem with input validation. Thanks, Vahid Foroughi

Problem Solved Baudrate was 38400 when working with ALIX and BIOS.  It needs to 115200 for pfSense 2.2

I did get them working.  Part of the issue was that there was no type assigned to the LAGG group.  The reason there was no type was because when there was a type, (i only tried failover and loadbalance), the lagg interfaces didn't show up as available interfaces in the VLAN setup menu.  However, they did show up when "none" was selected.  "none" doesn't pass any traffic.  Going back after and then switching to loadbalance worked just fine. The vlan lagg issue seems to have been resolved in a nightly build. I think this was similar https://forum.pfsense.org/index.php?topic=86147.0 Thanks for the help!

@johnpoz: Oh I see it now ;) "other than adding snort" Yeah that should be BOLD and first line.. Like So pfsense using snort… would be how the post starts ;) Guilty as charged on that one. As to ipv6 I agree, I use it now and then for testing..  So as you saw in my ipconfig no ipv6, click and then ipv6, but still no nonsene teredo, 6to4, isatap ipv6 conversion stuff..  Why would anyone need so many ways to get to ipv6 from ipv4?  Let them pick the one they want and install it..  You would of thought they learned their lesson many times over about protocols being enabled out of the box that can cause problems and security concerns by now ;) Its a balancing act between locking things down and providing the convenience of the OS experience. UPnP being one example, IE integrated into the OS as another, or in this case, default enabling new stuff they roll out, to help test it on a wide range of HW, not to mention all the problems that can follow.

But will reducing the queue number affect performance? Is there any info on the optimal queue number for this board?

@charliem: @Mr.: So I put myself on my main box which has 2.1.5 (first one in my sig, the second box, the DELL, has 2.2RC), which has exactly the same FW rules as 2.2RC, et voila: all mails sent right away. Can you explain what you mean here?  I'm probably dense … you have two pfSense firewalls, one for each of your WANs?  One ISP for your wife and one for you?  Jim's advice is on the mark for looking further, I'm just curious. Sorry, yes, that could appear confusing  :-[ [list type=decimal] I have a WIFE. She's such a fine one that I only spell that word in capitals ( ;D ); When we met a long time ago I said to her: 'I will do anything for you, anything your highness desires –- but I will not cook. Not now, not then, not ever' (I hate cooking >:( ); As a consequence she can cook, I can't; Food is a necessity of life, for which I've thus made myself completely depended on WIFE; WIFE threathens to withold food from me if internet breaks down (women…); Therefor I have dual WAN in failover, and a backup pfSense, the Dell; should the first one suffer from whatever, all it takes is switching some cables and she is good to go again (I don't have CARP, the Dell is not very low on energy consumption); It just so happened that I powered up the Dell to install 2.2RC on it, trying to see if the VPN problem I had would be solved in 2.2; so that's why we were both on the same 2.2RC for the time being (normally we would both have been on the other machine, the 2.1.5, and the Dell would have been powered off until emergency).

Thanks Chris, will updated and report back in a new thread.

@cmb: Several people have found things that work for them in this thread. https://forum.pfsense.org/index.php?topic=83424.0 Finally got around to re-testing again using the RC. The suggestions in the other thread helped. Unfortunately, still no connections above 54Mbps. I set the regulatory settings to FCC and USA/FCC. I HAD to manually select the channel or it would not come up when "NG" mode was selected. I also did increase the key rotation times. Not sure if that helped though. I would have to agree that so far the "N" access point stuff is definitely unstable. I am REALLY looking forward to this being fully functional. –-a couple of minutes later--- I re-read the other thread and I checked the WME option. I now get more than 54Mbps connections but it seems to bounce around a LOT. Maybe the WME option can be automatically enabled when "N" is used? I am just basing that off of someone in the other thread saying QoS is required for "N".

It only started it after I upgraded the system to Pfsense 2.2 because Pfsense 2.1.5 both of the Wifi interfaces work perfectly.

Normally that is a FreeBSD property of how it manages these rules. Whenever they get updated they get put last IIRC. There is a priority setting supported on strongswan for such situations but FreeBSD does not support it. Though apart technical details you solution is to remove the second phase2 and use firewall rules to control this. It is more manageable as well like that, no?

http://lists.freebsd.org/pipermail/freebsd-usb/2009-March/006493.html

@firewalluser: Just noticed as I've just installed snort (15:22 local time), firstly it wasnt showing in the packages, but having installed it, the below text is visable on the snort updates page. Snort VRT Rules Not Enabled Not Enabled Snort GPLv2 Community Rules e9cef31b25866760230a34cca074e854 Saturday, 10-Jan-15 13:01:08 GMT Emerging Threats Open Rules 1fe055c19fea21900ea4442022559ff5 Saturday, 10-Jan-15 13:01:09 GMT Snort OpenAppID Detectors Not Enabled Not Enabled Would this also be connected to the snort.sh script? No, this is simply showing that upon the reinstall, Snort detected an existing configuration in the config.xml file and acted upon those settings.  Snort's settings are stored in the _<installed_packages></installed_packages>_section. @firewalluser: Edit. Just to be clear, this was a fresh memstick install this morning, restored a backup but later decided to abort it so I chose to use the option 4 on the console, reset to factory defaults. Is it possible the Reset to factory defaults is not resetting everything ie there are still traces of apps & settings from packages left over? I could not see anything in the xml backup related to snort apart from "snort_alerts-" found in the <widgets><sequence>section having done the factory reset. fwiw.</sequence></widgets> I have not tested this, but it very well could be that the reset to factory defaults only resets the pfSense firewall settings and leaves any existing packages information in the aforementioned _<installed_packges></installed_packges>_section of config.xml alone. @firewalluser: Edit 2 https://192.168.10.1/snort/snort_rulesets.php Snort, Wan, Wan Catagories tab. Resolve Flowbits   If checked, Snort will auto-enable rules required for checked flowbits. The Default is Checked. Its not checked. Edit 3 Enable SSH Detection The SSH preprocessor detects various Secure Shell exploit attempts. Its checked as default, but all other comments state in this section of https://192.168.10.1/snort/snort_preprocessors.php?id=0 is to have  "Default is Checked." after the comment. Eg General Preprocessors Enable RPC Decode and Back Orifice detector Normalize/Decode RPC traffic and detects Back Orifice traffic on the network. Default is Checked. Enable DCE/RPC2 Detection The DCE/RPC preprocessor detects and decodes SMB and DCE/RPC traffic. Default is Checked. Enable SIP Detection The SIP preprocessor decodes SIP traffic and detects vulnerabilities. Default is Checked. Enable GTP Detection The GTP preprocessor decodes GPRS Tunneling Protocol traffic and detects intrusion attempts. Enable SSH Detection The SSH preprocessor detects various Secure Shell exploit attempts. Enable DNS Detection The DNS preprocessor decodes DNS response traffic and detects vulnerabilities. Default is Checked. Enable SSL Data SSL data searches for irregularities during SSL protocol exchange. Default is Checked. should be General Preprocessors Enable RPC Decode and Back Orifice detector Normalize/Decode RPC traffic and detects Back Orifice traffic on the network. Default is Checked. Enable DCE/RPC2 Detection The DCE/RPC preprocessor detects and decodes SMB and DCE/RPC traffic. Default is Checked. Enable SIP Detection The SIP preprocessor decodes SIP traffic and detects vulnerabilities. Default is Checked. Enable GTP Detection The GTP preprocessor decodes GPRS Tunneling Protocol traffic and detects intrusion attempts. Enable SSH Detection The SSH preprocessor detects various Secure Shell exploit attempts. Default is Checked. Enable DNS Detection The DNS preprocessor decodes DNS response traffic and detects vulnerabilities. Default is Checked. Enable SSL Data SSL data searches for irregularities during SSL protocol exchange. Default is Checked. Only cosmetic.  :) Thanks for reporting these inconsistencies.  I will look into them and fix them as necessary.  There have been at least three different sets of "hands" modifying the Snort package over the years, and there is some inconsistency here and there in all the PHP code.  For example, in some cases Boolean parameters in the config are stored as "yes" or "no", while in other places it may be "on" or "off".  I have been trying to clean those up. Bill

@skywalker: see below for the output. The output looks OK to me, that machine is sync'd and operating as a stratum 3 What really struck me here is that the reach goes up for a while and then falls back to 1. Surprisingly the same configuration did work before the upgrade (well, at least none of my clients complained before). 'reach' is a living number, updated every time a response is expected from your system peer(s).  (Please re-visit the link posted above).  If it decreases from 377, then you are not getting valid replies from you system peer(s).  Something may be blocking port 123.

Mmm, intersting scenario. This wouldn't have happened if pfSense was using https for webgui. Presumably at some point the pfSense webgui was open on WAN and the remote Squid cached it. Seems odd though. Like you wouldn't be able to login and any dynamic parts of the dashboard wouldn't work. Steve