you're right, I've cleaned the cache and it works now. dumbe me for not thinginkg about that. And that's the first thing I suggest to customers with similar issues :) I need vacations :p

Cool, many thanks! Just upgraded to the lastest Snapshot and it works again.

Yes, i have a setup. Until now, 12 systems (6 playstation 3), 3 smartphones, 1 notebook, 2 tablets. All connected at same time.
The notebook and playstation 3 is using the "real" access point. WPA2/TKIP NG mode.
The tablets and smartphones is using the "virtual" access point using the captive portal. The use is for 10 hours / day and 4-5 gb traffic in things like torrents, psn, web browser, emails, voip (skype) and games. Is very much stable and with more days more devices will be connected.

your using snort-dev… please post in the correct topic http://forum.pfsense.org/index.php/topic,50416.15.html

I did expand the Lan and then hit the wrench which showed update time and had a save settings button there.. I hit that and it refreshed then and only wan was expanded out to see.  So not fixed.

Lost IPv6 connectivity once again…

@Nadrek:

Agreed; particularly with USB devices, the very likely difficult step of tying interface identification to something more permanent than boot load order becomes very important; if I move a couple USB devices around/add/remove them, and even swap PCI(e) card slots, I'd prefer to have the interface assignments follow actual cards, not where they happen to be.  Ideally, base it on ID (8086:422c for an Intel 6200) plus and MAC address, and then use the some other ordering (the current system or one of the alternates below) to resolve duplicates.

That introduces its own problems. Have a box die on you, get a warranty replacement, restore your config, and it works perfectly the way things work now. Do this, and it no longer works. Numerous vendors ship boxes with custom pre-assigned NICs, which this would break. MAC spoofing also breaks this as the NIC's hardware MAC is gone once it's spoofed. There are countless other caveats. No matter how you handle interface assignments it introduces complications, breaks things that currently work that many people rely on, and has other caveats, in addition to being a very bug prone and work intensive process to change. This is one of those things that may seem simple at the surface but is actually very complicated. We've been discussing this one for going on 8 years off and on, and it's a real mess to do any differently. Hence it's not changing any time soon.

Looks useful

Hi,

Has this issue been fixed? or is in the works?

Thanks

Ok So I swapped out my dual server nic for a realtek 8179 I think it is.  PF calls it rl1
I get the same results,
100 MB file download cp counts from 258 too 368. Correct .. Bandwidthd counts from 522.4 too a whopping 743.7 witch is about double what it should be.
Is there anyway I can force BWD too get it's info from the same place CP does?
I want to set hard limits monthly some daily I would like to be able to offer users a way to keep exact tracking of what they have used/left.

thanks jimp… I had a feeling that could be the case :-(  I figured out how to get vnstat2 to work for now.... I really need to learn how to program php...lol

Added some includes there and in ospfd/quagga since they have similar sets of code, and someone could hit the same issue there potentially.

https://github.com/bsdperimeter/pfsense-packages/commit/b85fee0718d37e8da27ab2530e311cf5ac6d7434

So, loader.conf is not the definitive solution ?.

There's already a thread for this, http://forum.pfsense.org/index.php/topic,50971.msg272647.html#msg272647

please search the forum..Its a known issue, its being worked on.

http://forum.pfsense.org/index.php/topic,50971.msg272647.html#msg272647

Just a tip for anyone interested. My advice is to make sure your servers are Dual Stacked so you won't have to care where the client is coming from. It will just work.

4in6, tunnel IPv4 over IPv6, the reverse of
6in4(6over4), tunnel IPv6 packets over IPv4 to a relay on the other side.

6to4, this automatically generates a IPv6 prefix you can use based on your public IPv4 Address. This breaks if you don't get a public IPv4 address. Which is the case soon since most Local registries will run out of public v4 "soon" and thus start giving users a private address and NAT everything. This transition tech has limited lifetime. Always starts with 2002::/16. It carries the IPv6 traffic over IPv4 like 6in4.

DS-Lite, tunnels your IPv4 over IPv6, you still get NAT from the ISP but the base carrier is IPv6, like 4in6. The benefit from the ISP is that they don't need Public IPv4 to rollout, which is what any starting ISP will need to do starting 2013 because they will get a single /22 for transition purposes only.

6rd, based on the 6to4 mechanism, but the ISP controls the relay which means they can offer a more reliable service, it also works with private IP addresses on the WAN because they can define the relay the client uses. It uses a similar "calculate the local prefix based on the WAN address" as 6to4, but it can have a different prefix from 2002::/16 and is ISP prefix instead.

ISATAP, Teredo, ignore. It's going away. Windows thing. Automatic tunneling mechanism.

NAT64, DNS64, This is what you will use if you have a v6 client, that can not speak IPv4. We'll need this in the near future, mostly for mobile since it's hard to do dual stack there. Otherwise a v6 only device can not reach IPv4 sites. T-Mobile US is running limited scope testing, but most things work fine.
You'll need a black belt in packet capture foo to decode the NAT though. It's positively unreadable. But it's required to go forward.

4rd, rapid IPv4 deployment, but over IPv6. Tunnel your IPv4 over IPv6. This might be used somewhere in the future. This is for ISPs deploying IPv6 only to the client and then to give them a small bit of IPv4 so they can atleast dual stack. It means all equipment between your CPE and the ISP is IPv6 only. Which is something that will happen in 2013+. See DS-Lite which so far the ISPs prefer better.

NAT-PT, NAPT-PT. You mean something like Carrier(Crummy) Grade Nat, or Large Scale(Sucky) NAT.
I feel for anyone that's going to see their internet connection end up like this, sharing a single IP with a few hundred customers and then wondering why the single IP block from the forum just took out a whole lot of customers. All the automatic blocking mechanisms we have today in forum software in the like will wreck havoc with this.

The FBI was complaining about not being ready to track IPv6, that's just silly, they should try and decode connections from such a large NAT and then try to find which of the few hundred users was it.

Sure, wasn't meant to knock pfSense, after all, the built-in RRD works just fine.

As a matter of fact, in many ways it's the thing I like the most, except it doesn't allow to monitor traffic to/from specific IP addresses/nets, which is useful in discovering abnormal traffic patterns.

It's a bit disheartening though, that authors of such software wouldn't want to support IPv6, which clearly is going to be the future. They might as well just abandon writing the software, period.

ntop however, seems to support IPv6, it just has an issue with recognizing the tunnel interface. Not sure if that's a BSD, pfSense, or ntop issue, though. That might be worth investigating.

Well, I removed the interface and reran through the tutorial and I didn't run in to the problem again. Not sure what was up before, but it is working now.