Interestingly, just b4 I left for work this AM, I accidentally unplugged the box and when it came back up, it was broken this way.  I can confirm several dynamic hosts have DHCP'ed and no entries.  /var/etc/hosts looks fine except for no entries that should be there.  Usually, I can "fix" it by turning off that option and back on.  I just did that - will see if it works again.

@jimp: "Dummy" packages would cause more confusion than anything else, especially in your case since Varnish has not been removed – it is just not available on x86. Listing it on x86 would lead to people trying to install the "dummy" package. Packages which are removed from the repo still show up under the installed packages list, and if they can't be removed from there, that is the real bug. Ok, the suggestion with dummy packages I only made because I though the problem to be a different one than it is. I thought the problem exists because the packages was removed, but in reality the problem is, that the restore of an amd64 config into an i386 system plays tricks with the system that it shouldn't play… So yes, the dummy package idea would be worthless to solve the issue at hand. What needs to be solved then is how the system deals with config data from restored configurations that was written with currently unavailable packages present. @jimp: As for multiple services, it's just that they get added multiple times if a package isn't completely removed cleanly. If that's the case I have an idea where this may originate, it's related to something that should be improved anyhow: when one upgrades the OS, all packages are deinstalled and then reinstalled. That's OK, even though it takes up a lot of time,which could be saved if the OS could be upgraded independently from the packages. What is a real nuissance, however, is that one can't start the upgrade and walk away, because then only the OS is upgraded, the package upgrade only happens the next time one accesses the web interface. Worse, if this is done with a mobile device that goes to sleep, while the package manager page may be busy for 10-30 minutes downloading and reinstalling packages, then it seems the install of various packages may fail, and create theirs double entries. IMO the package reinstallation should happen fully in the background and not require web interface access or a continuous connection to the browser while it is unfolding. @jimp: As for fixing your situation, you'll need to download a config backup, edit out the package info, and restore the backup. Welcome to BETA software. :-) OK I'll try to get rid of varnish that way… @jimp: It will be improved before release, as always, but there are still rough edges. No problem, I'm aware of the beta status. With some feedback from the forum, I can likely resolve the problems and help track down a few bugs in the process…

thank you , i try "0601 2153" now  :) the 201006012153 iso is ok !! very happy  ;) thanks very much

I finally tested my CF that is working with 1.2.2 and it works with 2.0, but unfortunately I had problem configuring everything, like IPSec, Traffic Shaper and I don't have the patience tonight to look at it. So I flashed back my backup image I took and I'm back to my rock solid 1.2.2 I'll try to get my hands on a new CF to have to CF to play with… MageMinds

@hellsacolyte: I also experience that issue with the traffic shaper, along with enabling device polling with compatible network cards causes CPU to sit at 100% constantly. Polling uses 100% CPU. That's how polling works (uses normally idle CPU time to look for data on network interfaces), and isn't related to this other issue.

The ISOs from the last few days have not been building properly, but to my knowledge this is the first time this particular issue has happened.

This should be fixed now. I just committed an update to correct the cache_dir line when null is selected. I didn't bump the version number though. Just reinstall the pkg and it should be fine.

@mediadaemon: I've done this using wget, I use the data from ifstats.php to determine if the network is idle before starting automated large downloads (remote backups) Just modify the last three wget's with the location of the rrds you want. #!/bin/bash wget -qO/dev/null --keep-session-cookies --save-cookies /tmp/cookies.txt --post-data 'login=Login&passwordfld=YOURPASSWORD&usernamefld=admin' http://172.16.10.1/index.php wget -qO- --keep-session-cookies --load-cookies /tmp/cookies.txt http://172.16.10.1/ifstats.php?if=wan wget -qO- --keep-session-cookies --load-cookies /tmp/cookies.txt http://172.16.10.1/ifstats.php?if=lan wget -qO- --keep-session-cookies --load-cookies /tmp/cookies.txt http://172.16.10.1/ifstats.php?if=opt1 I added a variation of this method here: http://doc.pfsense.org/index.php/Remote_Config_Backup Thanks for the info.

That hasn't yet been dealt with, but there is a ticket open. It will probably involve sudo, or adding admin users to the wheel group. Due to the way things have to be in order to let the system work, every ssh user should essentially be considered to have root access anyhow. It's not exactly meant to be a full multi-user system. :) http://redmine.pfsense.org/issues/614

Anything from April is not recent, there have probably been 400-500 changes since then. There was an input validation bug a while back on dynamic gateways, which sounds like what you're seeing. Upgrade.

yes

same problem on the nanoBSD image from 25 May.

@mxx: Can't say anything about those previous snapshots, but 20100529-1730 is booting fine on my machine. Glad I didn't update for a while and might have jumped over ;) Don't know anything about stability yet though Edit: This build is very unstable for me. After some time there are connectivity issues and the machine even reboots/resets itself from time to time :( I tried that build and it has the same problem on all machines tested .

DynDNS's default TTL for their Dynamic DNS service is 60 seconds and it can go down to 20 seconds.  Propagation through any well behaved DNS server isn't an issue (there is an issue with all the badly behaved DNS servers that ignore the TTL though).

Thanks a lot for your help!

There are indeed parallels in these symptoms. Thats's why it's beta (as said in the linked thread inside the bugreport  ;) ) Just wanted to mention my experience as for example the stunnel package is just listed "?" in the sticky 'packages' topic… Thanks so far, i'll install it manually then.

Hi, I got the same problem after adding the shaper and reboot. May 30 13:12:49 kernel: IPsec: Initialized Security Association Processing. May 30 13:12:49 kernel: usbus0: 12Mbps Full Speed USB v1.0 May 30 13:12:49 kernel: acd0: CDROM <cd-224e 2.9b="">at ata0-master UDMA33 May 30 13:12:49 kernel: ugen0.1: <(0x1166)> at usbus0 May 30 13:12:49 kernel: uhub0: <(0x1166) OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0 May 30 13:12:49 kernel: ips0: adapter type: ServeRAID 6M (marco) May 30 13:12:49 kernel: ips0: logical drives: 1 May 30 13:12:49 kernel: ips0: Logical Drive 0: RAID1 sectors: 71096320, state OK May 30 13:12:49 kernel: ipsd0: <logical drive="">on ips0 May 30 13:12:49 kernel: ipsd0: Logical Drive (34715MB) May 30 13:12:49 kernel: SMP: AP CPU #3 Launched! May 30 13:12:49 kernel: SMP: AP CPU #1 Launched! May 30 13:12:49 kernel: SMP: AP CPU #2 Launched! May 30 13:12:49 kernel: uhub0: 4 ports with 4 removable, self powered May 30 13:12:49 kernel: Trying to mount root from ufs:/dev/ipsd0s1a May 30 13:12:50 php: : MONITOR: GW_AON has high latency, removing from routing group May 30 13:12:50 kernel: pflog0: promiscuous mode enabled May 30 13:12:50 php: : MONITOR: GW_SpeedT has high latency, removing from routing group May 30 13:12:50 php: : MONITOR: GW_UPC_PPPOE has high latency, removing from routing group May 30 13:12:50 php: : All gateways are unavailable, proceeding with configured XML settings! May 30 13:12:50 kernel: em0: link state changed to UP May 30 13:12:50 php: : The command '/sbin/route delete -host '62.99.170.113'' returned exit code '1', the output was 'route: writing to routing socket: No such process delete host 62.99.170.113: not in table' May 30 13:12:50 kernel: em1: link state changed to UP May 30 13:12:50 php: : Removing static route for monitor 62.99.170.113 and adding a new route through <wan_gwip>May 30 13:12:50 php: : The command '/sbin/route delete -host '195.3.68.49'' returned exit code '1', the output was 'route: writing to routing socket: No such process delete host 195.3.68.49: not in table' May 30 13:12:50 php: : Removing static route for monitor 195.3.68.49 and adding a new route through <wan2_gwip>May 30 13:12:50 php: : The command '/sbin/route delete -host '213.46.173.61'' returned exit code '1', the output was 'route: writing to routing socket: No such process delete host 213.46.173.61: not in table' May 30 13:12:50 php: : Removing static route for monitor 213.46.173.61 and adding a new route through 192.168.1.254 May 30 13:12:50 php: : The command '/sbin/route delete -host '213.46.160.253'' returned exit code '1', the output was 'route: writing to routing socket: No such process delete host 213.46.160.253: not in table' May 30 13:12:50 php: : Removing static route for monitor 213.46.160.253 and adding a new route through <dyn_wan_gw>May 30 13:12:50 apinger: Starting Alarm Pinger, apinger(20117) May 30 13:12:51 kernel: em2: link state changed to UP May 30 13:12:51 php: : ROUTING: add default route to 178.188.49.57 May 30 13:12:51 kernel: em3: link state changed to UP May 30 13:12:51 php: : Static Routes: Gateway IP could not be found for 10.8.0.0/24 May 30 13:12:51 dnsmasq[29995]: started, version 2.51 cachesize 10000 May 30 13:12:51 dnsmasq[29995]: compile time options: no-IPv6 GNU-getopt no-DBus I18N DHCP TFTP May 30 13:12:51 dnsmasq[29995]: reading /etc/resolv.conf May 30 13:12:51 dnsmasq[29995]: using nameserver 212.186.211.21#53 May 30 13:12:51 dnsmasq[29995]: using nameserver 195.34.133.21#53 May 30 13:12:51 dnsmasq[29995]: read /etc/hosts - 2 addresses May 30 13:12:52 sshd[44235]: Server listening on :: port 65002. May 30 13:12:52 sshd[44235]: Server listening on 0.0.0.0 port 65002. May 30 13:12:52 sshlockout[44411]: sshlockout starting up May 30 13:12:52 sshlockout[44411]: sshlockout starting up May 30 13:12:54 php: : MONITOR: GW_AON has high latency, removing from routing group May 30 13:12:54 php: : MONITOR: GW_SpeedT has high latency, removing from routing group May 30 13:12:54 php: : MONITOR: GW_UPC_PPPOE has high latency, removing from routing group May 30 13:12:54 php: : All gateways are unavailable, proceeding with configured XML settings! May 30 13:12:54 php: : The command '/usr/bin/nice -n20 /usr/local/bin/rrdtool update /var/db/rrd/opt1-queues.rrd -t :opt1:qInternet:qACK:qDefault:qP2P:qOthersHigh:qOthersLow N:U:U:U:U:U:U:U' returned exit code '1', the output was 'ERROR: unknown DS name ''' May 30 13:12:54 php: : The command '/usr/bin/nice -n20 /usr/local/bin/rrdtool update /var/db/rrd/opt1-queuedrops.rrd -t :opt1:qInternet:qACK:qDefault:qP2P:qOthersHigh:qOthersLow N:U:U:U:U:U:U:U' returned exit code '1', the output was 'ERROR: unknown DS name ''' May 30 13:12:54 php: : The command '/usr/bin/nice -n20 /usr/local/bin/rrdtool update /var/db/rrd/opt2-queues.rrd -t :opt2:qInternet:qACK:qDefault:qP2P:qOthersHigh:qOthersLow N:U:U:U:U:U:U:U' returned exit code '1', the output was 'ERROR: unknown DS name ''' May 30 13:12:54 php: : The command '/usr/bin/nice -n20 /usr/local/bin/rrdtool update /var/db/rrd/opt2-queuedrops.rrd -t :opt2:qInternet:qACK:qDefault:qP2P:qOthersHigh:qOthersLow N:U:U:U:U:U:U:U' returned exit code '1', the output was 'ERROR: unknown DS name ''' May 30 13:12:54 php: : The command '/usr/bin/nice -n20 /usr/local/bin/rrdtool update /var/db/rrd/opt3-queues.rrd -t :opt3:qInternet:qACK:qDefault:qP2P:qOthersHigh:qOthersLow N:U:U:U:U:U:U:U' returned exit code '1', the output was 'ERROR: unknown DS name ''' May 30 13:12:54 php: : The command '/usr/bin/nice -n20 /usr/local/bin/rrdtool update /var/db/rrd/opt3-queuedrops.rrd -t :opt3:qInternet:qACK:qDefault:qP2P:qOthersHigh:qOthersLow N:U:U:U:U:U:U:U' returned exit code '1', the output was 'ERROR: unknown DS name ''' May 30 13:12:54 php: : The command '/usr/bin/nice -n20 /usr/local/bin/rrdtool update /var/db/rrd/opt4-queues.rrd -t :opt4:qInternet:qACK:qDefault:qP2P:qOthersHigh:qOthersLow N:U:U:U:U:U:U:U' returned exit code '1', the output was 'ERROR: unknown DS name ''' May 30 13:12:54 php: : The command '/usr/bin/nice -n20 /usr/local/bin/rrdtool update /var/db/rrd/opt4-queuedrops.rrd -t :opt4:qInternet:qACK:qDefault:qP2P:qOthersHigh:qOthersLow N:U:U:U:U:U:U:U' returned exit code '1', the output was 'ERROR: unknown DS name ''' May 30 13:12:54 php: : Creating rrd update script May 30 13:12:54 php: : The command '/bin/pkill -f updaterrd.sh' returned exit code '1', the output was '' May 30 13:12:55 php: : Resyncing configuration for all packages. May 30 13:12:55 check_reload_status: check_reload_status is starting. May 30 13:12:55 check_reload_status: rc.newwanip starting May 30 13:12:55 check_reload_status: updating dyndns May 30 13:12:56 php: : rc.newwanip: Informational is starting .</dyn_wan_gw></wan2_gwip></wan_gwip></logical></cd-224e> Does anyone have any clue what might be wrong? Everything SEEMS to work though.. Thanks a lot! Max

Everything is working again (see below), but I figured I would include my configuration in case it stops working again. On the pfsense side: Server  mode: Remote Access SSL/TLS + User Auth Tunnel Network: 10.8.7.0/24 Local Network: 10.10.10.0/24 Advanced: engine cryptodev;route 10.4.2.0 255.255.255.0 vpn_gateway Client-Specific Overrides: iroute 10.4.2.0 255.255.255.0 On the client side: dev tun1 persist-tun persist-key proto udp nobind cipher AES-128-CBC tls-client client resolv-retry infinite remote xxxxxxx 1194 auth-user-pass up pkcs12 pfSense-udp-1194.p12 tls-auth pfSense-udp-1194-tls.key 1 comp-lzo Routes on pfsense server: Destination Gateway Flags Refs Use Mtu Netif Expire default x.x.x.x UGS 0 129136 1500 vr1 10.4.2.0/24 10.8.7.2 UGS 0 186 1500 ovpns1 10.8.7.0/24 10.8.7.2 UGS 0 168 1500 ovpns1 While I was copying/pasting the settings into this post, I thought to change the client-specific override to: iroute 10.4.2.0 255.255.255.0 vpn_gateway And guess what–it works again! PING 10.4.2.101 (10.4.2.101) 56(84) bytes of data. 64 bytes from 10.4.2.101: icmp_seq=1 ttl=62 time=31.6 ms So the take-home lesson for me seems to be that both the route and iroute commands require "vpn_gateway" after the subnet mask.