Hi, I am brand new to this forum.  Have been using BSD for about 5 years and pfsense for about a year (running on an Alix).  I had noticed I couldn't get anything out of the packet capture function and never really played with it until recently.  I am having a flaming nasty dispute with my ISP and really needed this to work.  I did a search and found the posts talking about how this was broken on embedded and suggesting replacing a file.  There were also some other patches proposed.  Having poked around a bit in the file system I realized that the issue was that the file is being written to /root which is normally read only on the embedded version.  The patch calls the PHP function that marks the file system read/write and sets it back to read only on exit.  If you stay in that page and are not attempting to capture after you leave it then maybe that will work, but here is a much more stable (and easy) to apply fix: 1.  Go to Diagnostics - Edit file. 2.  Enter /usr/local/www/diag_packet_capture.php 3.  Scroll down to just past the copyright notice for the line $fp = "/root/" 4.  Change it to $fp = "/var/" Save the file.  Your packet capture should now work fine on 1.2.3 embedded.  /var is a memory disk on embedded.  Your captured data will not survive a reboot.  I don't personally see this as an issue.

Thanks again for your help :) ;D

This sounds to me like your IP Phones already send tagged traffic to the switch. In this case you would have to add the ports on the switch as tagged members of the VLAN. The PVID would be set to the VLAN on which you get the config.

It's a third ISP, and there was nothing wrong with it..? I was able to rebuild the routing tables by running "/etc/rc.d/routing restart", and this removed that erroneous route, and cleared everything up. I don't know how it got created in the first place, but fingers crossed it won't happen again.

install rrd summary or vnstat2 package… They should help you

Hi, hmm  bridging is not a good option here because services would affect each other eg. dhcp gateway. I think that dont work very well. I would prefer option 2 because: -devided networks -prevent broadcast traffic over wireless network -failover possible and more easy (the failover gateway is the wlan interface ip adress of the opposite pfsense) cya

The denyhosts package will help block ssh script kitties. Yes this is a port scan being run against you by many script kitties. I would suggest changing the SSH port to something other than 22 (like 222). This will prevent these types of attacks.

Sometimes it takes other people to point out the obvious (been there myself many times). It could have been almost anything, the trouble is that cheap unmanaged switches have no diagnostics, so it's impossible to tell what's gone wrong. Buying a managed switch (Mikrotik's RB250GS is one cheap 5 port option) gives you a better chance to diagnose that type of fault.

You could just add firewall rules to your wireless interface to allow it to access the internet. No need to swap LAN and OPT1 (unless I missed something). It looks to me that on my system the web server (lighttpd) will accept incoming connections to any address, not just the address of the LAN interface. Indeed I was able to connect to it from a system on an OPTx interface.