Serious Computer Business

Hold on to your hats, HaLow is here

2026-07-22T22:08:54+10:00

I’ve been waiting a long time for WiFi HaLow (802.11ah) to show up. For the unaware, this is a standardised variant of WiFi using the 900 MHz ISM band to provide range over 1 km with a corresponding lower throughput—up to tens of Mbps.

The standard was published in 2017 but for a long time the only available hardware was pretty specialised and I stopped paying attention. Manufacturing has increased and around 18 months ago Heltec started selling a properly convenient USB/ethernet bridge device, the HT-HD01. Now that I know they exist, I have ordered four of them for mesh experiments. These units use a chip designed by Morse Micro, which I am proud to discover is an Australian company[1].

So what’s the big deal? Well, general consumers have had a pretty annoying range of communication technologies to choose from. We have regular fast WiFi, of course, with its tens-of-metres range. 2.4 GHz goes a bit farther than 5 GHz but competition for channels is fierce and microwave ovens are a natural predator. Bluetooth 5 Low Energy has its wonderful Coded PHY which lets you trade off bandwidth to get up to 1 km range, but it’s really very slow and you’ll be lucky to find an API for it outside of Android. Then there’s LoRa, which can work up to around 10 km, again with very low throughput. I’ll have more to say about LoRa shortly.

We’ve always been missing the happy middle. Now HaLow is here and that’s exactly what it offers. What can we do with it?

Cover large properties with internet access. Or stick an AP on your roof/balcony and enjoy connectivity on your walk.
Offsite backups.
24/7 LAN party with your mate who lives a block away.
Community WiFi projects (this is the one I’m eyeing off).
Probably lots more!

Of course, we’re not strictly limited to what we can buy off the shelf. There’s always amateur radio, the main downside of which is that you can only talk to other radio amateurs. For community/mesh networking this has some upsides—amateurs are generally well-behaved and the legal requirement to identify stations gives you out-of-band ways to deal with bad actors, which means you don’t have to solve every aspect of abuse handling in the protocol itself.

One thing that’s particularly cool about the HT-HD01 is that it supports 802.11s, a standard protocol for mesh networking. Here, stations can work together to form an encrypted mesh network. With the appropriate configuration your end devices can see a flat Ethernet segment, as if they were connected to the same switch, and the mesh routing is handled for you behind the scenes. That’s pretty neat.

Still, not everybody is satisfied with 802.11s as a multihop router. One of the most popular mesh-routing protocol families is called BATMAN, which is implemented in the Linux kernel as batman-adv. Using something like OpenMANET it happens that you can use 802.11s for all of its underlying connectivity and encryption but disable just the mesh forwarding, stacking batman-adv on top instead to cover that aspect.

I am curious to see how well these could work for a community WiFi deployment. It’s a bit of a harder challenge to get going. Even if the advertised 1–2 km range is realistic you need significant density to get a usable mesh. Within that usable mesh, though, suddenly so much is possible. Not just IRC: actual web pages, forums, email, images, PDFs, even VoIP or games if the latency is good enough. This is the kind of speed where it’s no longer just a poor backup to the “real internet”. If you rig it up in a sufficiently reliable and convenient manner it could be your first choice for local communications, not just something you reach for when Discord stops working.

And that’s my main gripe with MeshCore/Meshtastic, which are based on LoRa. They work for a low-volume text-based group chat containing only short messages. On the popular MeshCore “Mid” preset a 100-byte packet takes 0.55 seconds of airtime. That’s fine for what it is but it doesn’t really supplant anything. Good for an emergency or bushwalking; an idle curiosity when life is proceeding normally.

My other gripe with LoRa is that it’s a proprietary modulation scheme. The devices may be inexpensive but at the end of the day it’s using a patented and licensed technology. I would prefer to use an open standard where possible.

So I am looking forward very much to playing with these devices and seeing what they can do. If you live in Hobart and feel interested in doing some HaLow meshing, drop me an email.

I was moved to take a peek at their careers page but, alas, all of their technical roles are on-site up in Sydney. That’s not happening. ↩︎

Automatic JavaVM and Context detection using Rust on Android

2026-07-23T21:35:22+10:00

When you’re running Rust code in the context of an Android app, if you want to work with Android-specific functionality over JNI you tend to need three things:

A reference to the running Java virtual machine.
A reference to a suitable Context, often the ApplicationContext.
Some helper code on the Java side to provide APIs with required callbacks, and so on.

My cross-platform crate netwatcher has to do all of these when it finds itself running on an Android. It handles items 1 and 2 in a very straightforward manner: it exposes a public function where you pass in both of them. It’s up to the developer to do the appropriate plumbing to call through from Java or Kotlin, passing along their Context object. For item 3, I was happy to discover (that is, copy from someone else) a fiddly-but-dependable technique involving injecting DEX bytecode at runtime, which I wrote about previously.

As a crate developer, the holy grail is to get all of these runtime dependencies automatically without the end user having to do anything other than put the crate in Cargo.toml and use the API normally. They will be sad if their code suddenly breaks weirdly when they cross-compile it to Android. The difficulty level is increased by being a mere dependency within a larger Rust binary—if we’re just one piece of the final .so then we can’t/shouldn’t hook into JNI_OnLoad (without coordination through the final library), which is otherwise a reliable way to get the JavaVM* pointer.

The other day I was following some links between issues on GitHub and I noticed that the Matrix Rust SDK has apparently solved items 1 and 2, making them entirely automatic (PR #1, PR #2). I was intrigued and went on a deep dive to see how this worked. What I found is… well it’s pretty out there. For now I’ve decided to leave netwatcher the way it is, even if it’s more annoying for the developer.

The hacks involved are pretty impressive so here I want to dissect how they work and briefly discuss the risks. To be clear, I’m not trying to put anyone on blast for writing or using these techniques. It’s a noble cause and if you get it wrong it’s probably just going to crash.

Let’s begin with item 2 since it’s more straightforward. There is a class in Android called ActivityThread which you won’t find in the documentation. It has a static method currentActivityThread(), and when you get the instance back you can call getApplication(). This returns the Application that you can use as a Context. JNI can give you a reference to the class and help you call the methods. Too easy.

From the Matrix Rust PR:

// Get the current activity thread
let activity_thread = env
    .call_static_method(
        "android/app/ActivityThread",
        "currentActivityThread",
        "()Landroid/app/ActivityThread;",
        &[],
    )?
    .l()?;

// Then get the application context
let context = env
    .call_method(activity_thread, "getApplication", "()Landroid/app/Application;", &[])?
    .l()?;

The problem is that ActivityThread and its methods aren’t officially part of the Android SDK and there are policies around using non-SDK interfaces. When I look up currentActivityThread() and getApplication() in their spreadsheet they are both marked unsupported. This means Android turns a blind eye: the call will be permitted, but they’re allowed to break how this works at any time for any reason.

Going by a quick GitHub search this technique gets a fair amount of use but it still gives me pause. I don’t want to suddenly have to rearchitect my library because a new version of Android changes how ActivityThread works, or handle bug reports from people who are running strange OEM Android distributions where up is down and down is up. For now I intend to stick with the supported API.

For item 1 we must turn to the crate jvm-getter, which is where Matrix has ended up. This crate helpfully begins its README with a warning icon and suggests alternatives.

The game here is to locate and call a function called JNI_GetCreatedJavaVMs. This is an official JNI invocation function that gives you a list of JavaVM* pointers. In an Android app you would expect there to be just one VM, so you can pass it a 1-length array and now you have the pointer you need. This function is relatively unusual in JNI because it’s free-standing, an exported symbol you can look up. For most JNI work you would instead start with a JavaVM* or a JNIEnv* and use its function table.

This function has always been exported. What has changed over time is whether it can be discovered by application NDK code. Up to API level 23, you could use dlopen and dlsym to look it up by name and then call it. In API levels 24–30 linker namespaces were introduced and JNI_GetCreatedJavaVMs was no longer accessible, so dlsym fails. Then from API level 31 onward, Android made libnativehelper.so a public NDK library and this JNI function became available to dlsym officially.

This quirk bit Matrix: originally they used libloading (a cross-platform wrapper around the dlopen/dlsym technique) to look up the symbol and call it (PR #1). A bug report came in that it crashes on Android 11 and they switched to using the jvm-getter crate, which offered a workaround when dlsym fails.

So, that workaround. Buckle up, kids. What it does is this:

Use a system property to learn the name of the Android runtime library, typically libart.so.
Use dl_iterate_phdr to walk all the shared objects that have been loaded into the current process. For each one, this invokes a callback.
In the callback, look for the one corresponding to libart.so. When you see it, record the base address at which it’s been loaded into memory, and the full path on disk to the ELF file.
Read the contents of the ELF file into memory.
Use the goblin crate to parse the ELF file, find the symbol table, and locate the symbol whose name matches JNI_GetCreatedJavaVMs.
Take that symbol’s relative address.
Add the symbol’s relative address to the base address of libart.so which was recorded earlier.
Cast this to a function pointer and return it to the caller, which then calls it to find the JavaVM.

Now that’s persistence. Notice that the linker namespaces aren’t an isolation boundary. If you can find the address, you can still call it.

While this is plainly nuts, on balance it doesn’t seem too bad. There’s nothing wrong with locating JNI_GetCreatedJavaVMs with dlopen and dlsym—Android explicitly makes it available to find on most modern versions and this will be a reliable method for item 1 going forward. The tricky part is the gap in API levels where the symbol isn’t readily available, if you don’t want to drop support for older devices yet.

The thing about the ELF-parsing workaround is that all the relevant Android versions are in the past. They’re old phones or tablets that aren’t getting updates. libart.so isn’t going to wake up one day with stripped symbols[1]. If this workaround turns out to work well across a range of device types then it’s probably going to keep working.

Unfortunately, solving item 1 alone isn’t enough to simplify my public API. If I’m not prepared to use an unsupported method to get the Context then I need a configuration method anyway, and it’s just as easy to grab the JavaVM* at the same time.

We just need a slightly better way to get an application context from the NDK and everything will be perfect…

I suspect jvm-getter could be made more resilient here by searching dynsyms instead of syms. Since the JNI_GetCreatedJavaVMs implementation has to be exported, it must be named and cannot be stripped from this particular symbol table. ↩︎

Using local DeepSeek v4 Flash in Xcode

2026-08-05T15:07:20+10:00

I’m rather pleased. I’ve been able to bolt together enough pieces of software that I can now run DeepSeek v4 Flash with native MXFP4 routed-expert weights on my MacBook Pro, not only via a CLI harness like OpenCode, but also through Xcode’s native “intelligence” integration.

Before you get too excited please realise that I’m running this on a ludicrously expensive M5 Max with 128 GB RAM. However, I am hoping that the upcoming Qwen3.8-27B release will be awesome and it will be practical to have a similar workflow with a considerably more modest unified RAM budget.

This is the stack I’ve ended up with:

Xcode Intelligence configured with a custom ACP agent
OpenCode running as opencode acp
antirez’s ds4-server
DeepSeek v4 Flash: the new 0731 update[1]

To prove it works I typed a short prompt into Xcode—I wanted a Mac SwiftUI application to help me practise cardinal numbers in Polish. It whirred away autonomously for about 90 minutes, filling the context up to 95,200 tokens, and produced an app that more or less did what I asked. I spent an extra half an hour tinkering interactively through the chat interface to fix a few specification issues[2] and a couple of layout bugs[3]. The session started at around 17 output tokens/sec and dropped to about 15.

For a fun twist, I made the app itself also use the ds4 chat completions endpoint to provide some dynamic feedback on what the user typed, particularly to explain any mistakes. (As you can see, the “system prompt” needs improving.) DS4F happens to be weirdly good at handling broken Polish and explaining grammar. I’ll have more to say about that in a future post. I hope it got it right in the code. Otherwise I’m going to be practising the wrong thing.

I have no strong opinions about the Swift code. From a quick skim it all seems pretty sensible and it made proper use of JSONSerialization and URLSession for making the HTTP request to the completions endpoint.

Assuming you’d like to try something like this yourself[4], here are some notes and observations.

Let’s start at the bottom of the stack. Since I began my experiments antirez has now merged all the relevant work so you should be able to just clone the ds4 repo, run make -j and run ds4-server. I’m executing it like this:

"$HOME/ds4/ds4-server" \
    --ctx 393216 \
    --kv-disk-dir "$HOME/.ds4/server-kv" \
    --kv-disk-space-mb 100000 \
    --host 0.0.0.0 \
    --ssd-streaming \
    -m "$HOME/ds4/gguf/DeepSeek-V4-Flash-MXFP4Experts-F16HC-F16Compressor-F16Indexer-Q8Attn-Q8Shared-Q8Out-chat-v2-mxfp4-0731.gguf"

Most early benchmarks indicate that DS4F works best with “maximum” thinking. DeepSeek recommends only using max thinking with a 384K context size, which is enforced in ds4-server. Unless you choose a context of at least this size you’ll automatically get downgraded to high thinking. This comes with a RAM cost but it’s mild next to the weights themselves.

You’ll want to enable SSD streaming unless you have a Mac with a stupendous amount of RAM. Note that so long as you’re not going into heavy swapping this will cause large amounts of disk reads rather than writes so it shouldn’t contribute unduly to SSD wear. To give you an idea, across this coding session ds4-server has read about 22 TB from disk.

Since I have free disk space and generating the tokens is relatively expensive I choose to have a fairly large on-disk KV checkpoint cache. 100 GB is probably overkill for most purposes.

If you’re only using it locally you probably won’t want to bind to 0.0.0.0 but I sometimes access it over Tailscale so an endpoint available over LAN often suits me.

So you run that and now you have a standard OpenAI-like chat completions endpoint running at http://127.0.0.1:8000/v1.

Next we need OpenCode, which I have installed through Homebrew. It includes an implementation of Agent Client Protocol, which is what Xcode needs.

Now, in my OpenCode config my model is defined like this:

      "models": {
        "deepseek-v4-flash": {
          "name": "DeepSeek V4 Flash (ds4.c local)",
          "reasoning": true,
          "limit": {
            "context": 393216,
            "input": 393216,
            "output": 384000
          },
          "options": {
            "reasoningEffort": "max"
          },
          "variants": {
            "low": {
              "disabled": true
            },
            "medium": {
              "disabled": true
            },
            "high": {
              "disabled": true
            },
            "max": {
              "reasoningEffort": "max"
            }
          }
        }
      }

And at the top level I have:

  "compaction": {
    "reserved": 65536
  },

This is doing a few things. It forces DS4 to always use max effort even if ACP might try to default to a weaker level. It tells OpenCode the context size available. It allows large responses, which is important when using max thinking because the default limit is 32K and this model will quite happily think for more than that at a time. The reservation gives more breathing space for compaction. Having a large output limit can mess up OpenCode’s calculation of the compaction point, so it will constantly be compacting at a small context size. I fixed that by setting a large input limit too.

Note that you also need an environment variable OPENCODE_EXPERIMENTAL_OUTPUT_TOKEN_MAX=384000 in Xcode's settings, and in your shell if you use OpenCode there.

While you need to have ds4-server running yourself, Xcode will launch OpenCode on its own when you start a conversation. You need to configure it through Xcode’s Settings in the Intelligence section. Add opencode as the path, and scroll down to set acp as the argument and the above environment variable.

Like me, you may be confused by how you actually talk to it, since Xcode defaults to Codex. Once you click the Coding Assistant button in the top left, you then need to click on the little “New message” icon to get a dropdown where you can choose the agent you just added. When you type in a message and hit enter it will start OpenCode in the background. After 20–30 seconds of I’m-not-sure-what-exactly, requests start hitting DS4.

For some reason my Xcode uses a lot of CPU while DS4 is thinking. Maybe it’s constantly re-rendering the thinking box as reasoning streams in? If I swap away from the coding assistant back to the project view then it settles down. It’s clear that the Xcode UI designers were not anticipating DS4 quantities of thinking—when I click on a large one it can take a full couple of seconds for the scrollable popup to appear.

If you get all that right, you should be off to the races. I’m looking forward to trying this out with the new Qwen model too. It’s unclear to me whether Xcode will make it easy to select multiple open models through OpenCode itself or whether I’ll need to set up wrapper scripts and create two ACP entries if I want to toggle between them.

Apparently so called because it was released on July 31. ↩︎
Unsurprisingly in hindsight, it turns out that if you select random numbers between 1 and 999,999, most of the time you’re writing out 6-digit numbers like 556,195. This feels pretty laborious. Most of the grammatical trickiness a student of Polish needs to practise can be reproduced with smaller numbers. ↩︎
DeepSeek v4 Flash only has text inputs so I can’t just feed it a screenshot. It would be an interesting follow-up to see if I can get it to use a textual description of where the components are laid out in the actual window and use that as feedback to determine whether it wrote the SwiftUI it intended. ↩︎
Be aware that DeepSeek v4 Flash cloud inference is extremely cheap. That’s a much more cost-effective way to get tokens than buying hardware with lots of RAM. However, there will always be some people who are interested in local inference, for various reasons. You know who you are. ↩︎

WiFi HaLow on Phones

2026-08-09T21:37:02+10:00

In a recent post I was getting excited about HaLow and I mentioned that I had some HT-HD01 units on order from Heltec. Those have now arrived and my excitement continues. These units are very cool for three main reasons.

It’s affordable. They cost 69 USD each. Nice.

Versatile deployment modes. Out of the box you can build a standard AP/client scenario. You can also use 802.11s meshing, which I haven’t tested yet. You have the choice between NAT and bridging, so you can make it so that all the connected devices think that they’re on the same ethernet segment. You can configure it both for providing internet access and for using it as a secondary network that sits alongside your other WiFi and cellular.

Versatile local-device connectivity, especially ethernet over USB. Interestingly, these dongles do not even attempt to make themselves known to the OS as a WiFi HaLow adapter. The dongle itself acts as the host on the HaLow network and then your device is bridged over regular WiFi/Ethernet. You have three choices: connect to the dongle’s local 2.4 GHz WiFi AP; connect to the dongle’s RJ45 ethernet port; or use ethernet-over-USB via the dongle’s USB-C port.

Let’s focus on ethernet-over-USB for a moment because this is super interesting. I’ve tested this on a MacBook, an iPhone 17, and an Android Pixel 7. The Apple devices both did two things: they powered up the radio, and they added it as a wired ethernet device with zero configuration on the phone. This shows up as “Ethernet” in the screenshot above. This is significant so I’m going to spell it out in detail. If you would like your iPhone to communicate over a kilometre or two, you can plug in a device to its regular old USB-C port, and it will work. It does not need any batteries or charging of its own because it can get power from the iPhone. It does not require any pairing or user interaction. It shows up as an additional IP interface, which means that it does not displace any existing connectivity you have via WiFi, Bluetooth or cellular. Because it is a normal IP interface, it Just Works in every app that does LAN networking.

For anyone with an iPhone this is kind of amazing. Unfortunately, it did not work on the Android. For whatever reason my Pixel doesn’t come with an appropriate driver to pick up the Ethernet connectivity. It did, however, appear to power up the radio.

I mentioned before that these devices kind of default to being your primary network, where there exists some upstream gateway that is going to grant you both an IP address and internet access. This is not required. For my tests so far I haven’t gone full mesh and I’ve stuck with the simple “AP” and “STA” roles, where one radio is an AP, and the other connects as a client. With some config tweaks this coexists perfectly well with existing WiFi. I’m more interested in having HaLow as a secondary layer where you’re going to be using HaLow for a strictly P2P role with greater range.

Out of the box, one of the Heltec boxes acting as an AP will advertise itself as the default route. This is a problem if it is not actually connected to an upstream network with internet access, and you would prefer that clients used their existing WiFi or cellular connectivity to access the internet. Ultimately you can do whatever you need—under the hood it’s a MediaTek MT7628 paired with a Morse Micro MM6108 HaLow radio, running OpenWrt which is eminently hackable. You even have the option of flashing your own firmware if you want. The good news is that Heltec’s supplied user interface is sufficient to configure the DHCP server so that it will allocate IPs but not try to route unrelated traffic.

Navigate to Network > Interfaces and choose Edit on ahwlan.

Then go to DHCP Server > Advanced Settings and add a couple of extra DHCP options. The idea here is that a bare 3 will prevent it from advertising a default route, and a bare 6 will stop it advertising itself as a DNS server. This way you are free to talk to other devices across the HaLow LAN in addition to the networks you already had.

The other important thing to know is that these devices do not support wired ethernet and ethernet-over-USB simultaneously. You can toggle between these modes by briefly pressing the little button using the supplied metal widget. Everything is explained by the colour of the LED. For an AP, cyan means wired ethernet and purple means USB. For a station, green means wired ethernet and blue means USB.

The cool thing is that once you get this config locked in, it’s locked in. You can plug it in to a Mac or an iPhone and DHCP does the rest. You need only wait a minute or two for it to boot up.

I intend to put these radios through their paces—expect more posts about them!

netwatcher v0.8.0 - the AI bugfix release

2026-08-17T17:43:38+10:00

My little Rust library netwatcher has a new release and the changelog is unusually long. As you’ve probably already guessed from the title, this is because I took the time to run some LLMs over it looking for bugs and doc inconsistencies. It turns out that even within Rust’s guardrails I wrote plenty of bugs. Who could have seen that coming?

This won’t be a surprise to anyone who’s been using LLMs in 2026. There are no special tricks and you don’t have to overthink it[1]. We really are at the point where you say to any modern model “find the bugs” and it finds the bugs. It’ll even fix them too. Isn’t that magical? I may be slinging slop but darned if my library isn’t substantially better for it.

The only findings I had to reject were cases where I’m actually being sloppy on purpose. For example, some platforms have edge cases where a network’s hardware address might not be readable. I choose to leave it as a String with possible placeholder, since it kind of sucks to make it an Option for the normal case. Similarly, in principle it’s possible for an interface watcher to start failing in the middle. I choose to swallow the errors. Virtually everything was validated when the watch was first created, and transient errors will be handled gracefully by incorporating changes into the next update. Because I do this, you don’t need to check for an error every time and the code is lovely and clean. LLMs don’t enjoy this kind of corner-cutting (nor do certain humans) but I put my foot down. If there’s evidence that this causes problems in the real world then I’ll reconsider.

The majority of the bugs were the sort of things where I think “oh yeah I could see that being a problem” but it wasn’t particularly likely to come up for most users most of the time: race conditions, handling panics over FFI, unusual interface types, things like that. Pre-LLM, these are the sorts of things that would come up as intermittent faults on the bug tracker and I’d have to spend hours poring over the code and vendor docs to figure out what went wrong. I feel like I’ve done a kind of speed-run on that hardening and now it’s ready for more users[2].

That said, the most significant bugfix in this release was not detected by LLM inspection, and I’m a little surprised that it wasn’t. It fell out by accident when I added IPv6-specific integration tests and I realised that if I changed an IPv6 address on Linux it wasn’t picked up by the library at all.

The history of this bug is mildly amusing. On Linux the standard way to subscribe to IP address changes is to open a NETLINK_ROUTE socket and use group bits to indicate what event types you care about. I needed to specify the constants RTMGRP_IPV4_IFADDR and RTMGRP_IPV6_IFADDR, which I took from the nix crate. At this point, everything was correct.

Later I was trying to make this work on Android (which is a kind of Linux) and the build failed because those constants were not present in the Android version of the nix crate. To make the compiler happy I switched those constants to local definitions:

const RTMGRP_IPV4_IFADDR: u32 = 0x10;
const RTMGRP_IPV6_IFADDR: u32 = 0x20;

Unfortunately for me, this was wrong. If you look at the relevant kernel header, you can see that I copy-pasted the correct value for IPv4, then for IPv6 I used the value of the line directly underneath it, which is actually RTMGRP_IPV4_MROUTE. IPv6 really needed the value 0x100.

For whatever reason, my LLMs didn’t see this. Naively I’d have expected RTMGRP_IPV6_IFADDR and 0x20 in the same line to be a glaring, self-contained error, if you’ve been trained on lots of code where this would have been set to 0x100. Yet it didn’t, so we found the bug the boring, traditional way. (Tests.)

The best part of this bug is that as soon as I got Android compiling, I learnt that modern Android restricts netlink sockets and I was going to have to build an entirely different watcher mechanism involving their Java API. Thus I subtly broke the code for no gain whatsoever.

So there we have it. Enjoy the new release. If you’re maintaining a public library, at this stage you really have nothing to lose by asking an LLM to find the bugs. (Except for maybe getting put on strange lists.)

If you really want to know I used a mixture of DeepSeek v4 Flash and Pro and GPT-5.6 Luna and Sol, but it really doesn’t matter on a small codebase like this one. ↩︎
If crates.io downloads mean anything, usage seems to be increasing, which is gratifying. ↩︎