I don't have any 64bit systems at the moment to confirm this, but if that is repeatable on the latest snapshots, open a ticket here:

http://redmine.pfsense.org/

Hi all

THANKS!! The latest Snapshot 20100331 work again with pppoE

GREAT JOB!

Peter

It should be saner on latest snaps.

@cmb:

No, you don't have to do anything, it pulls the package list automatically.

noted with thanks. Just check the package again and found the squid has added on the list.

Thanks & regards.

ral update:

I have further investigated the ral problem and found that ral wasn't interrupting, even when in infrastructure mode. Close inspection showed the PCI card wasn't seated evenly in the PCI socket; the edge closer to the back panel protruded a little more than the edge further from the back panel. So I evened out it and rebooted and the system did not crash on clicking Apply all changes in any of the three modes: ad-hoc, access point or Infrastructure.

However when the NIC was configured in Infrastructure mode it repeatedly reported "device timout" and my netbook saw no evidence of a signal corresponding to the ssid I had configured.  I saw a problem report about this ( http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/117655 ) but I thought the explanation was unconvincing. I'm using a 90W PicoPS and a 48W switch mode PS (12V @ 4A) so I suppose the surge current capability of this is a fair bit lower than that of a more standard computer power supply. I can get a pretty cheap card with a more recent ral chip (rt2561) so I might get that to try out.

hi,

max_attempts and timeout may work for you

-OR-

add this in your pf rules(or modify filter.inc 'cos reload wipes this rule).

pass in on $ext_if proto tcp from any to ($ext_if) port ssh flags S/SA keep state (max-src-conn-rate 3/10, overload <ssh-bruteforce>flush global)

this rule really does good rate control but once host got banned, won't be removed from the table.

cheers,</ssh-bruteforce>

The standard answer is: when it's ready.

Just be patient :)

It's shaping up nicely, and coming along at a reasonable pace. There is still quite a lot of work to do, however.

I also have these kinds of lines in my log, don't know when it started….last weekend I made some scheduled tasks:

Mar 30 20:33:09 php: : The command '/sbin/pfctl -y 4bad31bfd9cf7' returned exit code '1', the output was 'pfctl: DIOCKILLSCHEDULE: Permission denied'

Can I provide more info to research this further for the dev team?

ALIX: pfSense-2.0-BETA1-1g-20100329-2138-nanobsd

thank you dusan!
I will download the last snap, and try it! if the last snap is fix it, I will reply in here!

@__Fox__:

hi,
for inbound LB and failover, the problem with 1.2.3 was resolved?
I mean this:
http://forum.pfsense.org/index.php/topic,21991.0.html
http://forum.pfsense.org/index.php/topic,23466.0.html

The second link isn't actually a problem, some sort of config issue there or something. The first is a known issue, I posted info there. Whether that changed depends on whether that behavior changed in FreeBSD 8. I haven't yet tried it so not sure.

Not my original post, but I have the same symtoms. Confirming resolution: disabling NAT-T makes errors go away and packets flow thru the tunnel.

Edit: Running 2010-03-24 snapshot, fresh install

Please check with latest snaps.

@keylevel:

One of them was configured as an AP.

And the other interface is configured in Infrastructure mode?

If so, how about configuring both wireless interfaces as Infrastructure to see what happens? This will be at least a little bit inconvenient if the system is crashing on startup. You will probably have to temporarily remove one of the wireless NICs, the startup will notice the configuration is different and will prompt you on the console to re-identify the LAN and WAN interfaces and you can leave the wireless interfaces unassigned. Then you could shutdown and reinstall the wireless interface and reboot.

A weeks ago I was looking into a crash on startup or enabling a wireless interface. It was quite annoying because the crash would usually cause a file system problem and corrupt the configuration file. But that was with the "full" version of pfSense. I hope the nanobsd version is more robust.

Dear Development team,

I would like to ask if there is any progress on the NUT package. I really really like the package :-).
I still try it once a week to see if it has changed and maybe working. But up to now i have no luck.

I you need help testing i would be glad to help.

I noticed this to with an snapshot of a couple of weeks old. It usually resets the /etc/hosts when a new entry should be added by the DHCP server.
Im currently running a snapshot built on Wed Mar 24 10:33:05 EDT 2010 and don't have any problems anymore.

Confirmed on Mar 26 01:13:43 snapshot. The bug was fixed.

Many thanks.

Thank you very much for the explanation! - it is most appreciated.
… and I think this way is great!

I tried again: Installing 20100324-0246, upgrading to 20100324-2048 from console.
Following the steps of the original post.

After activating the bridge and setting LAN to "none", I get:

netstat -rn Destination        Gateway            Flags    Refs      Use  Netif Expire default            87.52.xx.1        UGS        0      15    vr0 87.52.xx.0/24      link#1            U          0      708    vr0 87.52.xx.120      link#1            UHS        0        0    lo0 127.0.0.1          link#12            UH          0    1127    lo0 127.0.0.2          127.0.0.1          UHS        0        0    lo0 192.168.yy.254    link#13            UHS        0        0    lo0

(plus a lot of IPv6; xx and yy are my sanitizing).
Link#1 is the LAN, #12 is lo0 and #13 is the bridge.

After reboot I get:

Destination        Gateway            Flags    Refs      Use  Netif Expire default            87.52.xx.1        UGS        0      47    vr0 87.52.xx.0/24      link#1            U          0      137    vr0 87.52.xx.120      link#1            UHS        0        0    lo0 127.0.0.1          link#12            UH          0      19    lo0 127.0.0.2          127.0.0.1          UHS        0        0    lo0 192.168.yy.0/24    link#13            U          0        1 bridge 192.168.yy.254    link#13            UHS        0        0    lo0

But this time, I get no working GUI even after reboot  :o

I think I spoke too soon, I tried a new snapshot on Monday, and as of today from light testing the wired memory usage has grown to 57M.

2.0-BETA1 Built on Sun Mar 21 02:30:16 EDT 2010
FreeBSD 8.0-Stable
nanobsd

Can anyone point me to where I can find more info about what causes this problem?
Thanks
Josh