I see this error message also on my multiwan setup. I have 2 ADSL modems hooked up, one in bridge one in routed mode (same ISP, same network otherwise).

Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            88.115.128.1      UGS        0  7966945    em0
88.115.128.0/20    link#4            U          0        0    em0
88.115.135.211    link#4            UHS        0        0    lo0
127.0.0.1          link#6            UH          0      567    lo0
192.168.1.0/24    link#1            U          0  9068001  bge0
192.168.1.1        link#1            UHS        0        0    lo0
192.168.100.0/24  link#5            U          0        0    re0
192.168.100.1      00:14:d1:38:7e:34  UHS        0      148    re0
192.168.100.30    link#5            UHS        0        0    lo0
193.229.0.40      00:1b:21:0a:aa:ac  UHS        0      89    em0
193.229.0.42      00:1b:21:0a:aa:ac  UHS        0      63    em0
193.229.0.46      88.115.128.1      UGHS        0  204358    em0
193.229.9.190      192.168.100.1      UGHS        0  205264    re0

dmesg:

arpresolve: can't allocate llinfo for 192.168.100.1
arpresolve: can't allocate llinfo for 192.168.100.1
arpresolve: can't allocate llinfo for 192.168.100.1
arpresolve: can't allocate llinfo for 192.168.100.1

I am not using PPoE or anything fancy like that, I have DHCP enabled on both WAN interfaces.

Let me know if you need any other info

Can you try with the latest snapshot that will come out and see if it works:

Just enable AON and put any as source on rules Create a floating rule with direction out, quick selected, and the load balance pool

I'll do it tomorrow but size limits are rather strict one the forum…

ah, thanks.

Anyone?  What do I need to do in order to bridge the two networks?

No of the tutorials I can find work.

I happen to be one of those guys who favors clean installs whenever possible (too many years using Windows, I guess…), so doing that on so important a piece of equipment as a router is no big deal - I was just curious about other user's upgrade stories.

As to the config files, yeah, I should've saved those... I'll do that next time, and report back.

I remember though that one of those upgrades (a MultiWAN setup on an old Intel 845 mobo, with 512MB RAM and Intel, SiS and Realtek NIC's - yes, I'm that brave! :D) ended in a loop assigning interfaces - meaning, the "assign interfaces" console routine kicked up after the upgrade, but no matter how many times I did the (re)assignment, it always cycled back to the same screen; unfortunately, I had some urgency in restoring Internet access, so I just reinstalled on top of the botched upgrade (using version 2.0b5, and manually recreating the configuration) - it's been working flawlessly ever since.

Thanks - for the reply, and for giving us pfSense!

Marcello

That error is likely from removing and reinstalling snort. If the package upgrade worked as expected, it would probably be fine. But since snort doesn't install cleanly, it bombs.

Once the maintainer of the snort package fixes the problems there, it the errors will probably stop.

I've only seen those errors when there is no data in vnstat db after an install and the browser cache stores those old data (F5 for refresh). More likely is that packages do get reinstall after every boot and in that period you mention there has been some problems with the package installation process + I also update the vnstat2 package.

If vnstati also reports errors I would remove the package, delete /cf/conf/vnstat (Database dir) and reinstall.

Done, thanks.

it is
2.0-BETA5 (i386)
built on Fri Feb 4 15:47:28 EST 2011  snapshot today im wil upgrade to latest version and try again

Hi,

sorry for wasting your time. Don't know why this appeared yesterday on my screen. I did copy and paste. Perhaps a problem with my browser or something else. Today there aren't any "mistakes".  ???

Sorry for that.

Agreed Phobia.  I too am a developer of more years than I care to mention so I can sympathize.  Patients was the reason I let the system go for so many hours before finally taking a chance and rebooting both units.

Happy to see they got it taken care of and hope it was my post that brought it to their initial attention.

.80 amd64 installed successfully.  still seem unable to stack AES-256 for both phases though.  any thoughts?

kewl

downloading latest snapshot now…

Sweet! Thanks for letting me know.

If your machine was stuck at the console at a db> prompt, it didn't do a crash dump that can be submitted.

There is a false positive in the crash dump detection in the GUI on this morning's snapshot, so it probably didn't really have any info to submit.

When a proper crash dump has been done, it will show all of the info in the text box before submitting, and it will be enough to submit that info as-is.