if it's the issue specific to tap interfaces, which it probably is since that's the only way that could happen, that's fixed in 2.1.1. https://redmine.pfsense.org/issues/3475

Rolled back to 2.1 release, replaced the filter.inc, will keep monitoring the behavior… Thank you!

Ah… Does anybody use it that way??? I end up using different computers here and there, so a local copy of the forked repo would be a pest. For changing just a couple of files, I copy them manually from the "raw" github view, edit in Notepad++ (saving them in my DropBox) and paste them back into the GitHub online editor when done. I suppose I could put the local copy of the fork into DropBox and edit there - that would let me use it from multiple computers. I hadn't thought of doing that. Hmmm - rather drifted off the topic of this thread - sorry.

Yes, I understand that IGMP is only used for the UPNP discovery/advertisement (I authored a UPNP support library for embedded systems). I'll give your suggestions a try, though I fail to understand why an upstream interface designation is required at all if the igmpproxy implementation is symmetrical for all interfaces as you say.

I've done reset to factory defaults. The problem disappeared.

I wonder if this might be one of the issues with the newer version of the em driver. These newer versions were pulled from pfSense 2.1.1 after February 24th. I was having occasional "DHCP failues" on the WAN interface (em0) as well. However, for the last few days, everything appeared to work fine again.

It's not relevant to 2.1.1 release

Perfect, thanks!

There is exact same hint in DHCP (v4) page. Again, v4 is supposed to pick up v4 stuff, and v6 is supposed to pick up v6 stuff. What you are seeing is invalid DHCPv4 configuration.

Great, thank you! One more for you… Are those settings only available when it's a dashboard widget? I usually look at it from Status -> Traffic Graph so I never even saw the option. Perhaps it should be on both pages.

I have just updated to the latest snapshot and done a quick check: Both WLANs are up and running for the first time with pfSense 2.1.x! Thanks so far. Now I can go into more testing details. Regards, Peter

Huh this is still lasting… Some DDoS attack :)

Indeed that is a problem copying PHP_errors.log - for example this code fails: $xxx = copy("/var/etc/resolv.conf","/tmp/"); var_dump($xxx); outputs: Warning: copy(): The second argument to copy() function cannot be a directory in /usr/local/www/exec.php(246) : eval()'d code on line 1 bool(false) and the fix is: https://github.com/pfsense/pfsense/pull/954

Wow, you are a magician  ;D Tell the truth, there's a backdoor in pfsense and you see all?!?!? XD Going back serious, thx for your explain :) I will wait! Only a question: using pfsense SNMP or softflowd ( https://doc.pfsense.org/index.php/Exporting_NetFlow_with_softflowd ) this data are still bugged ?

Did you upgrade from 2.1 release or 2.1RC0? Steve

+1

Problem solved  :). Thanks 2.1.1-PRERELEASE (amd64) built on Tue Feb 11 22:10:33 EST 2014 FreeBSD 8.3-RELEASE-p14

just upgraded to the build from feb 11th … and for the first time with the new pre-release snapshots my alix went online without manual intervention. Great! ;-)