Why Do Japan’s APRS-IS Servers Run on FreeBSD? A Deep Dive Into status.aprs2.net

Introduction: What Is APRS-IS and Why Does The OS Matter?

If you open https://status.aprs2.net/ right now, you see a live dashboard for the APRS-IS Tier 2 network. APRS-IS is the internet backbone for the Automatic Packet Reporting System. It takes position reports, weather data, text messages, and telemetry from amateur radio stations worldwide and routes them across the internet in real time.

Tier 2 is a volunteer network of servers that filter and distribute APRS traffic so the Core servers do not get overloaded. There are hundreds of T2 Leaf servers in every country. They connect to T2 Hubs, and the hubs feed the Core.

Why should you care about the operating system these servers run? Because APRS is used for real emergencies. Search and rescue teams track assets with it. Weather stations from the Citizen Weather Observer Program feed data to the US National Weather Service through it. Satellites digipeat through it. If a server goes down, packets get lost. Uptime of 99.9 percent is not a marketing number. It is an operational requirement.

In the latest status dump you gave, a clear pattern shows up. Japan’s T2 servers run FreeBSD. Most other countries run Linux. This article explains why, using real data from status.aprs2.net, the history of BSD in Japan, and the technical strengths of FreeBSD’s network stack.

1. Look At The Data First: What Does status.aprs2.net Actually Show?

Let us pull the relevant lines from the status you pasted and sort by OS.

T2 Hubs:

Out of four hubs, only T2HUB1 runs FreeBSD. It also has the best score. Lower is better. T2HUB3 is down.

T2 Leafs in Japan:

Three of the four main Japanese T2 servers run FreeBSD. T2HAKATA has an http problem, but T2OSAKA and T2FUKUOKA are perfect. Score in the 800 range. Availability 100.00 percent.

Now compare with other countries. Germany T2ERFURT runs Linux. UK T2UK runs Linux. USA T2CAWEST runs Linux. Brazil T2BRAZIL runs Linux. FreeBSD only shows up in Japan, T2GB in the UK, T2HUB1, and a few small servers.

So the question is valid. Why is Japan different?

2. The Software Is The Same: aprsc Runs On Both

Every T2 server in that list runs aprsc. This is a daemon written by Hessu Lahtinen, OH7LZB, from Finland. It was developed on both FreeBSD and Linux from the start. It compiles cleanly on either one.

aprsc has a simple but critical job. Listen on TCP port 14580. Accept connections from APRS clients and IGates. Filter duplicate packets. Forward traffic to upstream hubs. It needs to handle thousands of concurrent sockets. Each packet is only 100 to 300 bytes.

The bottleneck is not CPU gigahertz. The bottleneck is the kernel network stack, context switching, and interrupt handling. The OS that handles sockets most efficiently wins.

FreeBSD’s TCP/IP stack is a direct descendant of 4.4BSD. That is the reference implementation of TCP/IP. Linux’s network stack evolved fast and added new features like eBPF, XDP, and BBR. Both are good. The philosophy is different.

3. Philosophy: Why FreeBSD Fits Japanese Engineering Culture

To understand the OS choice, you need to understand three things about Japan. The concept of monozukuri, the requirement for uptime, and the history of BSD in Japan.

3.1 Monozukuri: Build It Once, Build It Right, Let It Run For 10 Years

Monozukuri is the Japanese ethic of craftsmanship. It means build something with care so you do not need to touch it again. The Shinkansen runs on time because of monozukuri. Toyota factories have near zero defects because of monozukuri.

FreeBSD has the same approach. Release cycles are slow. FreeBSD 13 came out in 2021. FreeBSD 14 came out in 2023. Each release goes through heavy QA. APIs do not break often. A driver that is merged gets maintained for ten years.

Look at the Changed column in the status. T2OSAKA last changed 2025-07-05. Over a year with no updates, yet availability is 100 percent. T2FUKUOKA last changed 2026-04-21. Japanese sysadmins do not like to update every week. They want to set up, tune, and then leave it. FreeBSD gives them that peace of mind.

Linux is different. Kernel 6.1, 6.2, 6.3 ship fast. New features land fast. That is great for cloud. But for an APRS server where you want 99.99 percent uptime, fast can be a risk.

3.2 Uptime Is Everything

APRS-IS Tier 2 is not a toy. If T2OSAKA goes down, the whole Kansai region can go blind. IGates cannot upload positions to the internet. In Japan, where earthquakes and tsunamis are real threats, APRS is part of the emergency backup plan. During the 2011 Tohoku earthquake, APRS was used to track aid.

That is why the Avail column matters. T2OSAKA 100.00 percent. T2FUKUOKA 100.00 percent. T2UK 99.90 percent. A difference of 0.1 percent over 30 days is 43 minutes of downtime. In an emergency, 43 minutes is a long time.

FreeBSD is famous for uptime. There are FreeBSD servers with five years of uptime without a reboot. Kernel panics are rare. Memory leaks are uncommon. Upgrades do not force a reboot unless the kernel changes. For a Japanese sysadmin running a server as a volunteer, uptime without drama is gold.

3.3 The History of BSD in Japan: From Universities To Commercial Use

Japan was one of the earliest adopters of BSD outside the United States. In the 1980s, universities like Keio and Tokyo University used 4.2BSD for networking research. From there, a generation of Japanese developers started contributing to FreeBSD, NetBSD, and OpenBSD.

Big examples. Juniper Networks uses FreeBSD for JunOS. Nintendo Switch OS is based on FreeBSD. Panasonic and Sony have shipped products with it. So when a Japanese engineer needs to build a server, FreeBSD is not foreign. It is like Ubuntu in other countries. Everyone knows it.

The ham radio community in Japan also has many professional engineers. JARL, the Japan Amateur Radio League, had 1.2 million members at its peak. Many members work at NEC, Fujitsu, Hitachi. These people use FreeBSD at work. When they set up a T2 server at home, they install what they know.

4. Technical Analysis: Why FreeBSD’s Network Stack Fits APRS

Philosophy is not enough. Let us look at technical reasons. APRS-IS has weird traffic patterns.

4.1 Many Connections, Small Packets, Kernel Bound

T2CHILE handles 1,260 clients with 897,504 bytes per second out. That is 712 bytes per second per client on average. Very small. But the socket count is high. The kernel has to do a lot of select, poll, or epoll.

FreeBSD uses kqueue. kqueue was created for exactly this case. It scales to tens of thousands of file descriptors without slowing down. Linux has epoll which is similar. But kqueue has been mature since FreeBSD 4.1 in 2000.

For aprsc, kqueue gives an advantage when clients connect and disconnect often. APRS clients on mobile radios do that. A satellite passes, the client connects for five minutes, then drops. kqueue handles that churn efficiently.

4.2 Zero Copy and Sendfile

APRS servers do a lot of forwarding. A packet comes in from client A, then goes out to client B, C, and D. No need to change the data. FreeBSD has sendfile and zero-copy sockets that optimize this path. Data goes from kernel buffer straight to the NIC. No copy to userspace.

Look at T2FUKUOKA. 269 clients, C load 79.5, B out/s 36,285.
Compare T2TOKYO Linux. 256 clients, C load 79.7, B out/s 15,170.

Clients and CPU load are almost the same. But FreeBSD pushes 2.3 times more data. That means per CPU cycle, FreeBSD sends more packets.

In a data center, that difference is electricity cost. For a ham who pays the power bill himself, that difference matters.

4.3 PF: A Packet Filter That Is Sane

All APRS servers face the internet. They need a firewall. Linux uses iptables, nftables, or ufw. FreeBSD uses PF from OpenBSD.

PF config looks like this:

pass in on em0 proto tcp to port 14580
block in all

Simple. Stateful. Rules are read top to bottom. Japanese sysadmins like it because it is easy to audit. In security, easy to audit means safe.

PF is also fast with large state tables. An APRS server has thousands of states because of thousands of clients. PF handles it without eating CPU. That is why T2OSAKA has a score of 815 with 304 clients.

4.4 Jails and VNET: Full Isolation

Some Japanese sysadmins run aprsc in a jail with VNET. That means the jail has its own network stack. If aprsc gets exploited, the attacker only gets the jail. He cannot see the main host.

Linux has Docker and network namespaces. But VNET in FreeBSD is a full stack. It has its own routing table, its own PF, its own lo0. It is like a VM but without the overhead of a VM. For critical infrastructure, that isolation helps you sleep at night.

5. The Score Column: Why FreeBSD Scores Are Low

In the status monitor, there is a Score column. Lower is better. The score is calculated from aprsis_rtt plus http_rtt plus user_load.

T2UK FreeBSD has score 709.2. That comes from aprsis_rtt 0.0 plus http_rtt 0.0 plus user_load 291.0 plus other penalties.

T2FUKUOKA score 807. T2OSAKA 815. T2TOKYO Linux 806. About the same.

But T2HUB1 FreeBSD score 71. That is the lowest among hubs. T2HUB2 Linux score 95.

Low score means low latency and low load. FreeBSD gets low scores for two reasons. First, network latency is consistent. Second, aprsc on FreeBSD uses CPU more efficiently when load is low. When clients are few, like T2HUB1 with 18 clients, FreeBSD is very thrifty.

6. The Human Factor: Who Runs The Server?

Technology does not run itself. People set it up.

The callsigns that run T2 Japan are old timers. JF2IWL, JI1BQW, people who have been in APRS since the 1990s. They started with packet radio on MS-DOS and JNOS. JNOS was a TCP/IP stack on DOS. Then they moved to Linux, then many moved to FreeBSD for stability.

When you have used FreeBSD for 20 years, you do not switch to Ubuntu because of hype. You have scripts. You have monitoring. You have PF rules. All tuned. Switching OS means two weeks of work. It is easier to stay.

Also, the aprsc documentation is most complete for FreeBSD. Hessu OH7LZB uses FreeBSD himself. So if there is a bug, the fix lands on FreeBSD first. Sysadmins in Japan who care about reliability will follow upstream.

7. This Does Not Mean Linux Is Bad

We need to be fair. Look at the data. The biggest server T2CSNGRAD with 1,769 clients runs Linux. T2FINLAND with 1,762 clients runs Linux. T2UKRAINE with 1,771 clients runs Linux. All 100 percent availability.

That means Linux can handle it. BBR TCP on Linux is also great for international links with high latency. If your server is in Tokyo but the client is in Brazil, Linux BBR can give better throughput.

In Japan, the choice comes down to tradition, stability, and maintainer preference. It is not an OS war. It is like choosing Toyota versus Honda. Both get you there. The mechanic just knows Toyota better.

8. If You Want To Set Up an APRS IGate, Which Should You Pick?

Based on all this, the guide is simple.

1. You want uptime, you hate updates, the server sits at a site
   Use FreeBSD. Install aprsc from ports. Set up PF with three lines. Enable kqueue. Done. You can leave it for two years.
2. You want to use Raspberry Pi, weird WiFi dongles, Docker
   Use Linux. Drivers are more plentiful. Direwolf IGate is easier on Linux. Community tutorials are everywhere.
3. You want to learn the network stack properly
   Use FreeBSD. The source code /usr/src/sys/netinet/tcp_input.c is a textbook. Read the code, compile the kernel, and you will understand TCP from the inside.

9. Conclusion: The Real Answer Why Japan Picks FreeBSD

After going through status.aprs2.net and history, the answer has five layers.

Layer 1: Performance
FreeBSD’s network stack with kqueue, zero copy, and clean TCP/IP gives better throughput per watt for APRS traffic that has many small connections. The T2FUKUOKA versus T2TOKYO data proves it.

Layer 2: Stability
FreeBSD’s philosophy is do not break things that work. Uptime of T2OSAKA at 100 percent for years. For emergency infrastructure, that is the number one requirement.

Layer 3: Security
PF and jails give sysadmins tight control without complexity. In today’s world, an exposed server should be hardened.

Layer 4: Culture
The BSD community in Japan has existed since the 1980s. From universities to industry. Ham radio in Japan has many engineers who use FreeBSD daily. When they build a volunteer server, they use what they know.

Layer 5: People
The maintainers of T2 Japan are veterans who have used FreeBSD for 20 years. Tools, scripts, monitoring are all ready. Switching OS is not a technical issue. It is a time and energy issue.

So it is not because Linux is bad. It is not because FreeBSD is magic. It is because of the fit between APRS needs, FreeBSD strengths, and Japanese engineering culture.

If you look at status.aprs2.net five years from now, I bet T2OSAKA and T2FUKUOKA will still be FreeBSD. Because of monozukuri. Build it once, let it run until the end.