Good to know they're fixed. :-)

Sorry, false alarm. Problem was caused by braindead switches which forgot that they had been interconnected with two bonded LACP links, causing a Layer 2 loop.

M.

Thanks, this would explain it (and some other problems). The issue went away after rebooting the switches. Guess they forgot they had eben configured with LACP somehow.

Apologies for the false alarm.

Cheers,

M.

The old snapshots are just deleted, they aren't archived. In most cases, the most current is the best to use. If something is broken in a current snapshot, then work with developers (on the forum, via tickets, etc) to get it fixed instead of moving backward.

this should work:

http://redmine.pfsense.org/projects/pfsense/activity

thank you man.

Thanks, working perfectly  :)

Are by any chance trying to open a https site and expect to be redirected?

Alrighty, tested with the Linksys router, set it up behind current router, made it's private net 10.44.55.x, was able to ping out from behind it successfully, so it IS definitely something within the pf box preventing the clients from getting out…..

-Andy

Andrew Miffleton
Telecommunications Technician
DFW Business Telephones, Inc.
1260 Shiloh Rd
Plano, TX 75074
(972) 424-4242
http://www.dfwbt.com

The bug with Squid 2.7.9_4 (not 3.0) appears to have been squashed.

Running latest i386 Pfsense build December 21 no problems.  ;D

Hi,

thanks, that worked. Problem evaporated  ;)

cu

Martin

@shadow:

for the record, it appears the run driver doesn't work reliably yet anyway. I can associate but IP traffic is broken, looks similar to kern/132722.

I'll be collecting more info and reporting it.

2 bugs. One in ehci:
http://lists.freebsd.org/pipermail/freebsd-current/2010-October/020504.html
and one in the 802.11a support (at least)
http://gitorious.org/run/run/commits/P4_ratectl_fix

@ermal:

Please try the latest version of snapshots it should be fixed.
Jim was right that the code was 'too good' and was removing even present members of the lagg.

It's a step in the right direction; but there's a new problem now.

I was able to successfully add two nics to an already configured lagg (bringing the total to 4 nics). (see lagg_edit_error_5.JPG)

But if i try to edit anything on this lagg or even delete it, pfSense reboots with the following message at the console (see lagg_edit_error_4.JPG).

Cannot dump. Device not defines or unavailable.
Automatic reboot in 15 seconds - press a key on the console to abort

A dmesg at the console show the interfaces and so does an ifconfig. (see lagg_edit_error_6.JPG)

If i do hit a key at the console, this is what show's up (see lagg_edit_error_7.JPG).

lagg_edit_error_4.JPG
lagg_edit_error_4.JPG_thumb
lagg_edit_error_5.JPG
lagg_edit_error_5.JPG_thumb
lagg_edit_error_6.JPG
lagg_edit_error_6.JPG_thumb
lagg_edit_error_7.JPG
lagg_edit_error_7.JPG_thumb

@wagonza Yes, this is in /etc/rc

if [ "$PLATFORM" = "nanobsd" ]; then
…skipping...

if [ /bin/ls -la /etc/gettytab | /usr/bin/awk '{ print $5'} -lt 512 ]; then
        echo ">>> Restoring /etc/gettytab due to unusal size"
        echo ">>> Restoring /etc/gettytab due to unusal size" | /usr/bin/logger
        /bin/cp /etc/gettytab.bak /etc/gettytab
fi

@ jimp, thanks, it's fixed already now, and my 3G problems went away mysteriously at the same time :)
Lets get that gettytab.bak file on NanoBSD builds. Looks like GeekGod meant for it to be there.

Its normal in most of the cases.
Its not ok if it does not start anymore :)

@mrguitar:

I'm kind-of hoping someone w/ an alix and a PPPoE dls line can try to recreate the problem.

Many, many others including myself would have seen it if it were that simple.

If the Ubuntu version is like FreeBSD, after any update to VirtualBox it also updates the Kernel module, which you have to unload and then reload the updated version, or reboot and load the updated version. Perhaps something similar is happening to you.

I run a couple pfSense test VMs on my VirtualBox install on FreeBSD and they work fine

Should be fixed on latest snapshots.