Thanks for http://redmine.pfsense.org/projects/pfsense-tools/repository/revisions/9ef97a5994abb78061277f4f29d2067b7b833a9d But this commit is not applyed for amd64 (i tested). I don't understand why. Snapshots: pfSense-Full-Update-2.0-RC1-amd64-20110318-2213.tgz pfSense-Full-Update-2.0-RC1-amd64-20110320-0505.tgz Included yandex drivers. Edit: I understood why - http://redmine.pfsense.org/projects/pfsense-tools/repository/revisions/f7a0d0d634b787fede5b54ec26c625423c12b624/diff/builder_scripts/patches.RELENG_8_1

If you type: dmesg | grep -i hifn Should show you that the device has been loaded successfully.  Or if you are running 2.0 BETA, I think it shows on the dashboard. ;)

@Atlanta-Mike: I can't get the boot.  Has anyone got 2.0 to run on an AMD chip?  What about as a VM in Xenserver? I'm running 2.0-RC1-amd64 snapshot built 3/18/2011 on AMD chip.  Specifically, inside VMware Player 3.1.3 on Windows 7 x64 using AMD Phenom II X3 720 CPU. Seems to be running fine, except: 1. "watchdog timeout" messages spamming console (known issue with em0) 2. updating erases this line inside /etc/sysctl.conf:  kern.timecounter.hardware=i8254 Both issues are already known at: http://redmine.pfsense.org/projects/pfsense-tools/issues?set_filter=1&tracker_id=1

After an update to the todays version everything works fine again…

thank you for your answer. i have to configure the wlan as ad hoc ? access point ? i juste forget to tell that i want to use a hotspot with login/passeword. i have to connect to the open hotspot and then enter the login and the password. i will have to do that on the pc at the first login ??? not possible that the router does that ? Thank you.

Did I miss your question? ^^

OK, Thanks ermal. I will make the posts to redmine as you suggest. About point 1…. I don't even get any details of the users that logged in with passwords! Maybe the fact that "some" users are passing-through stops the status from working even for the password authenticated users. In any event, one would have thought the point of this status page would be to show the status of any users passing through the captive portal (regardless of how they authenticate- by password or pre-approved mac)... If anyone else can confirm that the status page is blank with version 2.rc1, then I will post it as a possible bug?

@Nachtfalke: I have got a similar problem with high MBUF usage on AMD64 snapshot. You haven't demonstrated a problem. NIC drivers allocate mbufs to hold received frames from the NICs. Depending on the NIC driver it is possible that the receive frame allocation might be replicated per CPU, per VLAN, … I suggest you only have a problem if the mbufs in use count grows "rapidly" and in a sustained way. After a few days of "typical" use the counts of mbufs in use shouldn't normally change much.

@David: I got the same thing recently, and had to switch both ends back to Main mode, restart IPsec, and switch back (I think, tried a lot of stuff). Finally it works, but the errors are still there. I had the same exact problem and your suggestion fixed my tunnels as well.  Gracias!

@wallabybob: I'm not familiar with multiple gateways but your two WAN interfaces and gateways are all in the same subnet hence either interface can be used.  Imagine you are pinging gateway 2. Then since its on the same subnet as WAN1 the ping can be sent over WAN1 which won't help if WAN1 has no connectivity to gateway2 except through WAN2. I suspect you need a rather longer network mask on WAN1 and WAN2. Seems to have fixed my issue ;D I've been trying to figure this out on and off for a week, total "doh!" moment when I resolved it. @dave99: Not that is really applies to your problem, but you might really want to reconsider using pfsense (or any firewall) in vmware server, especially version 1. vmware isn't too my knowledge updating that product anymore, plus you have potential security issues from the host OS as well. You really want to stick to the bare metal hypervisors (esxi, xenserver etc) for this kind of thing. Makes sense, I'm not too familiar with virtualization so I just wanted something simple to get my feet wet. I'll look into it for my final configuration of this network. Thanks again for the help!

Yes, the DSL connections use PPPoE. BTW - just realised the last message could be understood as a sarcastic message. That was NOT the intention! I am truly grateful for the help here! Both connections use the same gateway, so I guess I could also use that as a test, the logic being - if a modem fails the gateway will not be reached. If the gateway fails, both lines will fail no matter what. I will ask if it is possible to connect through a different gateway for one of the modems. It is in the middle of a city. But I don't know if there are options and how willing the ISP is to help.

I was hoping someone could tell me if they are experiancing the problem or maybe someone could shed some light on the issue. Thoughts?

I have always had the same problem as well.  From what I could find, its only a problem on amd64 servers.  I'm guessing thats what you have.

Ok, still trying to figure out what I am doing wrong here… Or, I added a OPT1 to my wifi card, named it WiFi, set it to AP, it is to static,  gave it the IP of 192.168.1.5. Went into DHCP server and enabled it on WiFi with a range of 192.168.1.176 to 192.168.1.199 (LAN is 192.168.1.100 through 192.168.1.175). Still can't get an address, what am I forgetting, and if it some rule, please note the syntax? THanks,

I'm getting same error (STOP at 45%), when trying to do fresh install pfSense on KVM VirtualMachine, both amd64 & i386 versions, CPU in host is AMD 550 Phenom II X2. Host information: AMD Phenom II X2 550 @ 3,1 GHz, DDR3@1600 QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5) 2.6.32-5-amd64 Tried with different Storage types for VM (SCSI, IDE, VIRTIO), different architectures (i686/amd64), KVM and QEMU emulators, checked: pfSense-2.0-RC1-amd64-20110317-0820.iso pfSense-2.0-RC1-i386-20110316-1024.iso pfSense-2.0-RC1-i386-20110316-1637.iso pfSense-2.0-RC1-i386-20110317-0727.iso some screens attached… [image: pfSenseRC1_screen3.png] [image: pfSenseRC1_screen3.png_thumb] [image: pfSense20rc1_screen1.png] [image: pfSense20rc1_screen1.png_thumb] [image: pfSenseRC1_screen2.png] [image: pfSenseRC1_screen2.png_thumb]

So it looks like HAVP was the culprit.  Once I disabled it, the download worked correctly. Not sure why it was causing so much chaos.

kern.ipc.nmbclusters="131072" Thanks, I put this setting in the "system->advanced->system tunables", now the netstat -m shows 131072 as max value… Anyway, hope this problem will be solved, because from what I understood, if there's a buffer leak problem every value you set will be reached sooner or later...

Ok, there was no way for me to repair this installation… So I reinstalled pfSense, restored the configuration, reapply the update that caused the error (2.0 RC1 Thu Mar 17 07:55:22 EDT 2011), and after the reboot everything was ok now... I really don't know what went wrong during the first upgrade, for sure I was just upgrading using the web interface, so it's an "idiot-proof" process... Now my firewall has been restored and it's working...

You have to do that on the interfaces->assign->ppp page now not directly on the interfaces->WanX page. The later will change the ethernet interface mtu and not the pppoe established mtu.