Netatalk/AFPD/TimeMachine server set-up on FreeBSD-12.1

This entry is more of a memo to myself to remind me of  what the syntax is for the /usr/local/etc/afp.conf file for FreeBSD-12.1.

I’m consolidating a couple of my servers onto one physical machine (the Beelink AP35 which I mentioned a few months back)†, using FreeBSD as the OS.  Not surprisingly, the syntax for the afpd daemon‡ set-up is very different from the ARM-Linux box which is currently running that particular service (which provides a local TimeMachine server for all of the Mac users in the family).  This is the magic incantation which worked for me:-

login message = “AFP Service on \”herons\””
vol preset = TimeMachine
log level = default:debug
log file = /var/log/afp.log
uam list =,,
mac charset = MAC_JAPANESE
unix charset = UTF8
mimic model = Xserve
zeroconf = yes
zeroconf name = “Herons-Store”

[Herons TimeMachine]
path = /store/TimeMachine
cnid scheme = dbd
ea = ad
time machine = yes

The “log level” setting of “default:debug” is quite verbose, but really helps with debugging problems during set-up.  Once your configuration is up and running you can remove that line completely to go back to the default logging level of “default:note”.

The “Mimic model” setting tells the server which Apple device icon to display on the client machine.  Using “Xserve” shows a rack-mount server, but you can also try “TimeCapsule8,119” or “TimeCapsule6,116” to see two different versions of a TimeCapsule icon.

The “zeroconf” lines were essential (in my environment, anyway) to having the clients recognize the new server.

The “charset” lines are probably unnecessary (or at least will need local modification) for users outside of Japan.

†  The AP35 is classed as a “mini-pc” (basically a device aimed at the set-top box market, but with an Intel CPU, rather than ARM).  This model comes with a dual-core J3355 CPU and 4 x USB3 ports, making it quite a versatile little machine.

‡  Note that the current, “approved” method for implementing a non-Mac hosted TimeMachine is the Samba (SMB) suite.  However, the older netatalk method described above is still simpler and a lot lighter (in terms of the number of support packages pulled in when using “pkg install”) than Samba if you only want to implement a TimeMachine instance (as opposed to a general, network file server).


A neat toy (but not an ESP)

Here I go with yet another not-quite-ESP-related diversion, but one which the audience of this blog this should find interesting, I hope.

A couple of weeks back I bought a cheap USB GPS dongle from Amazon.

U-Blox USB GPS Dongle

It was amazingly cheap (the Yen equivalent of $8 U.S.) and I wasn’t expecting too much, but I have a yearning to get a local reference clock for NTP set up on my local network and I thought that, if nothing else, this would be a good starting point for fiddling around with GPS before paying for (and possibly breaking) something more expensive.USB GPS dongle, antenna side  I have to say that I’m really, really impressed with this little thing.  I’m sitting in a valley with major mountain ranges to both the east and west of me (~3,000m on each side), so I have a fairly narrow view of the sky, but this little unit acquires and holds nine satellites from inside the house and about 1.5m from the window.

The second thing I did (after verifying that the unit did actually work) was to rip the covers off to verify the make and model of the receiver chip and, as you can see from the photo above, the built-in antenna covers most of the board space on the top side of the PCB (the single, other component, top L/H side, is the green, status LED).

USB GPS dongle, component side

The component side has the U-Blox G7020-KT chip in the bottom,R/H corner.  Note that there’s no FDTI (or equivalent) chip, as the G7020 has a USB interface included.

There’s a back-up battery on the board to maintain memory contents between power cycles (which, it turns out, is critical for reasonable start-up times for GPS receivers).

Unlike another (non-GPS) dongle which I bought recently‡, this unit barely gets warm to the touch and there are no ventilation slots or holes in the plastic cover.

Anyway, for anyone else interested in playing with these beasties, here are some hints to get you started:-

  • The very first time you power on this unit, it will take up to 25-minutes to locate the satellites and lock on. Apart from a very brief flash of the green LED when you first connect it, it will appear to be dead. It’s not! Just leave it connected and it will download the data it needs (the “almanac”) from the satellites it can see and eventually the green LED will start flashing once per second to show that it is now operational.
  • After that initial connection, the unit will come to ready (green LED flashing) in only a few seconds the next time you power on. This is because it saves that initial data to internal memory (with battery back-up).
  • If, on that first power-up, you don’t see a green flashing LED after 30-minutes, it’s because the unit can’t get a decent signal. Move it as close as you can to a window, or if you have a laptop, take it outside. If that doesn’t work, grab a 1m or 2m USB extension cable from your local 100-Yen shop and move your GPS dongle as far away from the computer (and as close to a window) as you can.
  • If you’re using Windows, you can get the genuine Windows driver directly from the chip manufacturer’s web site:-      -or-
  • The chip inside this unit is the U-Blox G7020-KT.
  • If you’re using open-source, you will probably find that your OS correctly identifies the USB device as soon as you plug it in. The application you need (as already noted) is the GPS daemon, “gpsd”. When you install “gpsd” you’ll get some additional helper applications bundled in, such as the invaluable “gpsmon” and “gpspipe”, which allow you to view the GPS data in several formats.
  • The device which you use to connect to the USB dongle will be different between various OSes. OpenBSD and FreeBSD will see it as /dev/cuaU0. Linux will see it as /dev/ttyACM0 or /dev/USB0.
  • To run gpsd you should use the “-n” option (“no-wait” – don’t wait for a client to connect before handling GPS data) and the device. So something like this:- /usr/local/sbin/gpsd -n /dev/cuaU0
  • After starting gpsd you should be able to run gpsmon (just type “gpsmon”) and see data coming from the device.
  • If you want to run your GPS dongle as a local source for the NTP daemon, you still need to start “gpsd” (and it’s important to use that “-n” option in this case). The gpsd process will automatically populate shared memory segments, which the ntpd daemon can then read to get time information (you may have to check your OS for sysctl settings for PPS to get this working). There are notes in both the ntpd and gpsd manual pages on how to do this. So far I have only managed to get ntpd to use the GPS embedded time information, not PPS.

As you can see from the photos above, the board has most of the components (including the battery and the G7020-KT chip) on one side and the antenna on the other. The green LED is on the same side as the antenna, so when you position your USB dongle, you should always have the green LED facing –upwards-. If your USB forces it to be downwards (unusual) or sideways (fairly common), you might want to buy an adapter or extender cable to ensure that you can position it so that the antenna (and LED) are pointing upwards.


‡ – A generic, black SDR dongle, bought for the advertised “R820T” tuner chip and specifically for receiving 1090Mhz ADS-B traffic from aircraft flying overhead (see the previous post on “PlaneSpotter”).  Not only does this thing get hot, it -doesn’t- have an R820T tuner chip at all (they use a cheaper and completely useless NC00012 tuner, which has a frequency range which cuts off at 985Mhz, so it doesn’t even cover the ADS-B band).  If you want to play with SDR (and especially ADS-B), save your money and buy a NooElec “Mini 2+” bundle (directly from instead.  It has an R820T2 tuner chip, plus a temperature controlled, 0.5PPM accuracy oscillator and comes with a “starter” antenna and a remote control unit (??? don’t ask me …I have no idea why!) for $21 U.S. + $5 postage to anywhere in the world.

A non-ESP8266 aside …Getting FreeBSD 10.2 to boot on the CuBox-i4P.

As with the previous post, please forgive this essentially non-ESP8266 related article (it is actually loosely connected, as the CuBox-i4p will be a gateway server).  Normal (ESP8266) service will be resumed as soon as possible.

As you may have seen from the previous post, I’m having difficulty getting OpenBSD installed on the CuBox-i4p (four-core ARM with 2GB of memory and a Gbit Ethernet interface).  As I wasn’t getting anywhere fast with OpenBSD, I decided to give FreeBSD a go, as I already have an ARM box (an RPi-B) running 10.2 quite happily.  Downloading  the FreeBSD release was a doddle (once you realize that you can ignore the “build using crotchet” advice scattered around on the web) and I dd’ed it to an SD card without any special, magical options.  Booting wasn’t quite so trouble free, though.

Having learnt (a little) from the OpenBSD experience, I plugged the USB keyboard into the bottom port, inserted the newly minted SD card and powered on.  The monitor sprang into life and the SolidRun header appeared (Yay!), but there was no countdown from U-Boot, so there was nothing to interrupt with a key-press.  And there it stuck.

It seemed likely that the CuBox was squirting boot info to the semi-secret micro-USB port, so I dutifully connected up my laptop and started “screen” (and, in yet another aside, I’d just like to say a big “Thank You!” to the guys and girls at the Technical University of Berlin for a program which has been invaluable to me for more years than I care to remember) and found myself at a “loader>” prompt.  Not quite what I’d expected, or hoped for, but at least there was life in the little beastie.  Typing in “boot” got me a semi-sane looking initial boot sequence, but immediately after starting to load from the SD filesystem it bombed out with “No device tree blob found”.  Duh!

On my previous foray into the land of U-Boot I was impressed how versatile it was and how easy it was to boot the OpenBSD installer from my tftpboot server.  Having said that though, I’m definitely a U-Boot newbie and, besides, it looked rather as though the problem lay with the FreeBSD loader, rather than U-Boot itself (which rather surprised me, as I’d assumed that the 10.2 release would just work — feel free to correct me if you know that I’m pointing the finger of blame in the wrong direction).  Anyway, I vaguely remembered a short thread on the FreeBSD mailing list about boot problems with the Hummingboard (another SolidRun product) and, in the course of searching for that thread, came across another, much longer one where the inimitable Ian Lepore came up with the answer:-

           setenv fdt_file imx6q-cubox-i.dtb


It took me a little while to realize that this was, in fact, to be executed from the U-Boot prompt, not the loader, but once I’d restarted, interrupted the countdown from the console and typed in the magic incantation, everything sprang into life and the kernel loaded without a problem.  It turns out that U-Boot passes some environmental variables to the FreeBSD loader and, for whatever reason, the initial set-up of those variables isn’t working quite right for the SolidRun hardware and, while the device-tree blob file (under /boot/dtb) is actually there, it’s not being correctly identified.  The setenv command (above) sets the correct file name in U-Boot, which is then imported by the loader, leading to much joy and jubilation.  The saveenv ensures that the variable remains set between reboots.  Once your FreeBSD system comes up, you probably still won’t have anything on the monitor, but you will be able to access your system via the network (remember, SSH root access is disabled, so use the “freebsd” username [passwd “freebsd”] to access the system and then su to root from there).

So there you have it …even if we can’t get OpenBSD to install quite yet, we can still get FreeBSD up and running (and, for those people who are about to leave a “Why don’t you use Linux, it just works” comment, I would ask you in return to try this little experiment — boot a *BSD system and a Linux system.  On each machine, type “ps ax” and then for each running process just try doing “man <process-name>” and let me know how you get on).  😛