Locking this thread for now, separate threads are better from here on.
The purpose of this thread was for problems specific to 2.1 – meaning, package X worked on 2.0.x, but not 2.1. Most of those have been fixed, but packages that were broken on 2.0.x are also likely broken on 2.1 (e.g. stunnel, vhosts, freeswitch) and that's beyond the scope of what this thread is meant to deal with.
I was originally doing triage trying to fix what I could on things to get things in decent shape, but we're at the point now where the package maintainers for items with remaining issues need to step up and fix what few things are left. In the cases where there are no active package maintainers for certain packages, someone with the time/knowledge may have to take them on.
Yes we are doing quite much on the system, but as we are sitting in Nepal we have no chance at the moment to get an other one with more RAM. We striped down to the minimum of services we need but still have problems. And i doubt our charity can pay for commercial support.
Could you explain why you think this fix is unpredictable? By default it does not do anything, just if the administrator enters values in the "Maximum delay time" field it will be active.
I agree with you that the problem is PHP and not the services them self. But even more that is an argument for me to use the sleeping solution as an temporary fix. We basically wait till the one php process is finished before we start a new one.
Controlling the PHP forking would be of course a much better way of solving this problem. But as you told your self it's to late to have that change in 2.1. That would mean there would be no solution till 2.2 comes.
What about having a workaround in 2.1 and going for a proper solution in 2.2?
And to be totally clear: this had nothing to do with pfsense.
It wasn't "client isolation" in my WAP, per se, but the fact that my Cisco Aironet WAP was interfering with multicasting. I found the solution here: http://forums.androidcentral.com/google-chromecast/301720-issue-chromecast-cisco-aironet-1140-a.html (i.e., disabling igmp snooping).
Thanks for all the suggestions; they were helpful in tracking down the real issue.
Actual problem was a Realtek 8111E (on Asus C60M1-I motherboard) causing numerous problems, including pfSense restarts. One of the WANs, the problematic one, was on this interface. Besides Intel dual gigabit LAN in PCIe slot.
Temporarily installed a USB LAN for Nintendo Wii, disabled Realtek in BIOS and all problems are gone now. Will add a Cisco smart switch with VLANs as a permanent solution instead of USB LAN once it arrives.
I'll second this issue. Sometimes I load the Queue's graph and the numbers look reasonable even though smoothing looks too aggressive. And other times my Wan says it has 200Mbps when the provision is for 5Mbps. No way to reset the numbers.
Be helpful to know the file that defines the averaging of values in the graph columns. I'd like the Bandwidth column to average over maybe 3 to 5 samples since the interval is 5 seconds.
I have two tunnels from he.net to two different tunnel servers, one on my DSL, one on Cable, and they both work fine independently or at the same time (NPt helps there).
If they all went down at the same time then one of a few things had to have happened:
Your monitor IP pings were not going over the interface you thought they were
Upstream connectivity to the tunnel servers died (Happens a lot when someone decides to DDoS he.net)
Something else along the path caused the tunnels to drop
With quite a lot more information about your setup, it may be possible to speculate more accurately about the cause, but there isn't enough to go on there.
the reason i need this is because of another issue not related to this thread, when u create a dyndns entry with interface as wan failover group, sometimes when the wans switch the dns doesnt get updated at all
We (a friend at my workplace and myself) are working on some rc.bootup changes to handle low-memory systems better - giving the option to slow down the boot process, checking free memory after each significant process is started and waiting until it stabilises before moving on. We are also thinking about moving the OpenVPN startup until later, as OpenVPN process startups are memory hogs, and it might be best to have all the other essential things up and running before OpenVPN.
Hopefully there will be a proposed code solution later in the week.
If you have any ideas to share to improve the boot process, let us all know.
As i said in the other thread its not openvpn the issue its the php.
If you want to be smart enough you should optimize check_reload_status to check memory conditions or even not fire an similar even if its running.
The simple hack to make all things work on lowmem systems would be to tell check_reload_status to serialize the events and wait for one to finish before starting another.
That will give you predictable behviour on lowmem systems.
Do you mean Firewall Alias?
Firewall Aliases are used in Firewall Rules and other places in the pfSense code. The Firewall Alias name and its associated IP addresses are not added to the DNS hosts file.
(That would be quite difficult to implement generally, because aliases can have other aliases, FQDNs, networks… in them as well as simple IP addresses.)
To get name/IP-address into /etc/hosts, add them to DNS Forwarder, Host Overrides.
That code is part of the OpenVPN Client Export package. It sounds like the package did not reinstall after the last firmware update. Look in System->Packages.
You are right! For some reason the last upgrade did not reinstall the packages and had to reinstall them manually, but I completely forgot that the Client Export is a package and not part of the normal install.
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.