Blog

  • Hetzner Storage box quirks

    While troubleshooting some issues with my “Homelab” configuration I noticed some quirks in the speed I was able to achieve when connecting to my storage box:

    My “Homelab” is hosted by hetzner at Falkenstein. I use this box to host a bunch of services that I use, and at 4 arm cores it has plenty for most applications and is dirt cheap compared to what I can get now.

    I also use the Storage-box solution the offer as the backend for the bulk data.

    Recently the performance of the link between the VM and the storage box degraded significantly and I spent some time digging into what changed (I think Ive figured that out now, story for another time). Performance is now back to the region I would expect.

    What I noticed was that if I was using rsync to transfer files I go significantly faster results if I tunneled through the VM to the storage box. the only explanation I can come up with is that there is some sort of speed cap on external connections going to the storage box that is not enforced for the VM, now this could be my ISP or Hetzner, or someone in the middle (unlikely).

    Desktop --> VM --> Storage box : upload ~20.2 Mbps
    Desktop <-- VM <-- Storage box : download ~73.0 Mbps
    Desktop --> Storage box : upload ~18.8 Mbps
    Desktop <-- Storage box : download ~62.1 Mbps

    Now before we run into a replication crisis of our own I have run these tests at several times of the day the results remained comparable. I set up an SHH config for three hosts: The server, the storage box, and the storage box with a proxy jump configured to go via the vm.

    This means I can run the two commands below easily to compare the two, fstbox is configured to use the proxy jump, and box is a direct connection. I have downloaded the the speed check file from Hetzner’s servers as a baseline anyway, so I used that file and moved it around a few time.

    rsync -avz --progress fstbox:100MB.bin ~/ && rm ~/100MB.bin
    rsync -avz --progress box:100MB.bin ~/ && rm ~/100MB.bin

    Commands for the Hetzner speed test are here:

    curl -4 -w "\nIP: %{local_ip}\nTime: %{time_total}\n\n" https://fsn1-speed.hetzner.com/100MB.bin -o ~/100MB.bin

    The files available are referenced at Hetzner troubleshooting article. I was able to achieve slightly less using curl: only about 67 Mbps

    This got me thinking. If it can be faster to jump what about using the VPN which is already set up to the VM to carry the proxy jump connection? (prxbox is configured as a host using the wireguard interface)

    rsync -avz --progress prxbox:100MB.bin ~/ && rm ~/100MB.bin
    receiving incremental file list
    100MB.bin
        104,857,600 100%   10.09MB/s    0:00:09 (xfr#1, to-chk=0/1)
    
    sent 43 bytes  received 104,881,449 bytes  9,120,129.74 bytes/sec
    total size is 104,857,600  speedup is 1.00

    Something weird happened when I was just re-running the tests to show a complete suite done at a similar time. I was now testing 1GB files. and they all came in at roughly the same speed. Now my thoughts are did another process interfere with my network or

  • AP Divesight on linux (wine)

    TL;DR

    Stop ModemManager, ensure the rfcomm port is properly linked to wine (symlinks). Pair and trust the MAC address of the handset each time you connect. Expect some download failures. Success??

    The easy way:

    I as able to get AP Divesight to work on virtual box OSE without too much difficulty. after following the instructions for USB forwarding I was able to connect without any difficulty, I was even able to monitor the traffic in wireshark on the host machine. But I would prefer to run the program using wine, as it is much lighter and feels better integrated.

    Initial Attempts

    By default, Wine will try to use software rendering, which makes the main application window invisible or completely unresponsive to mouse clicks. (At least that’s what I encountered, when I revisited this program, I initially had it working fine without this workaround). Also make sure you are using a version of wine that includes the required DLLs currently winehq-staging provides this (>= 11.5).

    Using wine

    AP Divesite requires the icuuc.dll libraries. Luckily versions of wine since 11.5 include these, so at the time of writing this is as easy as installing the staging version of wine from the official repo. alternatively there are a couple sources for DLLs that work (github discussion link).

    sudo dpkg --add-architecture i386
    sudo mkdir -pm755 /etc/apts/keyrings
    
    wget -O - https://dl.winehq.org/wine-builds/winehq.key | sudo gpg --dearmor -o /etc/apt/keyrings/winehq-archive.key
    
    sudo wget -NP /etc/apt/sources.list.d/ https://dl.winehq.org/wine-builds/ubuntu/dists/noble/winehq-noble.sources
    
    sudo apt update

    Presumable the next step will change once a version greater than 11.5 becomes stable, but for now this worked for me:

    sudo apt install winehq-staging

    For a previous attempt at this project I used: https://github.com/FaithLife-Community/icu, there is a stack exchange answer here with a bash script and instructions to download and install the libraries to the wine prefix.

    1. Open your terminal and run:
      winecfg
    2. Navigate to the Graphics tab.
    3. Make sure “Allow the window manager to control the windows” is checked.
    4. Make sure “Allow the window manager to decorate the windows” is unchecked (this prevents the splash screen from trapping mouse focus).
    5. Click Apply and then OK.

    2. Launch with NVIDIA Hardware Acceleration

    To bypass the display server issues and force Pop!_OS to map the window layers correctly, you must launch the application by routing it directly through your dedicated NVIDIA graphics card.

    __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia wine ~/.wine/drive_c/Program\ Files\ \(x86\)/AP/AP\ DiveSight/AP\ DiveSight.exe
    

    Use code with caution.

    3. Create a Permanent Quick-Launch Shortcut (Optional)

    To avoid typing that long command every time, you can create a simple one-word shortcut (an alias).

    1. Open your terminal config file:
      nano ~/.bashrc
    2. Scroll to the very bottom of the file and paste this line exactly:
      alias divesight='__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia wine ~/.wine/drive_c/Program\ Files\ \(x86\)/AP/AP\ DiveSight/AP\ DiveSight.exe'
    3. Save and exit
    4. Reload your terminal settings:
      source ~/.bashrc

    Now running divesight should get you a useable window. although I still cannot get it to connect on Bluetooth.

    It Works!…Then doesnt

    Update as of 14th september 2026. I have succesfully managed to download a dive using ap divesight and wine.

    • Put the handset in bluetooth mode.
    • ensure that your bluetooth is plugged in, then run the following
    bluetoothctl
    
    [bluetooth]# remove 00:06:##:##:##:##
    [bluetooth]# pair 00:06:##:##:##:##
    [bluetooth]# trust 00:06:##:##:##:##
    [bluetooth]# exit
    • Run the following in a terminal and leave it running:
      The first line ensures that any existing rfcomm processes are closed down, the second opens and maintains a serial connection that we can use.
    sudo rfcomm release all 2>/dev/null 
    sudo rfcomm connect 0 00:06:##:##:##:## 1
    • The next command links the rfcomm0 port with COM3 inside wine. (run it in a new terminal)
    ln -s /dev/rfcomm0 ~/.wine/dosdevices/com3
    • This command pre-sets the BAUD rate and options and esnures that the buffers are flushed immediately
    sudo stty -F /dev/rfcomm0 57600 cs8 -cstopb -parenb clocal -crtscts

    Honestly I am not sure what worked in the end, but I think that some of the permissions relating to /dev/rfcomm0 were messed up and after I fix this (sudo chmod 666 /dev/rfcomm0) I was able to communicate with the handset using a python script. and then when I tested Divesight it then showed an attempt to connect with the handset going through PC link 0,1,2,3 on the screen and the button in divesight changing to verifying. I still did not get further than this and the verifying timed out or failed eventually. I had been running divesight with every QT trace option imaginable.

    Lo and behold when I ran it without logging I was able to get communication established.

    When trying to download from multiple computers you must pair and trust when switching back to a previously trusted and connected platform.

    Repeatability

    After recording a ton of downloads through virtual box and storing the bluetooth packet captures. I was able to point the finger at modem manager and other Linux services interfering interrupting the transfer. While I would occasionally be able to download data it would be unreliable and would frequently leave divesight in an unresponsive state (if you click the download button in the connect dialog but the device disconnects before the display is properly loaded). The close button doesn’t work if this happens.

    Stopping Modem manager for the duration of the download was the easiest and most reliable way of avoiding interference. still occasionally times out or fails to verify.

    To be continued

  • CIDR Calculator

    I recently needed to calculate a list of CIDR networks for VPN configuration, I came up with the calculator embedded below. Let me know what you think. Everything is stored and calculated locally, nothing is sent back to my server.

  • Subsurface dive log dive computer downloads from a Shearwater Petrel 1 on a Linux PC

    How I managed to get a Bluetooth connection working on Linux (POP OS & Ubuntu).

    First things first: make your user is in the dialout group:

    sudo usermod -aG dialout $USER

    Log out or restart for the changes to take effect.

    I had no luck with the subsurface bluetooth interface and had to pair & trust the device manually through bluetoothctl

    bluetoothctl

    If you now put your dive computer in bluetooth mode you should start seeing it advertise itself in the console as shown

    [NEW] Device 00:13:43:##:##:## Petrel
    [bluetooth]# [CHG] Device 00:13:43:##:##:## RSSI: 0xffffffc6 (-58) # <-- This is the device we are interested in
    [bluetooth]# [CHG] Device 00:13:43:##:##:## RSSI: 0xffffffbe (-66)

    copy the MAC address and enter the following two lines (still in bluetoothctl commandline)

    pair 00:13:43:##:##:##

    You will be prompted to enter a pin (0000).
    You should then see something like the following:

    [bluetooth]# pair 00:13:43:##:##:##
    Attempting to pair with 00:13:43:##:##:##
    [CHG] Device 00:13:43:##:##:## Connected: yes
    [Petrel]# Request PIN code
    [Petrel]#   1;39m[agent] Enter PIN code: 0000 <--- enter pin
    [Petrel]# [CHG] Device 00:13:43:##:##:## Bonded: yes
    [Petrel]# [CHG] Device 00:13:43:##:##:## UUIDs: 00001101-0000-1000-8000-############
    [Petrel]# [CHG] Device 00:13:43:##:##:## ServicesResolved: yes
    [Petrel]# [CHG] Device 00:13:43:##:##:## Paired: yes
    [Petrel]# Pairing successful

    then enter

    trust 00:13:43:##:##:##
    Petrel]# [CHG] Device 00:13:43:##:##:## Trusted: yes
    [Petrel]# Changing 00:13:43:##:##:## trust succeeded
    [Petrel]# [DEL] Device C8:6C:3D:##:##:## C8-6C-3D-##-##-##
    [Petrel]# [CHG] Device 00:13:43:##:##:## ServicesResolved: no

    That’s it, that should be all the command line needed.

    • Open Subsurface import > import from Dive computer or CTRL+D to open the import dialog.
    • Select Shearwater from the manufacturer drop-down
      • Select Petrel (or your own computer model)
    • Click on the ... next to Choose Bluetooth download mode
    • you should see the dialog shown below:

    bluetooth.src==

    bluetooth.src==

    bluetooth.src==

    • You should now see that the device or mount point field is populated with the correct device. And Choose Bluetooth download mode is checked.
    • Click download and new dives should start appearing in the pane on the right.

    After this I was able to import dives normally. One quirk I have noticed is that if I merge two dives (short surfacing in the dive) subsurface will always import all segments again if this is the last dive in the log as it doesn’t seem to recognize that they have already been downloaded.

    Subsurface dive log is available here for the unbeatable price of free: https://subsurface-divelog.org

  • Dewalt circular saw comparison table

    I recently bought a bundle of DeWalt tools and batteries for a very good price so the option of expanding my tool collection with a circular saw seemed quite appealing. I was lucky enough to get a couple flexvolt batteries in the bundle meaning I could potentially get a “pro” grade tool for a reseonable cost. There is a frankly bewildering array of circular saws made by DeWalt. I have tried to compare some key feature in the table below.

    DeWalt Circular Saws

    Generated by wpDataTables
  • WMS and other GIS information resources

    Some usefull mapping resources.

    JNCC

    Resources for UK marine conservation and other marine zones.

    Shows chart reporting areas, coastlines and MCZs.

    WMS URL: https://mpa-ows.jncc.gov.uk/mpa_mapper/wms

    C-Map Chart explorer

    Allows previewing C-Maps wonderful high resolution bathymetry ocean maps in a browser (Raster only in the preview).

    The android app (Free, with subscription options) has their full vector maps.

    Very nice for finding new diving spots around the coastline

    URL: https://www.c-map.com/chartexplorer/

    Garmin Chart preview

    Similar to the previous item allows previewing Garmin and Navioncs’ high resolution bathymetry charts in a browser, while their apps get access to the full vector map data.

    URL: https://maps.garmin.com/en-GB/marine/?maps=another-brand&overlay=false

    Open Sea Maps

    https://www.openseamap.org

  • OpenStick adventures Part 2: GPS

    It would be great if the GPS part of the modem could be used.

    Modem manager supports this, and it should be as simple as running the command below:

    sudo mmcli -m 0 --location-enable-gps-nmea --location-enable-gps-raw --location-enable-3gpp

    This command enables NMEA and Raw output as well as the coarse network location derived from the mobile network.

    I have yet to acquire any satellite signals.

    sudo mmcli -m 0 --location-get
    ... 3GPP Output cut ...
      --------------------------
      GPS  |               nmea: $GPGSA,A,1,,,,,,,,,,,,,,,*1E
           |                     $GPRMC,,V,,,,,,,,,,N*53
           |                     $GPVTG,,T,,M,,N,,K,N*2C
           |                     $GPGGA,,,,,,0,,,,,,,,*66
    

    The first line shows that no satellites are available and the rest just confirm that no fix is possible.

    The link below shows common NMEA sentences and how to decode them properly.

    https://pe2bz.philpem.me.uk/Comm/-%20Receivers/-%20GPS/Info-921-GPS/Site1/Gps-Diags/NMEA_sentences.htm

    Maybe I need to find a better location to put the stick and give it longer for a cold fix. The building I am in has thick stone walls and I haven’t found a suitable location for a power supply that has good visibility of the sky. I might try the conservatory over night.

    AGPS

    Augmented GPS should, in theory massively improve fix times on basic GPS devices. there are two modes of operation MSB and MSA. MSB is a simpler mode where an aGPS server is used to proved network time, this can reduce the time taken to get an initial fix. MSA lets the aGPS server carry out much more of get calculation required. This is provided by fewer aGPS providers.

    In my experimentation I was able to enable MSA, but reveived and error when I tried to enable MSB. I am currently not sure whether this is due to a configuration error (URLS and servers) or an issue with my modem.

    The flags: --location-enable-agps-msb and --location-enable-agps-msa are used to control this behaviour.

    When enabling MSB mode I receive the following error:
    error: couldn't setup location gathering: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Aborted: Couldn't enable location 'agps-msb' gathering: Failed to receive operation mode indication'

    Update 2025/01/15

    After nearly 24 hours to acquire a signal there is still no change.
    I have to assume that the antenna or other parts required for GNSS are not present or configured properly in these dongles. This would make sense if an active antenna is required or additional hardware for such a cheap device, it would have been just too good to be true.

  • Openstick Adventures

    I recently purchased a selection of cheap LTE dongles that contain the MSM8916 chip (AKA Snapdragon 410). These are available from the usual east asian websites, or for slightly higher prices on local e commerce sites.

    They provide a similar compute performance to a raspberry pi zero in a very similar form factor. the primary

    Here is an overview of the specs:

    https://www.qualcomm.com/products/mobile/snapdragon/smartphones/snapdragon-4-series-mobile-platforms/snapdragon-processors-410

    I want the companion computer to achieve several things:

    1. Forward MavLink messages between the ground station and the Flight Controller (FC), securely, either via either wifi (direct) or via LTE.
    2. Serve as a platform for onboard logic to add higher level functionality to the drone.
    3. It may be possible to enable the GNSS (GPS) receiver onboard the modem. this could then be used as a backup location source for the FC

    There are a couple options for connecting to the FC: directly over serial; if the serial port on the dongle can be used for a purpose other than the default serial console then this would be the most direct and easiest solution. As an alternative to this the dongle support both gadget and host USB modes which could be used to connect to the FC over USB. this would open up other options for USB devices to be used on the drone, such as a webcam.

    I initially purchased a single stick which turned out to be a UZ801 3.0 after flashing it with debian and running some benchmarks and failing to get the modem to connect to LTE I decided to purchase a few more to play with and hopefully find one that “Just Works ™”. I ordered a pair of dongles like the first, with one being the same revision as the first and the other a slighly later model 3.2 this is missing the eSIM chip that is present on th earlier version.

    Wim van ‘t Hoog has posted the firmware he used for the same purpose and I have used this primarily where I used bookworm: https://wvthoog.nl/openstick/

    I also bought a version that includes a screen, I am hoping that this too may be possible to use in linux at some point. I am not entirely sure what the the model of display is.

    Feature\StickBlack-1Black-2White-1MF880s
    ModelUZ801 3.0UZ801 3.2UZ801 3.0MF880S
    DebianYes (buster & bookworm)Yes (Bookworm)still running stock firmwareNot tried
    WiFiYesYesYesYes
    LTENo- Sim enabled, modem enabled, error on registrationYes, fully functionalYes (in stock firmware)Yes (in stock firmware)
    eSIM N/ANot TriedN/ANot Tried
    GNSSNot TriedNot TriedNot TriedNot Tried
    USB HOST ModeNot TriedNot TriedNot TriedNot Tried
    USB GadgetsEthernet (default)Ethernet (default)
    HW UART (other than serial console)
    Yes,
    SystemD script to disable on successful boot
    Yes,
    SystemD script to disable on successful boot
    Yes

    Security

    Once I had the LTE modem working on the second stick I tried installing wireguard. I already have a wireguard network and I thought that adding the stick to this existing private network would be the simplest method to achieve some level of privacy.

    Unfortunately although wireguard installs fine through sudo apt install wireguard the required kernel module was not compiled in, more specifically it was compiled as a module and I was not able to enable it.

    A (temporary) fix for this is to install wireguard-go, this is a userspace implementation of the wireguard protocol and plays nice with wg-quick and wireguard commands installed.

    I also configured several WiFi networks so that regardless of which building I am in the stick connects to a known network if possible. it also automatically connects to the wireguard network and displays its status via the blue LED on the stick (rapid flashing for internet connected, slow flashing for wireguard connected). So now I know immediately whether the stick is available on a known private IP.

    Update 25/12/24

    I have been using some tools from the repo below to configure the system on boot, I have tweaked some values to better suit my needs.

    https://github.com/hyx0329/openstick-failsafe-guard

    I now have it reconfigure the serial port from a console to the MAVLink port once the succesfull boot has been confirmed.

    Update 2025/01/19 (Getting into EDL mode)

    There are two methods of getting into EDL mode once the stick as been flashed with debian:
    1. Hold the button on the stick for 5 seconds while plugging in. This gets you to fastboot. Then on the host use the command fastboot oem reboot-edl .

    2. the other is to short two pads on the stick itself while plugging the device in. This method is fiddly but more reliable if you have really messed up

    When trying to restore a backup using the EDL tool. I have encountered an issue where the tool gets stuck with the last message being main - Device detected :). Rebooting the device into EDL again fixed this issue for me.