The pfSense Store

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - jwt

Pages: [1] 2 3 4 5 ... 23
I'm looking for the ultimate Travel / Off Grid / Emergency Operations security appliance that I can store and operate in a small Pelican case off DC power if AC is not available.  The SG-1000 is cute and affordable @ $149, but I just want a little more "oomph" in the same form factor.
  • Same or similar form factor as SG-1000.
  • Multi-core CPU.
  • Higher clocked CPU.
  • AES-NI support for future proofing.
  • Include 1-year Gold Subscription.
  • $199 price point possible?  ;)

I've considered building a second generation on the Armada 3720

2 cores @ 1.2GHz. (ARM64)
has crypto offload (does what you want from AES-NI)

Official pfSense Hardware / Re: SG-3100: How do I assign port(s) to a VLAN
« on: November 22, 2017, 11:47:34 am »
Line 215 of /usr/local/www/switch_vlans.php


   foreach ($config['switches'] as $cswitch) {

wants to be:

   foreach ($a_switches as $cswitch) {

for now i had to rename all igb.20 to igb1_20 to make it connect, why would they release it with such a bug

It was allegedly done because of some ARM nonsense where some genius decided to name the interface mvneta and they found that it was too long after beginning to sell hardware with those. (Those are the SG3100 units than can be recycled as paperweight once your one year support has ended and you need to reinstall, since there are no public ARM images available.)

Renaming interfaces is about the most critical thing you can mess with on a networking gear such as firewall. So, of course a minor bugfix release is an excellent opportunity to change those, completely untested and after 2.4 has been tested for ~1 year. Sigh.

Once again, reading the release notes is important:

Yeah, once again, noone sane makes and expects such changes at this time point.


Point in-fact the "too long" was due to some work done (by people who are now gone) to use "interfacename<unit>_vlan<number>" in pfSense.

What we did is to repair the pfSenes code to use the FreeBSD standard "interfacename<unit>.<number> where <number here is the vlan tag".

As you should be well-aware, choices made over the last decade mean that pfSense can be quite difficult to maintain.

This did not occur "after beginning to sell hardware" as you assert.  You are 100% wrong on this point, and you need to retract.   2.4.0-RELEASE occurred prior to SG-3100 entering a shipping state, and, in fact, the earliest release of pfSense for the SG-3100 is 2.4.1-RELEASE.

This "mvneta" name did not come from us, it came from Semihalf, via FreeBSD.
Many people are misinformed about being able to get reload images for Netgate platforms.  You perpetuate the myth, and I think only to gain advantage.

You've made several false statements in the above, and denigrated members of the team.

We've been here before.  Back down the rhetoric, and retract the above, or go somewhere else.

You have zero more chances, and I am 100% serious on this point.  Criticism is fine, but lying is not.


a) we're not convinced that the LAGG issue is correctly fixed yet.

b) you could always write me directly and ask for that patch.  have you done so?  If you have, I can't find it.  Engaging in this kind of cajoling and hyperbole on the forum is exactly how you drive me to ignoring you (all).

If the only value you ascribe to pfSense software is that it is open source, that none of the development, integration, Q&A and having a company solidly behind the project are of no value to you, then I suggest that you fork the project and find like-minded people to work on it with you.

We are, literally, investing millions of dollars in pfSense software and giving the result away to the community for their use.  The only restriction is that commercial distribution is not allowed.  This is because it is how we fund the development.  Without the revenue associated with hardware sales, pfSense would not be developed at the rate the community has enjoyed for the past half decade.

It's like you're asking for that to stop.

I've asked that the thread be unlocked.

to address the topics presented by 'doktornotor' (does anyone want to hazard a guess as to how much I enjoy responding to anonymous posters to the forum?):

the documentation was removed (It did not "disappear") because it was no longer accurate.

As the patches to FreeBSD are matured to a state where they can be upstreamed to FreeBSD, we will do so.

please open a bug on

Wireless / Re: Very serious security problems with WPA2
« on: October 17, 2017, 09:28:08 am »
The vast majority of people are not going to update from snapshots for machines in use, unless they are lunatics.

Nor are the vast majority of pfSense users using WiFi.

I anticipate both 2.4.1 and 2.3.5 being released next week. (Ask me how I know.)

Wireless / Re: Very serious security problems with WPA2
« on: October 17, 2017, 09:21:58 am »
If OpenBSD was aware of the problem since mid-july and have already deployed a patch, then why FreeBSD were only aware of the problem only a couple of days ago?

Ubiquiti is already up to date against this flaw. That's sad for pfSense.

Because OpenBSD had a specific attack shown to them, so they broke the embargo, and as a direct result, that researcher will no longer give them long leadtimes.  Further, the researcher showed where OpenBSD is still vulnerable.

Snapshots for 2.4.1 and 2.3.5 with fixes for this problem and other are already published.

Nor would I call Ubiquiti “up to date”.  While they published firmware for UniFi and SG- series, they build a lot of other gear (e.g. cameras) that have not been updated.

Finally, what is “sad” here is your desperate cry for attention from a new account.  Stop, or the ban hammer drops.

Hardware / Re: Atom C3758 - Supermicro A2SDi-8C-HLN4F - PFsense?
« on: October 14, 2017, 01:29:35 am »
C3000 is already running in the lab.

Hardware / Re: ESPRESSOBin
« on: October 14, 2017, 01:28:16 am »
yes, if you look at that posting, you'll see we helped bring the Armada 38x code to FreeBSD.

and (semi-obviously) we have product based on same.

I'll be working on the 3700 soon.

I'm specifically looking for the 11.1 (2.4.1) 6rd patch(es).

Being Franco's waterboy isn't going to put you in the best light, Larry.  Franco can work on his project, we'll work on ours.

We are not stoping our work to upstream a change because he needs it in his project.


Official pfSense Hardware / Re: 8860 hardware offload
« on: September 18, 2017, 10:34:33 am »

Hardware Large Receive Offloading (LRO)
LRO works by aggregating multiple incoming packets from a single stream into a larger buffer before they are passed higher up the networking stack, thus reducing the number of packets to be processed. LRO should not be used on machines acting as routers as it breaks the end-to-end principle and can significantly impact performance. pfSense is most frequently used as a router or an equivalent.

Hardware TCP Segmentation Offloading (TSO)
TSO is similar to LRO, but for sending. It works by queuing large buffers and letting the network interface card (NIC) split them into separate packets just before transmit.

Both LRO and TSO can help when pfSense is an endpoint and not a router. If pfSense is being used as an appliance (e.g. for DNS), it is possible the options could enhance performance.

Hardware Checksum Offloading
The Ethernet hardware calculates the Ethernet CRC32 checksum and the receive engine validates this checksum. If the received checksum is wrong pfSense normally won't even see the packet, as the Ethernet hardware internally throws away the packet (though there are exceptions, such as when the interface is in promiscuous mode).

Higher-level checksums are "traditionally" calculated by the protocol implementation and the completed packet is then handed over to the hardware. Recent network hardware can perform the IP checksum calculation, also known as checksum offloading. The network driver won't calculate the checksum itself but will simply hand over an empty (zero or garbage-filled) checksum field to the hardware.

Some cards will additionally process TCP and UDP checksums, as above, but this isn't of value on a router.

It's possible, when everything else is right, that IP checksum offloading can provide a modest performance improvement, but this is unlikely to be more than "noticeable" with the traffic processed by most pfSense installations. However, at 10Gbps or above, such offloading can become quite useful. Support for these is an important component of the pfSense "3.0" effort.

pfSense 2.x defaults both the LRO and TSO settings to disabled and the Hardware Checksum Offloading settings to enabled.

2.4 Development Snapshots / Re: 2.4.0 RC no packages available
« on: August 20, 2017, 01:54:53 pm »
2.4.0-RC1 isn't officially out yet.  Probably tomorrow. 

Pages: [1] 2 3 4 5 ... 23