I did a manual update last night.

This morning I tried to do the auto update via webUI and it stalled again at 49%!

When the download stalls, nothing works on the the webUI, even after I restart the webUI (from SSH). But all the other network functions seems still working normally. To be able to access the webUI again, I can only think of a reboot. :-[

Thank you for your reply..

Keep up the good work, we all appreciate it!

No easily. And there may not be enough of the right data to do what you ask.

The way rrd files work at certain intervals the data is consolidated into larger and larger averages, so unless the rrd is actually keeping the small interval data for the entire time period (unlikely give the size of the files) then you probably can't get it what you're after.

Though if you want to try, look in /usr/local/www/status_rrd_graph_img.php

Would have been easier to look in /tmp/rules.debug to see the actual order of the rules :-)

Should be OK on current code. I pushed a fix for that on Saturday.

@mdima:

more than awesome… that would be legen...wait for it...dary... legendary!

Haha!  :D
It would be good though.

Steve

hope config is better than a screeshot …

[2.0-RC3][root@vpn01]/root(1): cat /var/etc/openvpn/client1.conf dev ovpnc1 dev-type tap dev-node /dev/tap1 writepid /var/run/openvpn_client1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher AES-128-CBC up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 192.168.4.252 engine cryptodev tls-client client lport 1194 management /var/etc/openvpn/client1.sock unix remote vpngw 1194 ca /var/etc/openvpn/client1.ca cert /var/etc/openvpn/client1.cert key /var/etc/openvpn/client1.key comp-lzo resolv-retry infinite

I muste create the bridge manual after every restart, with

ifconfig bridge0 addm ovpnc1

Nobody will fix it for me :(

you need more, tell me. only remote access is not possible ::)

No.

If you have the i386 version installed, make graphs, and then change to the amd64 version, your graph data becomes unusable.

If you have the amd64 version installed, make graphs, and then change to the i386 version, your graph data becomes unusable.

If you only ever have the i386 version in use, the graph data would be OK.

If you only ever have the amd64 version in use, the graph data would be OK.

(And it's still not relevant to this thread)

had same 'error' I think the problem is you have same IP twice (both mac's have same IP)? You can check it with arping.

I too just experienced this… Except the cpu stays at 100%.  Top shows dhcpd taking all the cpu.. I'm also running on esxi and using pfsense built 2.0-RC2 (i386)
built on Thu Jun 2 04:01:18 EDT 2011.

Edit:  I restarted the dhcpd service and it corrected the problem. We'll see if it happens again...

First, you are not on latest snapshot.
Second, in latest snapshot you do not need the nat rules since localhost net is included in auto generated nat rules.
Third, it should only need localhost as interface on squid selected. Not sure why some declare it does not work like that since i have not checked the package.

tuaris, a mix dns would be a PIA, but fruitful…however, i am running internal DNS with reflection/NAT on many websites, mail servers, etc. i have yet to run into a problem with RC3.

i only allow dns through my dmz and all is grand. reverse lookups havent had a problem.

ofcourse i have more than one static (200+ statics at the moment) ...but i still havent run into a problem you might be worrying aboot.

also, the hardware i am running is prehistoric compared to the hosting environment..and it runs like a top.

i replaced TWO paloalto 5500's with pfSense (not load balanced, but failover setup) ...and not only do i have LESS work to do compared to the paloalto's ...i have better performance on VPN, email, and www.  ...so...i was a skeptic at first, but i have quickly become a big ol fan of pfSense.

Sounds like a plan if you have the hardware & time to try. :)  And yeah hard to say if some stray setting is in there from previous versions.
Bill

This issue has been a problem for me as of late. It may have been there when I upgraded to RC3 but only until recently have I noticed it.

I'm set for DHCP from my ISP with no MAC spoofing and every couple of days I'll randomly just get a DHCP failure on my boxes and my WAN connectivity drops out. I've had to release/renew to regain connectivity. I looked into the logs and I have an "apinger" entry that occurs around the same time as the DHCP trouble on my LAN. I failed to check tonight but typically this leads to a 169 IP (before the release/renew).

Aug 21 00:20:05 apinger: alarm canceled: WAN(x.x.x.x) *** down *** Aug 21 00:14:41 check_reload_status: Reloading filter Aug 21 00:14:31 apinger: ALARM: WAN(x.x.x.x) *** down *** Aug 20 21:49:55 dhclient: Creating resolv.conf

FWIW, I saw another post mentioning the apinger issue and he was using the same modem that I am which is an SB6120. Perhaps there is an issue with this modem and pfSense? I can tell you that with this modem downstreams are bonded together for improved bandwidth. I'm not sure if that could be something of concern but I thought I would mention it.

Here is the post I was referring to…
http://forum.pfsense.org/index.php/topic,39205.msg202106.html#msg202106

Thank you, Thank you, Thank you all!

I did have to go back in to the serial interface and assign my IP to my LAN one last time but everything is working now even through a reboot…

I could figure out how an interface without DHCP assigned could be the VR for my LAN and reassigning my LAN away could be correct but with all of your encouragement it seems to be working!

Thanks again! Wallabybob and Jameson, thanks for sharing your knowledge and time!

It is different and not interchangeable, you'll either have no data until you're back on amd64, or you'll have to delete all your data and have it recreate it (and do the same once you're back on amd64).

Created a work around:
Since the SNMP data was requested by an external webserver, it is also possible to get some webpage info through this php webserver.

Created to following script on pfSense /usr/local/www/dhcpDump.php

$dhcpFile = file_Get_contents('/var/dhcpd/var/db/dhcpd.leases'); echo nl2br($dhcpFile); ?>

Then created a NAT rule for only my webserver's IP address to access the pfSense portal. (E.g. https://pfsenseAddress:7000/dhcpDump.php)

Got in this dump a lot of usefull info to work with.
Hope it helps others as well.

Best regards,
Tim

I reordered my interfaces in config.xml and it's still the last interface (now em0_vlan208) that's seeing the pause, so it apparently has nothing to do with any specific interface.

Tried with latest snapshot, 8/19 and when i clone wan mac address with dhcp client, the link goes up/down still.