SquidGuard is also pretty memory intensive.  It launches a user specified number of redirectors which handle the filtering decisions, which means that they sit and use up a lot of memory.  Not something I'd want on an embedded box.

Thanks ryates. That was the problem. I re-flashed the box with 1.2.2 and it's working great now.

Note that the changes from 2.0.6 to 2.0.9 all relate (as it says on the OpenVPN site) to the Windows installs.  There is no need to upgrade from 2.0.6 to any of the later 2.0.x series on FreeBSD.

fixing the XML "cannot occur more than once" error which showed up elsewhere (again, for an option which didn't even exist in the current configuration, only in backups) made this problem go away.

Hello,

thanks for this informations, i have an mini-IDE-Drive connected, this works fine.

By

It was tested both before and after the reboot.
They both failed.

I just tried again, and now it syncs, so it looks like the ntpd somehow failed before the reboot.

1.2.3-RC2 built on Wed Jun 10 09:44:42 EDT 2009

if enable periodic PPPoE resets , reset at each day ('0 0 * * *')

pppoe not respawned after down

Jul  8 00:00:01 pfsense mpd: [pppoe] rec'd signal usr2, closing Jul  8 00:00:01 pfsense mpd: [pppoe] IPCP: Close event Jul  8 00:00:01 pfsense mpd: [pppoe] IPCP: state change Opened --> Closing Jul  8 00:00:01 pfsense mpd: [pppoe] IPCP: SendTerminateReq #4 Jul  8 00:00:01 pfsense mpd: [pppoe] IPCP: LayerDown Jul  8 00:00:01 pfsense mpd: [pppoe] IFACE: Down event Jul  8 00:00:01 pfsense mpd: [pppoe] exec: /usr/local/sbin/ppp-linkdown ng0 inet shraik Jul  8 00:00:01 pfsense mpd: [pppoe] exec: /sbin/route delete 0.0.0.0 87.236.40.69 Jul  8 00:00:01 pfsense mpd: [pppoe] exec: command returned 256 Jul  8 00:00:01 pfsense mpd: [pppoe] exec: /sbin/route delete 87.236.41.27 -iface lo0 Jul  8 00:00:01 pfsense mpd: [pppoe] exec: /sbin/ifconfig ng0 down delete -link0 Jul  8 00:00:01 pfsense mpd: [pppoe] exec: command returned 256 Jul  8 00:00:01 pfsense mpd: [pppoe] can't set bpf node program: No such file or directory Jul  8 00:00:01 pfsense mpd: mpd: fatal error, exiting Jul  8 00:00:01 pfsense mpd: [pppoe] IPCP: Down event Jul  8 00:00:01 pfsense mpd: [pppoe] IPCP: LayerFinish Jul  8 00:00:01 pfsense mpd: [pppoe] IPCP: state change Closing --> Initial Jul  8 00:00:01 pfsense mpd: [pppoe] IFACE: Close event Jul  8 00:00:01 pfsense mpd: [pppoe] IPCP: Close event Jul  8 00:00:01 pfsense mpd: mpd: process 7970 terminated

after manual Interfaces|Wan|Save  link is UP

It doesn't appear to respond to the break sequence. Top can be exited with q, but if you use ping without -c, there doesn't seem to be away to stop it.

Hi wallabybob

Thankss for your answer. It helps! I had a roule from WLAN to LAN for all traffic but had no Aliases set. After I put the 2 ports in it works. On WLAN I get now an IP address from the DHCP server which runs on the LAN interface. Very nice.

But another question: I have also a VPN tunnel running from the pfsense wall to a zywall. It works fine on the LAN port, but also after the bridging to the LAN interface I have no connection on the WLAN side. The same I tried in M0n0 and there it works. Maybe there's also something like the DHCP problem before. One small setting wrong. But I can't find it.

Sigma

I downloaded a 1.2.3 freebsd 7.2 based snapshot from link above and installed and it booted just fine!

Not sure if you are a planning to release 1.2.3 based on 7.1 freebsd, but if you do so might want to mention in the release notes that may be a problem with recent release intel cpus.

I haven't tried this in a few days but it worked fine for me the last time I was able to test it.

Depending on the hardware involved generating the SSH keys can take quite a long time, it is entirely possible that the keys were not complete yet.

FYI- the newer 1.2.3-RC embedded snapshots that are based on nanobsd will require a 1GB CF.

That is normal. The console options are only able to be set upon reboot.

You are seeing consequences I am seeing a cause, this is the only difference. ;-)
If multicast/broadcast packet goes from lan to wan and there is CARP then you get storm.
What is important (and interesting) is when I connect my laptop broadcasting with the same IP to WAN net segment then there is no storm. The same packet (at layer 3) coming from LAN (remember - no NAT) does cause a storm.

thanks for the quick reply.

yes the hardware im using is alix too. 2c2

OOps, didn't want to stirr up the soup.

Sometimes a company policy keeps you from upgrading. There are some web apps out there that need IE6/7 to work correctly…
It doesn't make it any better but unfortunately it's still a real life/office scenario for some.

yeah sorry, uses opt1 its a dedicated link, have webservice running, more strange is the interface don´t stop at all, access to IIS is normal, but webservice don´t make connections, fails, in rc1 without any change, works fine, very strange.
All redirects works, have msrdp, vnc, just webservice is down with rc2, but only by optional, with wan works fine.

I spoke too soon. It came back on 7.2 after about a day.
This is top -S:
last pid: 16105;  load averages:  4.61,  5.08,  5.03    up 0+23:57:09  16:24:04
106 processes: 8 running, 82 sleeping, 16 waiting
CPU: 52.2% user,  0.0% nice, 42.9% system,  4.9% interrupt,  0.0% idle
Mem: 59M Active, 11M Inact, 42M Wired, 416K Cache, 26M Buf, 375M Free
Swap: 1024M Total, 1024M Free

PID USERNAME  THR PRI NICE  SIZE    RES STATE    TIME  WCPU COMMAND
13937 root        1  -8    0 40684K 13892K piperd  0:27 12.79% php
  26 root        1 -68    -    0K    8K -      20:05  9.67% em1 taskq
16095 root        1  97    0  3156K  856K RUN      0:00  7.47% tail
16088 root        1  8    0  3492K  1396K wait    0:00  6.88% sh
14832 root        1  -8    0 40684K 13784K piperd  0:16  6.79% php
9109 root        1  -8    0 41708K 15140K piperd  0:58  4.98% php
8421 root        1  4    0 40684K 14364K accept  0:58  4.49% php
  25 root        1 -68    -    0K    8K -      13:07  4.20% em0 taskq
  12 root        1 -44    -    0K    8K WAIT    4:44  2.39% swi1: net
1164 root        1  4    0  7148K  5096K kqread  8:46  0.29% lighttpd
15715 root        1  44    0  3528K  1924K RUN      0:00  0.29% top
  11 root        1 171 ki31    0K    8K RUN    17.9H  0.00% idle: cpu0
  27 root        1 -68    -    0K    8K -      11:07  0.00% em2 taskq
  28 root        1 -68    -    0K    8K -        3:57  0.00% em3 taskq
  13 root        1 -32    -    0K    8K WAIT    3:40  0.00% swi4: clock sio
  23 root        1  8    -    0K    8K -        3:11  0.00% thread taskq
  15 root        1  44    -    0K    8K RUN      3:03  0.00% yarrow