HFSC is inter-queue and FAIRQ is intra-queue. Another way to put it is HFSC decides which queue goes next and FAIRQ decides which packets leave a queue.

https://blog.pfsense.org/?p=1588

Now hook in some BSDploy (http://docs.bsdploy.net/en/latest/)

@phil.davis:

FreeBSD 11.0-CURRENT Release Notes: https://www.freebsd.org/relnotes/CURRENT/relnotes/
That is an ongoing set of release notes that are updated as things happen.

There is also https://wiki.freebsd.org/WhatsNew/FreeBSD11

Looking at, potentially, the most important section of that for the average pfSense usr:

Support for linking NIC Receive Side Scaling (RSS) to the network stack's connection-group implementation (r263198)

We actually (privately) support this by loaning a set of 10G and 40G cards to the individual doing this work.  It won't have a large
impact on pfSense (yet), because it is all being done first to support reception on the box, rather than forwarding through it.

Support for the UDP-Lite protocol (RFC 3828) has been added to both IPv4 and IPv6 stacks (r264212)
I doubt anyone cares (yet), and this was already in FreeBSD 10.1 (and thus pfSense 2.2) for IPv4.

IPX is no longer supported (r263140)
Hurray!

AppleTalk is no longer supported (r263152)
Hurray!

Flowid, bindmulti and RSS awareness have been added to the IPv6 stack (r268562)
See above where we support this via loaned cards to the developer

RSS awareness has been added to the igb(4) driver (r268028)

RSS awareness has been added to the ixgbe(4) driver (r268029)
These are Intel 1Gbps and 10Gbps cards.  Please see the paper, "Measure Twice, Code Once: Network Performance Analysis for FreeBSD" to be given by George Neville-Neil and myself at AsiaBSDcon in March.  I won't reveal the contents of the paper, but I will reveal that pfSense 2.2 is significantly faster than 11-CURRENT with a NODEBUG kernel.

netstat can display RSS and flow information with -R (r266448)
See above.

PF hash has been changed from Jenkins to Murmur3 which shows a conservative 3% increase in packets per second (r272906)
We're the party responsible for making this happen.  (It was George Neville-Neil and I.) and it's already in pfSense 2.2, btw.

Netmap support has been added to libpcap allowing tcpdump and other native pcap application to run directly on netmap ports (r272659)
this is (just) importing more of Luigi's latest work.

faith(4) and faithd( 8 ) have been removed from base (r274331)
Hurray!

cxgbe(4) will now front loads as much as possible before any driver lock or software queue gets involved (r276485)
Chelsio cards.  There was a useless panic removed yesterday as well.

@phil.davis:

Is there a "roadmap" document somewhere that has a target timetable for 11.0-RELEASE and what is hoped to be in it?

It's not that time, yet.    Nor is this the FreeBSD-CURRENT forum.

The other major thing that is in pfSense 2.2 that is not yet in FreeBSD are the changes to the IPsec stack to support AES-GCM, enabling AES-NI accelerated IPsec.  Make no mistake, it's going in FreeBSD, it's just that the work isn't done, yet.

@reggie14:

@Harvy66:

The most concerning exploit I can think of is the RNG. Almost any changes to AES-NI will cause the system to stop working and will be easily detectable as storage and network instantly breaks. But changes to RNG does not cause catastrophic failure.

Agreed.  To make matters worse, poor RNGs are extremely difficult to detect.  And in crypto protocols there are lots of opportunities for the attacker reconstruct the state of your RNG if it has a major weakness.

@Harvy66:

Most any back door related to AES-NI will probably require physical access at some point. AES-NI could save the last N keys in non-volatile on-chip storage or at a certain memory location in dram. Storing unexpected data in dram could very likely result in data corruption unless the location was reserved, but the CPU does not reserve memory, it would have to be in concert with another device that is also back-doored.

Maybe I'm not following you, but AES-NI doesn't do what you think it does.  As I said in my previous post, AES-NI is just an accelerator.  If you want to steal a key, you certainly don't need physical access.  The keys are just sitting in memory, so you just need to memory-scrape it (or, in some cases, read it from disk).

Even if someone wanted to put a backdoor in AES-NI, I'm not even sure what they'd do that wouldn't be better accomplished with some other form of malware. (And those other methods would work perfectly fine against any software crypto library.)

@Harvy66:

Any hardware based remote backdoor would require several devices to work together to accomplish this feat. Doing this transparently in a way that doesn't cause an OS to crash would be quite hard, since not all OSs work the same and they change over time.

Well, that depends on what you mean by a hardware-based backdoor.  Purely hardware?  Sure, that looks needlessly complicated.  But if that includes tampering with low-level firmware, either in the BIOS or in the firmware in any of the numerous devices in your computer with direct memory access, then that doesn't look that hard.  It seems like an awful lot of work to for a highly targeted attack, though.

For both the AES-NI and "hardware" backdoors, I was going after is it would be hard to create remote backdoor that was integrated into the hardware and not software. Creating any old remote backdoor wouldn't be hard, but creating an undetectable backdoor that does not crash the system would be quite difficult if it was built directly into the CPU or network silicon.

I assume the easiest place would be into the drivers, assuming they're binary blobs.

windstream is my dsl provider don't know if they offer third party isp option

Yep, sad times. I remember running m0n0wall on an old P100 many years ago. That was my first BSD experience.

Steve

+1  Land of my peeps… 8)

Just for fun, there are 2^64 IPv6 addresses in a /64 IPv6 subnet - that is:
18,446,744,073,709,551,616

There are 3,153,600 seconds in a year. Let's say your nmap can scan 1,000,000 (1 million) addresses per second, just to be ambitious.

So it will take 18,446,744,073,709 seconds, which is 5,849,424 years.

Hmmm - I don't think I want to wait that long just to find the IPv6 address of my lost device.

ha!

Many of us are already married. We always accept a free $beverage though.  :D

The Gold Member "meetups" are the monthly Hangouts we have that are generally like a mini training session or us showing off a particular feature or methodology.

Eventually we'll run out of topics though!

We want to have some of them be Q&A sessions as well but the fear is that people will treat them as "fix my firewall" sessions and not a Q&A to benefit everyone. It may work if we have everyone submit some brief questions beforehand so we can have plenty of choices and time to research.

Every other VM's are running absolutely fine apart from the pfsense. The Install is clean and version is 2.2

Actual System build is

2.2-RELEASE (amd64)
built on Thu Jan 22 14:03:54 CST 2015
FreeBSD 10.1-RELEASE-p4

BTW it reboots again. :'(

Most of the conce[ts still apply.  There will be be GUI changes and some other stuff like Unbound but I would think 85% is the same.

If one deserves it, it is you  ;D ;D ;D

(congrats with even more work  :P ;D 8) )

congrats.png
congrats.png_thumb

May take longer then 2.3… ::)

I'd really drop any forwarding. Unbound + DNSSEC. There's also this 0x20 draft - patch for pfSense available here until 2.2.1 is out.

Naah, I solved it…

Had to select management vlan to 5 and also pass VLAN1 between devices.

Use Google fiber and the state watches you everywhere :D

It's the little things that make the difference.