ok will need to try it

Have seen the same problem occur with our setup: https://forum.pfsense.org/index.php?topic=73460.msg401168

I had that problem myself but never found out the reason. The problem just did not occur anymore and I did not have the opportunity to analyze this.

There are several possible reasons apart form a problem with pfSense itself: pfSense could not receive group membership packets by the receivers of the stream or the provider could simply have caused that drop.

You could start by monitoring the IGMP traffic on the WAN interface (Diagnostics / Packet Capture). I would prefer using tcpdump from the command line on pfSense because you can filter IGMP traffic.

If you do that while receiving the stream then when you have drops you should check the exact time. This way you can associate the drops with events in the packet trace. I would first look whether the drops have been caused by missing IGMP packets to your provider.

What error are you seeing?

You can switch back to http at the console:
https://doc.pfsense.org/index.php/I_locked_myself_out_of_the_WebGUI,_help!#HTTP_vs_HTTPS_confusion

Steve

The backup/restore functionality is pretty comprehensive.  Instead of imaging, perhaps try installing fresh and then loading the old config via Diagnostics - Backup/Restore.

@paklids:

3. Make pfsense "puppet friendly" (or just get the ball rolling - it doesn't have to be complete). Yeah, someone can post a bounty….then wait.....then get no response. Keep in mind that these changes are going to appeal to Enterprise environment admins who already have their commercial firewalls with dedicated change management systems - those people rarely post bounties.

Although this is a somewhat old post, the situation may change to match your needs… I've started adding puppet support to pfSense as a separate package:
https://forum.pfsense.org/index.php?topic=79397.0

You're welcome to contribute to the pfSense puppet provider and the puppet modules:
https://github.com/fraenki/puppet-pfsense
https://github.com/fraenki/puppet-pfsense_rancid
https://github.com/fraenki/puppet-pfsense_autoupdate

Regards

KOM,

I am using 2.1.4 with Squid version with 2.7.9. Not sure why I couldn't save the changes, so I did a Backup and reset the system to factory settings and now it seems to be working fine.

Thanks Jason that is the confirmation I was looking for  :D

My experience with ssd's is a myth tv thin client with low io running perfectly for 3 years, win ssd's died every 3 weeks, after 3 months old. Hence I was playing on the cautious side, as my ex server experience was all magnetic based drives, prior to the current job. So sorry but your feedback really helps thanks :)

I will go with it all on the ssd  :D

Thanks for the other input in regards to the rams drives Stephen, the Alix box ran out so this is my reasoning not to use ram drives, but it's sound logic. I scripted those to an external hd on the Alix box.

Thanks also Bryan for confirming further Jason's input, I'm a lot more comfortable with the fact the technology isn't as flaky as searches indicate.

:D thanks all - a great community here supporting a great package of software.

@stephenw10:

You can add feature requests in Redmine. That way they get added to the bug system such that they can be easily searched/listed.
Doesn't seem like a bad idea have a sub board here though.  :)

Steve

I already forgot that there was such a thing as Redmine, Steve :-[

At first sight, one could say a sub board would be duplicate. Then again, it might also be considered to have requests here (first), since I think the audience here is a lot larger than in Redmine (I only think). That way, a sub board here could be used as an informal 'brain storming' place, where noobs like me ask for something, Experts like comment and hence refine the request, and after these discussions in this fine forum a request, then well defined and scoped, could enter Redmine.

I should add: I hate bureaucracy myself  ;D ;D ;D

(But love effectiveness and efficiency  :P )

Yep, the dyndns log entry is just a symptom of the WAN going down. Note that the apinger logs don't show the line going bad slowly with excessive ping times or packet loss gradually building up. They show the WAN going down directly. What sort of WAN connection do you have? Does the time, 19.42, equate to anything you might have done? What time was it you last reset your modem?

Steve

i haven't tried it myself but you could tried to configure IGMP Proxy

If you have a samba server or windows server that is up 24/7 then just have that run a WINS server and add it to the DHCP configuration in pfSense so that all clients register with it. These sorts of problems usually occur when you have a network of windows boxes behind pfSense but no domain controller and no WINS service. In that situation one box will become the 'netbios name server' but if it's turned off it can take ages for another machine to take over that duty and longer for it to have a complete list.
It's been a while since I've had to deal with that I could be skipping a few steps!  ;)

Steve

I have seen similar errors caused by something as simple as a card that had become unseated in it's slot. Also bad cable or bad switch, anything that might stop the NIC actually sending packets whilst still being connected enough to show up.

Steve

Yep, you shouldn't be swapping, ever. Not if you want any sort of decent performance anyway.  ;) Quite why running a public IP would require more memory though is odd if that is the issue.
What hardware are you running? I see you have 256MB RAM, are you running any packages?

Steve

If you work with it alot then yeah, it would be difficult to understand.  I hit that bump often myself.  Even just a little confirmation dialog would probably help alot.

Yep, looks like it's included in FreeBSD 10:
https://svnweb.freebsd.org/base/head/sys/dev/usb/net/if_urndis.c?view=log
Don't know whether it made it into 2.2 though, I'll have to re-fire my test box. Also I can't find what devices it supports.

Edit: Looks like it uses a generic USB vendor/product ID so it should work with a variety of hardware, all Android though  :-. Some older man pages list some known hardware:

The urndis driver provides support for Ethernet access over Remote NDIS.
    The urndis driver should work with all USB RNDIS devices, but the
    following devices are known to work:

o  Google Nexus One
          o  HTC Dream / T-Mobile G1 / ADP1
          o  HTC Hero
          o  HTC Magic
          o  HTC Tattoo
          o  HTC Wildfire

Steve