On my laptop (HP Spectre x360 2018), I decided to install a second FreeBSD install, this time on the Intel Optane drive.

When I proceeded to install, I chose manual partitioning, and while it finished extraction, it proceeded me to this error:

This happened to me on a recent 13-CURRENT. I don’t believe it happened on earlier snapshots or 12.x. I had this issue with both UFS and ZFS partitioning.

After tesing on my desktop via VirtualBox EFI mode, I found out the issue was the fact that the EFI system partition wasn’t formatted.

Solution: To fix this issue, you need to make sure you have a FAT-formatted EFI system partition. This doesn’t mean the EFI partition has to be mounted, and as of the time of posting the FreeBSD UEFI bootloader won’t get loaded.

As a hobby, I play with software routers in virtual machines (always FreeBSD). One recent project of mine was to emulate DSL bandwidth and latency in a VM, from varying bandwidths of 1.5 Mbps (ADSL) to 50 Mbps (VDSL2).

By default, when using FreeBSD on a hypervisor, the kern.hz tunable is set to 100. This is to prevent additional CPU use from idling.

But dummynet recommends kern.hz=1000 which is also the default on physical hardware. This is to prevent additional latency as dummynet uses clock ticks, and this also works with VMs.

Using dummynet and the default kern.hz=100 on both VirtualBox and bhyve hosts had about 10-20ms delay.

If I set kern.hz=1000 in /boot/loader.conf, the latency from dummynet drops to <1ms on average, and at worst 1-2ms.

However, this has the disadvantage of higher idle CPU use (as mentioned earlier) in the VM running dummynet. I only recommend setting kern.hz=1000 in a VM only if you are using something like dummynet which relies on clock ticks and some idle CPU use is acceptable.

After graduating college, I am moving from Brooklyn, NY to Redmond, WA (guess where I got a job). I always wanted to re-do my OPNsense firewall (currently a HP T730) with stock FreeBSD and IPFW’s in-kernel NAT.

Why IPFW? Benchmarks have shown IPFW to be faster which is especially good for my Tor relay, and because I can! However, one downside of IPFW is less documentation vs PF, even less without natd (which we’re not using), and this took me time to figure this out.

But since my T730 is already packed, I am testing this on a old PC with two NICs, and my laptop [1] as a client with an USB-to-Ethernet adapter.

So you may ask how do we do this?

First, you need the ipfw and ipfw_nat kernel modules. To load them, run:

kldload ipfw ipfw_nat 

Then, you need a firewall ruleset. A basic ruleset is as follows:

#!/bin/sh  ipfw -q flush  ipfw nat 1 config if fxp0 redirect_port tcp 192.168.1.10:9001 9001 ipfw add 100 nat 1 ip4 from any to me in via fxp0 ipfw add 200 nat 1 ip4 from 192.168.1.0/24 to any out via fxp0 ipfw add allow ip from any to any 

This setup sets up NAT with fxp0 as the WAN interface, and sets up a port forward to 192.168.1.10 at port 9001.

Then, you should enable the firewall in /etc/rc.conf:

firewall_enable="YES" firewall_script="/PATH/TO/RULES" 

Replace /PATH/TO/RULES with the path to the IPFW ruleset, and don’t forget to run chmod a+x /PATH/TO/RULES (to be safe).

And enable the NAT firewall with service ipfw start.

What does all this mean?

The first ipfw line flushes the existing ruleset, which you should do for obvious reasons when reloading.

In the second ipfw line:

• 
  

  The nat 1 config if fxp0 part sets up NAT with fxp0 as the WAN interface. Replace fxp0 with your WAN interface name.

  
  
• 
  

  The redirect_port tcp 192.168.1.10:9001 9001 sets up a port forward to 192.168.1.10 with port 9001 [2]. Replace 192.168.1.10 and 9001 with the IP:Port combo you want to forward. This can be repeated multiple times.

  
  

The third ipfw line allows traffic to come in to the internal network via fxp0.

The fourth ipfw line allows outgoing NAT traffic from the 192.168.1.0/24 subnet to go through fxp0. Change 192.168.1.0/24 with the subnet you want to use. If you have multiple noncontiguous subnets, repeat this line with each subnet individually.

You can also expand the ruleset, as explained in the ipfw(8) man page.

Footnotes

[1] – FreeBSD, not Windows at the time of writing. My job could change this, who knows?

[2] – You will not have NAT reflection/hairpinning. If you need to access an external domain from your internal network, consider split-horizon DNS.

I recently picked up an HP T730 as my OPNsense firewall, mainly to repurpose my previous HP ProDesk as a desktop. With that, I also initially tried an Intel NIC primarily because the de-facto NIC choice for OPNsense/pfSense is in fact Intel. To my surprise, the T730 froze with the Intel-based NICs I tried, both igb and em based cards.

Many people have reported on pfSense’s subreddit that certain Intel-based NICs actually do freeze on the T730. However, not all Intel-based NICs freeze.

However, my gut told me that instead of hunting down the right Intel NIC and hoping it works, just buy a Broadcom-based NIC and ignore the “advice” of the community. I then decided to then buy a two-port Dell Broadcom BCM5720 for my T730, and it actully worked. I installed the Broadcom card yesterday and the system works even today.

I haven’t heard the same freezing complaints for Broadcom NICs on the T730, so it may not have the same issue (but it may). Or the pfSense/OPNsense community convinced people to only buy Intel so nobody tested Broadcom further.

I’m not saying that Broadcom is perfect. Broadcom Wi-Fi in an older Dell laptop meant no Wi-Fi on FreeBSD. And maybe Intel is better than Broadcom 99% of the time. But in the case of the HP T730, just stick with Broadcom for this one.

If you had success (or failure) on the HP T730 with a Broadcom (or any non-Intel) NIC, please tell me at neel AT neelc DOT org and I will (hopefully) update this article.

UPDATE: The Broadcom/T730 setup worked well for many months with a HP T730 on a “Gigabit” connection, albeit one with occasional slow transit/peering. “Genuine” Intel i340/i350 cards should work as well (from what I’ve read).

If your ISP uses it (e.g. CenturyLink, Bell Canada, etc.), you may run into the igb bug with PPPoE queues. I never had CenturyLink or Bell, or any ISP using PPPoE as of writing so I can’t confirm. Surprisingly, I am hoping for the former’s FTTH offering where I move next despite PPPoE.

I have been asked to use GENI to test some software I have written at CacheCash/NYU. To communicate with GENI, you usually use a tool called Omni.

FreeBSD has been my choice of desktop operating system since 2012, and since I am using my personal machine, my work is being done on FreeBSD.

However, Omni only supports Python 2 while FreeBSD’s default version of Python is Python 3. Not that a default of Python 3 is a bad thing (I think it’s a blessing), but some additional steps are needed to install run Omni in this case.

First, you need to install the dependencies using the command below:

sudo pkg install py27-m2crypto py27-dateutil py27-openssl xmlsec1 py27-xmlsec autoconf 

Then, you should download Omni’s source code which can be found on Omni’s respective GitHub Wiki page.

Once you have downloaded and extracted the archive, you need to tell Omni and autoconf to use Python 2. To do that, run:

setenv PYTHON python2 # To tell autoconf to use Python 2 and not 3
find geni-tools-2.10 -type f -exec sed -i '' -e 's/env python/env python2/g' {} \; # So the scripts call Python 2 

Replace geni-tools-2.10 with your extracted directory. Keep in mind that you have to call it from the parent directory of the geni-tools directory because ./ results in Invalid Command Codes errors.

Then, you should configure and build Omni. To do that, run:

cd geni-tools-2.10 autoreconf -i ./configure make 

Replace geni-tools-2.10 with your extracted directory.

Now, you should install Omni. To do this, run:

sudo make install 

And after that, you should be able to use Omni and GENI as normal.

I have gotten a HP T620 Plus as a firewall box, replacing a Chinese “Mini PC” which barely handles my 300/300 Verizon FiOS. The T620 Plus is a very popular choice in the pfSense world, however I wanted to go with OPNsense.

One issue with the T620 Plus with OPNsense is that when you attempt to install, you get a segmentation fault in the installer. From forum posts, many other people have had this issue with HP and non-HP hardware.

The issue is that the OPNsense installer uses a client/server setup that doesn’t play well with the full-screen UEFI console, and OPNsense doesn’t boot on the T620 Plus in BIOS mode because HP’s UEFI doesn’t want to boot BIOS from GPT disks.

To fix this issue of segfaults from the installer, you need to boot in UEFI mode from the USB containing OPNsense. When you are at the OPNsense loader screen (with the countdown), press Esc.

When you are at the loader prompt starting with OK, type the following:

set gop 0 

And press enter. The screen should go blank. When it does, type in the following to boot (even if there is no output):

boot 

And press rnter. After the above step, you should get a (lower-resolution) console that doesn’t bug out with OPNsense’s installer. Then you should be able to install OPNsense normally.

You do not need to put set gop 0 in /boot/loader.conf on the installed copy of OPNsense.

Note: I am using FreeBSD as the operating system in the article, but the information should be generic to Linux or any non-Microsoft operating system. This should also apply to most other current HPE ProLiant servers (as of 2019) other than the MicroServer (UPDATE: Don’t own one, but this article should apply to the new MicroServer Gen10 Plus as well).

I recently got a Xeon 4108 HPE ProLiant ML110 Gen10 to replace my MicroServer as a home server along with two 1TB hard drives to run in ZFS RAID.

As a FreeBSD person, the natural thing for me to do when getting a new server is to install FreeBSD. So I installed FreeBSD in UEFI mode, and added a UEFI boot entry. When I rebooted, it didn’t boot FreeBSD but instead tried to boot from the network.

I did a Google search and found a PDF about HPE’s UEFI configuration). It turns out that the SATA controller on my server was set to “Smart Array SW RAID Support” by default and that is supported in Windows only. As I am using SATA and ZFS mirroring on FreeBSD, I had to set the SATA controller to AHCI mode.

To do this, first reboot your server and press F9 when offered. This will get you into the UEFI setup. If you are asked for a BIOS password, enter it.

Once you are in the UEFI setup, go to System Configuration -> BIOS/Platform Configuration (RBSU) -> Storage Options -> SATA Controller Options.

When you are on the SATA Controller Options menu, click on the Smart Array SW RAID Support in the Embedded SATA Configuration option, click on OK (it’s a warning about legacy BIOS mode that we’re not using), and select SATA AHCI Support.

Then you should save the BIOS settings and reboot. To do so, press F12 and press OK. Now, you should have [OS of your choice] booting from disk in UEFI mode on your ProLiant.

If you’re like me and run FreeBSD on a laptop (mine is was a HP EliteBook x360 1030 G2 before I broke it in a bothed “repair” job), one issue you may encounter is the fact that switching between speakers and headphones isn’t automatic. This isn’t a HP-specific problem as I also know this impacts Dell laptops, and probably impacts other laptop brands as well.

However, not all hope is lost. FreeBSD allows you to specify your audio device in device.hints to make automatic switchover between the integrated speakers and 3.5mm jack possible.

On laptops where the switchover isn’t automatic, you often have multiple pcm devices. On my EliteBook, these pcm devices exist (via dmesg | grep pcm):

pcm0: <Conexant (0x2008) (Analog)> at nid 23 and 26 on hdaa0
pcm1: <Conexant (0x2008) (Right Analog Headphones)> at nid 22 on hdaa0 pcm2: <Intel Kabylake (HDMI/DP 8ch)> at nid 3 on hdaa1 

While I’m no expert on FreeBSD’s audio subsystem or an audio engineer (the best I know about audio is really only a bit more than “Beats by Dr. Dre suck”), from what I understand, hdaaX is the system’s HD “audio codec” (meaning audio chip X) and pcmY is FreeBSD’s audio instance (meaning instance Y of the pcm subsystem).

Here, hdaa0 is the audio codec for the integrated Conexant audio used by the headphones and speakers, and hdaa1 is the audio codec used by HDMI.

The issue which arises is that with one hdaa device, you have two pcm devices for your integrated audio, and FreeBSD doesn’t automatically configure switching between this. To enable this switching, you need one line in /boot/device.hints for your headphones:

hint.hdac.X.cad0.nidYY.config="as=1 seq=15 device=Headphones" 

Where X is the number assigned to the hdaa associated with your “Headphones” dmesg line, and YY is the nid number assigned from the same line.

You also need one line in device.hints for your speakers:

hint.hdac.X.cad0.nidZZ.config="as=2 seq=0" 

Where X is the number assigned to the hdaa associated with your “Analog” dmesg line, and ZZ is the nid number assigned from the same line.

Keep in mind that your system may use different terms for “Headphones” and “Analog”. Also, if you have multiple nid values, use one. If that doesn’t work, try the other one.

Using the output for my system, my device.hints has the following new lines:

hint.hdac.0.cad0.nid22.config="as=1 seq=15 device=Headphones"
hint.hdac.0.cad0.nid26.config="as=2 seq=0" 

Note: Don’t just copy and paste my values, your system may be different!

After entering the following lines, you should now reboot.

Once you rebooted, try playing something with audio (e.g. YouTube) with and without headphones plugged in. This should work, as it works for me with the HP EliteBook x360 1030 G2 running FreeBSD 12.0 mentioned above along with AKG Y50BT headphones in wired mode.