Ok, fixed now!tx!

8/30 2GB update worked perfectly.

@orangepeelbeef:

Durrrr… there is a page 2.  Sorry.   I read somewhere the nopacket thing was put into future images, is that not the case?  With the nopacket change will it work on WRAP or still no?

Read the rest of my post here:
http://forum.pfsense.org/index.php/topic,18302.msg94911.html#msg94911
The gist of it is:
ALIX needs packet mode to work on slice #1 and slice #2.
WRAP needs nopacket, and even then only works on slice #1.

So the images can't be set to nopacket, or it breaks updates on ALIX, and it can't be set to packet and work on WRAP.

cmb/sullrich are working with PC engines to see if a BIOS update can be made for the WRAP which will resolve this, otherwise I'm not sure what will happen.

This turned out to be a bug in the m0n0wall config conversion code. If someone runs into it in the future, backup the config and replace:

<diag>with:

<diag><ipv6nat></ipv6nat></diag>

save your changes and restore. It'll be fixed in the next few days for future converted configurations.</diag>

Sorry, is it FreeBSD limitation? is anybody working on this?
Thanks.

I think (but don't quote me on this) that it means it went down/up (or up/down) very quickly, so it didn't log the down and the up, just that the link is the same as it was before, but there was a change.

Check the CPU usage.  Mine is running at 100% now with the latest snapshot.  Hmm..

Guess I will have to see what app is doing it.

You have an carp loop.
Remove the ip addressen by the peer options on the slave machine.

Exactly. This topic is about the gre limitation. And ofcourse possible solutions.
As there is no solution right now, m setting up IPSec for my inbound client because won't be limited by gre.

Anyways I hope this gre issue is to be solved asap

cheers,
Leon

Great. Thanks!

Just took another look at the graphs again.  I'm absolutely certain that the graph is not even charting any of the LAN queues properly.
The alleged qGamesDown queue in the graph is simply a graph of all downstream traffic.

It depends on what you set for the remote network on the tap interface. By trial and error I found one that doesn't seem to cause interference with the part of the Internet that I use.

If the Avahi package worked on nanobsd, I don't think bridging would be needed. But it doesn't.

Is this not possible/risky to do?

Reda: what you're hitting, it sounds like, is an odd FreeBSD bug with missing ICMP replies. It appears we have a work around switching from slbd to a custom patched apinger. Try a 1.2.3 snapshot from http://snapshots.pfsense.org and report back.

Try to reflash from scratch, then attempt another update when a new snapshot is available.  I've been having 100% success applying the nanobsd updates manually to my 2GB card.

ok thx

thx 4 tip. width new bios 1.2.3 rc1 works
i will try nano after i test rc1.
so 1.2.3 final will be separate versions or just nano version?