FreeBSD Network Status 2025 Week 05

Here we are 8% of the way through the year and the end of January. Perfect time to check in with what is going on in FreeBSD.

Goings on

BSD Devroom at FOSDEM 2024

I'm writing today above the North Sea on my flight to AMS on the way to Brussels for FOSDEM. The BSD Devroom is running tomorrow (Saturday the 1st of Feb) and there is a great line up of talks. If you are within a reasonable travel distance head over, its a free event and there is a ton of stuff going on.

Beyond the talks there will be a FreeBSD table for the project and the foundation. We have stickers and I'll be there if you want to chat about goings on in the project or to complain about some of the bugs I've written recently.

Stab week

This was the first stab week of the year and two regressions were picked up through repeatided stabbings:

  • Compilation failure on 32-bit platforms. Fix [5289625dfecb] (https://cgit.freebsd.org/src/commit/?id=5289625dfecb)
  • Instant panic with SO_REUSEPORT_LB and nginx. Fix 06bf119f265c

glebius@ is adding scripts to make it easier to know when it is time to stab. I'm hoping more tooling involves and we start getting more testing in the stab weeks. The work Netflix is doing here is incredibly helpful for the quality of FreeBSD, but other workloads should also be represented.

Network Stack

Caught in stab week was a regression in the TCP listen operation when it is called multiple times on a socket. This was harmless generating multiple TCP state changes until last week after a clean up fixing races where started to call LIST_REMOVE() twice on the same entry.

Style and small fixes for netlink and netlink/route support.

ip6addrctl manages address selection policy for outgoing packets. With some improvements teach it how to run in a jail.

Netdev

Replace the single global admin taskqueue with a per interface admin taskqueue. This should resolve timeouts when long operations are performed without using too much more in resources.

Add a device id to ure, otherwise it will use the CDC mode driver. If you have issues with USB Ethernet you might want to look to see if moving from the CDC driver will help.

Wireless

Some further fixes around firmware loading for iwm and its integrated bluetooth controller.

Add support for Blueooth Secure Simple Pairing - which I didn't manage to look up before getting on a plane.

Firewalls

This is the third week of changes adding support for NAT64 with some more changes coming in via OpenBSD.

User Tooling

Netcat is the network swiss army knife, an incredibly useful and flexible tool for doing stuff that requires you to put packets onto the network. It is great exemplar of how to use networking options and used more and more by network tests. There was an issue in this stab period around SO_REUSEPORT_LB , making testing more practical helps catch issues closer to their introduction.

Other stuff

Nice fix from mckusick@ to UFS1 file system helping with the inevitable passage of time.

  • 1111a44301da Defer the January 19, 2038 date limit in UFS1 filesystems to February 7, 2106

    Defer the January 19, 2038 date limit in UFS1 filesystems to February 7, 2106

    UFS1 uses a signed 32-bit value for its times. Zero is January 1, 1970 UTC. Negative values of 32-bit time predate January 1, 1970 back to December 13, 1901. The maximum positive value for 32-bit time is on January 19, 2038 (my 84th birthday). On that date, time will go negative and start registering from December 13, 1901. Note that this issue only affects UFS1 filesystems since UFS2 has 64-bit times. This fix changes UFS1 times from signed to unsigned 32-bit values. With this change it will no longer be possible to represent time from before January 1, 1970, but it will accurately track time until February 7, 2106. Hopefully there will not be any FreeBSD systems using UFS1 still in existence by that time (and by then I will have been dead long enough that no-one will know at whom to yell :-).

    It is possible that some existing UFS1 systems will have set times predating January 1, 1970. With this commit they will appear as later than the current time. This commit checks inode times when they are read into memory and if they are greater than the current time resets them to the current time. By default this reset happens silently, but setting the sysctl vfs.ffs.prttimechgs=1 will cause console messages to be printed whenever a future time is changed.

Please Send Feedback

Smaller report this week. I'm trimming out more "small fixes" style comments. I'm going to play with the format of these posts more over the next few months. I am trying to add value beyond just rewriting commit messages, sometimes it is good to show the continuous on going work, but it will get a bit tedious if that is 60% of the report each week.

I'm giving a FOSDEM talk tomorrow on the writing of these reports.

I would love to know if this summary was any help, if it was, or if you think I should cover other thing please let me know (thj@freebsd.org).

If you find a typo or have a correct let me know and I'll thank you at the end here.

You can see all prior posts here. ( rss )


My work on FreeBSD is supported by the FreeBSD Foundation , you can contribute to improving FreeBSD with code, documentation or financially by donating to the FreeBSD Foundation .

Recovering from external zroot

My favourite terrible computer has been locking up after a VM panics and I need to panic a VM a lot to find a firmware crash. The hard power cycle reboot loop is taking too long and I'm done with it.

More annoyingly is is also hard locking up copying the VM off the machine. Thisb forced a trip to the attic, a reinstall of my large memory host (which for reasons had a 128GB NVMe, which is silly on a machine with 128GB of RAM!).

That is fine, I can pull the NVMe and drop it in an enclosure and just copy locally. For a zfs disk on a machine with an existing zroot this was turned out to be very painful. Somehow no one has written down how to do this either:

Normally zpool import take a name argument, but it can take a pool id. If you are using a machine with zfs on root then you will already have a pool called zroot , so trying to import your pool from an external drive will fail with the name already in use.

Finding the pool id can be done with the -d argument to zpool import . This takes a device to use as a pool.

# zpool import -d /dev/da3p4
  pool: zroot
    id: 647281366119489090
 state: ONLINE
status: Some supported features are not enabled on the pool.
    (Note that they may be intentionally disabled if the
    'compatibility' property is set.)
action: The pool can be imported using its name or numeric identifier, though
    some features will not be available without an explicit 'zpool upgrade'.
config:

    zroot       ONLINE
     da3p4     ONLINE

Now you can use the pool id instead of a name with zpool import

# zpool import -R /mnt -N -f 647281366119489090 -t oldzroot

With this command I ask zpool to import with a different root location ( -R ) so I don't clobber my existing file system, to not mount anything ( -N ), use the id and to use a temporary name for the pool ( -t oldzroot ).

With the pool imported you can find your dataset and mount it with zfs list and mount -t zfs .

FreeBSD Network Status Report 2025 Week 04

Goings on

FOSDEM 2025 is next weekend and we are fortunate this year to once again be running the BSD Devroom. The program is on the schedule

I need help staffing the Project/Foundation table at FOSDEM, if you want to help send me an email (thj@freebsd.org).

13.5 code slush in effect

The schedule currently looks like this:

ports quarterly branch:  January 1, 2025
reminder email:          January 13, 2025
stable/13 slush:         January 24, 2025
doc/ tree slush:         January 31, 2025
releng/13.5 branch:      February 7, 2025
BETA1 build starts:      February 7, 2025
BETA2 build starts:      February 14, 2025
doc/ tree tag:           February 14, 2025
BETA3 build starts:      February 21, 2025
ports package builds:    TBD (Between February 14 and 28)
RC1 build starts:        February 28, 2025
RELEASE build starts:    March 7, 2025
RELEASE announcement:    March 11, 2025
13.4-RELEASE EoL:        June 30, 2025
13.5-RELEASE EoL:        April 30, 2026
Branch EoL:              April 30, 2026

You can find the current issues for the release on this wiki page https://wiki.freebsd.org/Releng/13.5ISSUES .

This is the final release in the 13 cycle.

Network Stack

Previously this would always increment the first counter in the array. Accounting is really difficult! But good accounting can help you find interesting bugs .

The netlink API is getting more attention. I think we will see more network subsystems move towards netlink in the future so improvements here are always good.

Netdev

After a short 5 years (!!!) in review we have a new network adapter in USB umb(4) . This gives us support for cellular modems and makes fail over setups on FreeBSD possible. These are normally just data modems so we don't have a FreeBSD phone (yet).

markj@ is continuing fixing races in inpcb.

Wireless

adrian@ has continued his long series of changes to improve rtwn, if you want easy wifi in a random machine picking up a usb wifi device and testing it would help make this even better. More so if you work or visit somewhere with an interesting network like a huge campus or a University.

Improvements to handling of bluetooth firmwarein iwm WiFi devices.

Firewalls

More work on NAT in pf and supporting tests. The pace of pf development is incredible.

UPDATE: kp@ told me I missed the point of these changes the message should be something more like:

Ported OpenBSD's NAT64 pf implementation, extended it to support SCTP,
dummynet and if-bound mode. As a bonus added test cases.

"Don't send bug reports to kp@"

User Tooling

Did you know that you can boot over http using the efi loader?

Other stuff

Wider address space support on arm64, I can't find evidence of any hardware supporting this, but you can test in qemu or the arm simulator.

Sad news for the few keeping PowerMacs alive (but probably not surprising), Add a depreciation notice for firewire.

Please Send Feedback

I would love to know if this summary was any help, if it was, or if you think I should cover other thing please let me know (thj@freebsd.org).

If you find a typo or have a correct let me know and I'll thank you at the end here.

You can see all prior posts here. ( rss )


My work on FreeBSD is supported by the FreeBSD Foundation , you can contribute to improving FreeBSD with code, documentation or financially by donating to the FreeBSD Foundation .

Badger Badge

Years ago for for EMF 2022 I got some badger badged for me and Phine as a surprise and promptly forgot to take them with me. After 38c3 (for which much writing is waiting to leave my head) it was really obvious to me that things are easier for strangers if they get a clue about who you are.

As I will be at FOSDEM this year I thought I'd try and set up the badger with a contact card to make things easier while I run the project/foundation table.

The badger has a 296x128 eink panel and an Micropython "OS" that hosts some examples. The badger has an onboard RP2040 microcontroller which can control the display, read buttons and do stuff. It has an ebook reader and an image view. If I want my own content for the badge I just need to upload an image to /images on the badge and open it.

Uploading an Image

As I use FreeBSD and have an allergy to installing software I didn't want to install a python IDE to copy a file.

I thought this would be easy to do, it wasn't.

The badge has documentation for beginners, but I found it really difficult to actually find facts. I've done a fair amount of stuff with micropython on various microcontrollers so I was able to skip using their recommended GUI tools and use sensible things.

The RP2040 is flashed by powering it up with RST held, it then appears as a FAT mass storage device. Micropython firmwares either host their own mass storage and don't require the RST hold or can offer a file system via serial. The badger is one of the second.

The easiest way I have found to upload files to micropython devices is to use ampy from Adafruit. This season it is packaged as py311-adafruit-ampy

# pkg install py311-adafruit-ampy

If you plug the badge in and look at dmesg you should (but might not) see it connect as a serial device.

ugen1.12: <MicroPython Board in FS mode> at usbus1
umodem0 on uhub0
umodem0: <MicroPython Board in FS mode, class 239/2, rev 2.00/1.00, addr 14> on usbus1
umodem0: data interface 1, has no CM over data, has no break

umodem0 is ttyU0 and cuaU0 depending on what you are doing. I uploaded my image with the put command:

$ sudo ampy --port /dev/cuaU0 put badge.jpg /images/badge.jpg

and got this awful thing:

time to look at making the image better

Creating an Image

To make my FreeBSD badge I grabbed the Official FreeBSD Project assests from the Foundations website, dropped them into Inkscape and added some text using Roboto Sans the projects body text font. I then exported this to a non-progressive jpeg.

The output from Inkscape has some stray pixels, but badger has also applied dithering to the first image. This was a great opportunity to try the grafx2 bitmap editor so I pulled the exported JPEG into that. For what ever reason Inkscape had exported the black for the logo as very dark grey (12, 21, 23) and so the badger had done its best.

I edited the image to just be black and white saved it to BMP and then used convert to turn it into a 1 bit per pixel jpg.

$ convert badger-badge.bmp -depth 1 badger-badge.jpg
$ identify badger-badge.jpg 
badger-badge.jpg JPEG 296x128 296x128+0+0 8-bit Grayscale Gray 256c 10553B 0.000u 0:00.000

After a firmware reset (below) I then through the image onto the badger and I'm happy enough for now.

Firmware Reset

The BadgerOS doesn't want to run after I have loaded my image, but that is easy enough to fix. Hold boot/usr on the back of the badge then press RST and it will come up as a USB mass storage device then copy the .uf2 from Pimoroni's Github and unmount and you will have updated the badge and recovered it to a running state to try a second image.

$ sudo mount_msdosfs /dev/da3s1 ~/mnt
$ cp ~/Downloads/pimoroni-badger2040-v0.0.5-micropython-with-badger-os.uf2 ~/mnt/
$ sudo umount ~/mnt

FreeBSD Network Status Week 03 2025

Happy New Year and welcome back to FreeBSD Network Status Reports. I hope you had a great time over the Winter Pause (if you did pause) and are ready for another great year of improvements to FreeBSD.

I have opted to do a mega report, there have been 705 commits to FreeBSD main since my last update so we should get going before any more sneak in.

Goings on

BSD Devroom at FOSDEM 2024

The Devroom program is available here . I am speaking about writing these reports and staffing the Project/Foundation table the rest of the time. I could do with help covering the table (which must always be staffed) for the weekend. If you want to help send me an email (thj@freebsd.org)

Transport

In RACK and BBR there have been a bunch of tidy up changes simplifying code.

I think the other TCP changes fall under maintenance and general code quality. The "don't send beyond advertised window" change is an indicator of how complex TCP is to work on.

Network Stack

Better MTU selection when using ipsec.

Changes in VNET, more socket sysctl parameters are virtualised and there have been some fixes.

Several commits to netlink.

Netdev

Some fixes to mlx5 in SRIOV.

An update for the Cisco Virtual Interface Card driver to better handle MTU changes.

Wireless

adrian@ has been working on rtwn and it is growing into the WiFi device with the best support. IF you have supported USB hardware and want to try higher rates then testing CURRENT now would be appreciated.

Changes in net80211 and LinuxKPI to support HT and VHT rates. We are getting closer to the Linux KPI drivers having reasonably modern throughputs.

I think from the rtwn stuff some longer standing issues in ath were fixed.

gavin@ has started poking on the Broadcom NICs you might see in old MacBooks.

Firewalls

Much has happened in PF in the last month. OpenBSD's NAT rewrite support has been partially imported, with accommodation for FreeBSD's existing rule syntax. SCTP support has been expanded and is growing towards TCP support in PF.

There have been test, documentation support and bug fixes to help the NAT write and SCTP handling.

User Tooling

A fix in ping for minimum packet for ping sweeps and better error messages.

Other stuff

This is kind of a WiFi change, but it is important for how FreeBSD deals with firmware. Historically firmware was loaded as a kernel module and then requested by a driver, getting a opaque blob to send to the device. For CVS(?) it has to be uuencoded, which wasn't a real problem for a long time. From 15 firmware can just be loaded from disk as a blob, this frees up drivers a bit certainly making development easier, but it makes it more difficult for things like loader to load kernel modules and know that firmware will be there. Expect some churn. while thinks improve.

Please Send Feedback

There was a lot of stuff in the last month, but I decided to trim out most of the picked commits rather than make a lot of "small improvement" comments on huge series of changes. It is good to see the number of changes that pf gets every week and occasional bursts in other areas.

I would love to know if this summary was any help, if it was, or if you think I should cover other thing please let me know (thj@freebsd.org).

If you find a typo or have a correct let me know and I'll thank you at the end here.

You can see all prior posts here. ( rss )


My work on FreeBSD is supported by the FreeBSD Foundation , you can contribute to improving FreeBSD with code, documentation or financially by donating to the FreeBSD Foundation .