I'm Watti.
Curious by nature.

I still haven’t landed on a proper name for this one, so for now it’s CarMAN. The name grew out of CarFi, the Wi-Fi network my Connected Colorado already broadcasts. Once the car had its own network, it felt natural to build a management plane and a visual dashboard on top of it: something I could run on a tablet mounted in the car, and also as a mobile app when I’m away from it. The app itself is an iOS app I designed with the help of AI.

The brains: a Raspberry Pi

Behind the scenes, everything runs through a Raspberry Pi in the vehicle. It connects to CarFi, with a failover 4G Ethernet connection in case that drops out. Attached to it are an NESDR Nano 2 USB SDR (software-defined radio) receiver, a YARD Stick One transceiver, and the Pi’s own built-in Bluetooth. Between them, those three give the Pi a way to listen to, and in some cases talk to, almost everything electronic in and around the vehicle.

Reading the car itself

For data from the car’s own ECU, I’m using a basic OBD-II Bluetooth module. That gives me engine RPM, temperatures, fuel levels, battery levels and similar statistics, pulled straight from the car.

Making sense of the battery system

My Colorado runs a Kickass 12V dual-battery system in the canopy, which has its own built-in Bluetooth for the BMS (Battery Management System). Once I’d connected that Bluetooth to the Pi, I could start sniffing the packets of data the BMS was sending.

What followed was countless hours of working out what each packet actually meant. I used Python to interpret the data, map it to the correct packets, and line it up with the real battery information: current battery charge, current discharge rate, battery health, charge rate and so on. That then went into a simple PHP page inside CarMAN, showing the battery statistics alongside the OBD data from the car.

Knowing where the car is, and where it’s been

The next step was tracking. I bought a Teltonica GPS tracker through CoreGPS, and with great support from Daniel Nagy, had it up and running quickly.

The data it gives me is genuinely useful, not just a dot on a map:

• Mapped trips, and how far I’ve travelled over a period (currently by month).
• The actual routes taken.
• Any extended stops along the way.
• Speeds along the route.
• Geofences, with alerts whenever the car arrives at or leaves a fence I’ve set up.

Controlling the 12V panel

Then came the hard part. I have a wireless 12-gang 12V panel controlling various things on the vehicle, and I wanted to switch those on and off from anywhere, in keeping with the whole idea of CarMAN. This is where the YARD Stick One and NESDR Nano 2 came in.

The panel transmits on 433 MHz, and it wasn’t straightforward. Each of the twelve switches is its own piece of data, but the remote also sends a randomised string that only the wireless controller can decipher: a rolling code. That turned into a genuinely difficult problem over several days of testing.

Eventually I worked out an approach that lets me approximate the required string within a small margin of error, and for the most part it works. That gave me control of switches 1 through 12 from a simple PHP page and from the CarMAN app.

It didn’t stop there, though. Some of those switches power things that should never be turned off by accident, like the fridge, the Raspberry Pi itself, and a few other devices. So I added code to make sure those particular switches aren’t executable, whatever else happens on the panel.

Where it stands

At its current state, this has been a fully hands-on project: a lot of testing, a lot of trial and error, and a much better understanding of how devices talk to each other over BLE and 433 MHz than I had when I started. Between the Pi, the SDR gear, the BMS reverse engineering and the GPS tracking, CarMAN has turned into a genuinely useful way to see and manage what my car is doing, whether I’m in it or not.

I’ll keep documenting this one as it develops, including, hopefully, a better name for it.

— Daniel (Watti)

This is a development-journal entry about something less glamorous than most of my projects, but one I’m quite pleased with: a globally distributed APT mirror. I designed it mainly to support ixFabric, although it’s available for all my projects and friends to use. It isn’t a public service.

What is an APT mirror?

APT is the package manager used by Debian and its relatives. When a server installs or updates software, it downloads packages from a repository. A mirror is a copy of that repository that you host yourself. Instead of every server reaching out to the original sources, they fetch from your copy, which gives you more control over what they get and where they get it from.

Why I built it

I wanted all my packages to be the same across my locations, with no floating package-version discrepancy across the network. Running my own mirror means every location pulls from the same source of truth.

It was also a chance to build my skills in Aptly and rsync, and to get more exposure to CDN work, particularly replication.

What’s in it

The mirror currently carries:

• Debian (Trixie) and Debian-Security (Trixie)
• Ansible, Caddy, NGINX, Lynis, MariaDB and Docker
• Proxmox: VE (Virtual Environment), PBS (Backup Server), PMG (Mail Gateway) and PDM (Datacenter Manager)

It’s currently about 833 GB across roughly 154,890 files.

Where it lives

The content is replicated to nine locations:

• Sydney
• Frankfurt
• London
• Stockholm
• Singapore
• Los Angeles
• São Paulo
• New York
• Johannesburg

How it works

Aptly is the tool that pulls the mirrors. My Aptly scripts fetch content from the respective upstream sources into my Sydney infrastructure. From there it is pushed up to my CDN, which replicates it out to the mirror locations.

I’m careful about being a good citizen towards the upstream sources:

• I sync from reputable sources every 3 to 6 hours, checking for changes first, so I’m not downloading content and putting load on the source for no reason.
• The same approach runs in reverse when syncing to my CDN location: files are checksummed and only what has changed is uploaded.

The challenge: stale release files

The biggest problem was CDN caching. APT relies on small index files, including the release files, to know which packages and versions are current. The CDN had the latest files, but the release files were being cached, so clients were seeing stale information and downloads fell behind.

It showed up most clearly in my Ansible deployments, which failed because their apt updates were out of date.

My fix was to clear the CDN cache every 48 hours. It has resolved the failures I was seeing, though I’ll keep an eye on how it behaves.

What I took from it

• Consistency is worth the effort. Identical package versions everywhere removes a whole class of “it works in one location” problems.
• Be kind to upstream. Checking for changes and syncing at sensible intervals keeps the load on the source low.
• Caching needs thought. A CDN is only as good as its cache behaviour, and the small index files matter as much as the big packages.

I’ll share more as the mirror evolves.

— Daniel (Watti)

I like tools that fit the job. When I run into a problem that doesn’t have a good off-the-shelf answer, I’ll often build a small web application around it. This post introduces three of mine: NFTM, NPMM and LicMAN. Each started with a practical need. They’re personal tools I built for my own use, and I’m sharing them as a development journal rather than as products.

NFTM: NFTables Manager

NFTM is a multi-tenant management platform for nftables, the Linux firewall framework. “Multi-tenant” means one installation can look after several separate sets of managed hosts.

The idea came when I found myself managing over 60 separate instances of nftables. Doing that host by host doesn’t scale, and I thought there had to be a better way. So I built one.

How it works

• Adding hosts. A host is added using an SSH key, including on a custom SSH port. It can be managed on its own or as part of a group.
• Rules per host or group. Firewall rules can be added and assigned to a single host or to a group of hosts.
• Review before deploying. Pending changes are reviewed first. NFTM shows the differences between the current running configuration and what is waiting to be deployed, so I check exactly what will change before committing.
• Deployment with automatic rollback. A backup of the existing configuration is taken before deployment begins. If the host doesn’t respond after the change, NFTM automatically rolls it back to that previous configuration.
• ACLs. Access control lists can be created and applied to rules, which makes it easier to manage several policies across many hosts.

The review step and the rollback are the parts I care about most. A firewall change that locks you out of a remote machine is a bad day, and those two features are there to prevent it.

NPMM: Nginx Proxy Manager Management

NPMM is a multi-tenant platform for managing Nginx Proxy Manager (NPM) installations. One or several NPM instances can be managed from a single central location, covering their hosts, certificates and so on.

It was certainly helpful for me when I had 12 locations around the world to look after. I wanted one central place to manage everything rather than a separate set of controls for each node.

LicMAN: Licensing Management

LicMAN is a licensing management and verification platform for any code that I write. An installation periodically calls the license server to verify itself against its hashed license.

It also gives me visibility. I can see where my applications are installed and which version and revision each one is running, and I can apply updates and patches remotely when they’re needed.

What they have in common

Looking at the three together, a few themes repeat:

• Central management. One place to see and control many systems, whether that’s 60 firewalls or 12 locations.
• Safety before change. Review what will change, and keep a way back.
• Visibility. Knowing what is running where, and in what state.

Each one began as “there must be a better way” and ended up as a web application shaped around exactly the problem I had. I’ll share more about them here as they develop.

— Daniel (Watti)

I’ve written about my projects, but not much about the work that paid for the hobby. This post is a look back at my working life so far. It isn’t a résumé, but the roles and dates come straight from mine.

Where it started: 2006 to 2013

My early working life was a mix. Between 2006 and 2013 I worked in call centre sales and customer service, data processing and checking, and computer retail. I built and repaired PCs, installed software, and did some network design and installation. It wasn’t a straight line into networking, but the customer-facing roles stuck with me. Computers are only useful if the person on the other end can actually use them.

Networks and servers: 2012 to 2015

In 2012 I worked in network support at Golden Group of Companies and as a systems administrator at RackCentral. The work covered network monitoring, commissioning and decommissioning equipment, network configuration, and phone and ticket support. At RackCentral I was installing servers too, and at Golden Group there were wireless installations.

From 2013 to 2015 I was IT manager for Marks’s Cleaning Services. I looked after the business’s IT systems and network, its website and its online presence and social media, and coordinated promotions through media outlets. It was a small business, so it was a little of everything.

Into the ISP world: 2015 to 2020

• Network Engineer, Lynham Networks (Lightning Broadband), June 2015 to September 2016. Layer 2 infrastructure, customer internet connections and authentication, customer support, and building wireless towers and rooftop installations.
• Systems Administrator, j2 Australia Hosting (Web24), November 2016 to March 2017. Layer 2 networks, custom-built servers to customer specifications, procuring equipment, and working with the service desk on Level 2 and 3 issues.
• Network Administrator, ZAX Amusements, September 2017 to June 2019. Office and remote-location networks, building and servicing IT equipment, monitoring network services, deploying Intercard debit card systems to remote locations, and installing arcade games.
• Network Administrator, Golden Group of Companies, June 2019 to July 2020. Layer 2 infrastructure, customer connections and authentication, customer troubleshooting by phone, email and onsite, wireless installations, and installing customer equipment at roof locations.

A lot of that was hands-on: towers, rooftops, customer premises and remote sites. It gave me a good grounding in how a network physically gets to the people using it.

Senior Network & Systems Engineer: 2020 to 2026

From June 2020 to April 2026 I was a Senior Network and Systems Engineer at Fixtel / OneNet / CoreFibre Networks. My work covered:

• Designing and maintaining ISP infrastructure, including BGP routing with BIRD on Debian systems.
• Building and operating Proxmox clusters, automating operational tasks and maintaining monitoring.
• Troubleshooting network issues, deploying GRE/GRETAP, managing firewalls and supporting deployments.
• Designing, building and deploying GPON fibre networks in gated communities.

The GPON work is the part I’m proudest of. The networks delivered high-speed internet and free-to-air television, tailored for elderly residents. The goal was reliability, accessibility and ease of use. For someone who isn’t interested in networking, a good network is one they never have to think about.

The common thread

Looking back, a few things run through all of these roles. I like getting hands-on, from rooftops and racks through to routing configuration. I’m comfortable talking to customers and users as well as other engineers. And BGP, Linux and virtualisation have been constants, which is why they show up in my personal projects, including ixFabric.

Skills at a glance

• ISP and Layer 2 networks
• BGP (BIRD)
• GPON fibre
• GRE/GRETAP
• Firewalls
• Debian Linux
• Proxmox clusters
• Network monitoring and automation
• Windows and Windows Server, Active Directory
• TCP/IP, Ethernet and VLANs
• Customer and deployment support

Looking ahead

I’ll keep writing here about the technology I work with, the projects I build and the things I learn. If any of this overlaps with something you’re working on, my contact details are at the bottom of the page.

— Daniel (Watti)

On Wednesday 11 November 2026, Gerald Whittle and I carried out on-shore testing and troubleshooting of the Nautilus Rescue GPS at Blairgowrie Yacht Squadron Marina in Victoria. We were joined, by telephone and in discussion, by Marine Rescue Victoria and Victoria Water Police. This is a field-testing journal, not a product review. I’m writing down what we expected, what we observed and what we still need to find out, because the subject is diver safety and accuracy matters.

Why we decided to test it

The Nautilus Rescue GPS is becoming popular with scuba divers and other water users. But there seemed to be some uncertainty about exactly how these devices work, what a distress alert actually does, and who actually receives it. We wanted to move past assumptions based on documentation and online information and see what happens in practice.

Our objectives were to:

• Understand how the Nautilus Rescue GPS operates.
• Investigate its AIS and DSC functionality.
• Understand how distress alerts are transmitted.
• Establish which organisations and vessels can detect the transmissions.
• Understand the relationship between the device and the vessel or vehicle it is registered to.
• Identify how an alert might be relayed to wider marine rescue networks.
• Help educate fellow divers about what these devices can and can’t do.

The equipment and organisations involved

Equipment: Nautilus Rescue GPS units, with AIS (Automatic Identification System) and DSC (Digital Selective Calling) functionality, plus associated marine AIS/DSC equipment.

People and organisations: Gerald Whittle, myself, Marine Rescue Victoria and Victoria Water Police.

Location and date: Blairgowrie Yacht Squadron Marina, Wednesday 11 November 2026.

AIS and DSC: two different things

It helps to keep these separate. In general terms, AIS is a system that broadcasts identity and position information over marine VHF radio so that suitably equipped vessels and shore stations can see where others are. DSC is a digital signalling feature of marine VHF radio that can be used to send alerts, including distress alerts, to other vessels and stations.

I’m describing both only in general terms. Exactly which message the Nautilus sends in each system, and how each type of receiver displays and handles it, is something I still want to confirm against the manufacturer’s documentation and further testing. I’d rather say that than blur the two together.

What we expected

Before testing, our understanding was that the unit would transmit an AIS/DSC distress signal that other suitably equipped vessels and authorities could detect within an approximate 40-kilometre radius. We expected that to include Marine Rescue Victoria and other AIS/DSC-equipped stations or vessels within range.

That mattered a lot from a diver-safety point of view. We wanted to know whether activating the distress function would directly notify Marine Rescue Victoria, Victoria Water Police or other emergency response organisations. To be clear, the 40-kilometre figure was our expectation going in. It is not a verified specification, and we haven’t tested range, so please don’t treat it as one.

Testing at Blairgowrie Yacht Squadron Marina

We spent a significant amount of time on the equipment: testing, troubleshooting and discussing how it operates. The test itself used the unit’s built-in test positioning, and we also sent a distress signal. We also spoke directly with both Marine Rescue Victoria and Victoria Water Police by telephone. Their involvement and willingness to help were genuinely valuable, and I’m grateful to both organisations for their time.

What we discovered about distress alerts

The Nautilus Rescue GPS did transmit a distress signal. Victoria Water Police received our DSC distress alert and were able to acknowledge it. However, the transmission did not directly alert Marine Rescue Victoria during our testing.

That was concerning at first. After further investigation and discussion, we developed a better understanding of how these devices are intended to work.

Our understanding after the testing is that the Nautilus Rescue GPS is designed primarily to communicate with the vessel or vehicle it is registered to. When that vessel has compatible AIS/DSC equipment and is within suitable reception range, it may receive the distress alert. The operator can then assess the situation and, if appropriate, relay the distress information through their own onboard communications and established channels to wider emergency and marine rescue networks, potentially including Marine Rescue Victoria.

That distinction is important. Receiving a distress transmission and making sure the right rescue organisation is notified are not necessarily the same thing.

Important: this is our understanding based on the testing and discussions on 11 November. It isn’t a verified technical description of every Nautilus unit, every AIS/DSC installation or every marine rescue network. We only established that Marine Rescue Victoria did not receive a direct alert in our particular test. We have not established that it can’t under any circumstances.

Victoria Water Police: a successful reception

One of the most encouraging results was that Victoria Water Police received our DSC distress alert, which told them that somebody was in trouble and needed assistance. In our view, this is important. It showed that the transmission could be detected by an appropriate receiving station under the conditions of our test.

Because we were on the phone with them at the time, they knew it was a test, so no assets were dispatched, as they would have been in a real incident. That means we saw the alert arrive, but we did not test what happens next in a real emergency. What, if anything, was received over AIS in this test is also something I still want to confirm. I’d like to thank both Victoria Water Police and Marine Rescue Victoria for the time they gave us.

Understanding the role of the registered vessel

The main thing I took from the session is the importance of the registered vessel and its onboard equipment. If the device primarily signals the vessel or vehicle it’s registered to, then a diver’s safety depends partly on that vessel being able to receive the alert, recognising it for what it is, and passing it on. We still need to establish how reliably that happens, and what happens when the registered vessel is unavailable or out of range.

What this means for scuba divers

Owning a Nautilus Rescue GPS does not automatically mean that every marine rescue organisation will receive a direct alert when the distress function is activated. Divers should understand:

• What the device actually transmits.
• Which receiving equipment may detect its transmission.
• The importance of the registered vessel and its onboard equipment.
• That receiving a distress signal and starting a rescue response are separate steps.
• The limitations of any personal emergency signalling device.

I’m not suggesting anyone stop using the equipment. I’m encouraging informed use, education and further testing. This article is not a substitute for official emergency procedures, manufacturer instructions or appropriate safety equipment.

What we still need to test

Despite the positive result with Victoria Water Police, we aren’t yet 100% confident in these units or how effective they are in all situations. These are open questions for future testing and have not been completed:

• Actual transmission and reception performance.
• The practical range and limitations of the distress transmissions.
• How different AIS/DSC receiving installations respond.
• Whether the registered vessel reliably receives and recognises the alert.
• What happens when the registered vessel is unavailable or out of reception range.
• How distress information can be relayed to Marine Rescue Victoria and other emergency organisations.
• How a real alert is handled from end to end. Our test was known to be a test, so no assets were dispatched.
• What divers should realistically expect when they activate the device.

Looking ahead: open-water testing

We intend to carry out further open-water testing over the coming weeks. That should show how the units perform in real marine conditions, rather than relying only on testing at the marina. I’ll write up the results here, whatever they turn out to be.

Final thoughts

This session was a good reminder that safety equipment is only as good as your understanding of it. The device did transmit, and Victoria Water Police received and acknowledged the alert. We also learned that the path from an alert to a rescue organisation may depend on other links, particularly the registered vessel. There is more to establish, and I’d rather be honest about that than overstate what we know.

— Daniel (Watti)

This is a development-journal entry about VicVIZ, a personal project for checking dive conditions in Victoria. It takes weather and marine forecast data and turns it into an estimate of how diveable a site is. I’m writing about it as a project in progress, not announcing a finished product.

The idea

Anyone who dives in Victoria soon learns that conditions decide a great deal. Wind, swell and tide can turn a simple shore entry into one you would rather skip. I enjoy shore-entry dives around the Mornington Peninsula, so how easy it is to get in and out of the water is never an abstract question for me.

Community dashboards already exist for this purpose; VIZ explained is one example. VicVIZ has the same purpose: giving divers a fast way to read the forecast for a site.

The score

The headline figure is a surface and entry–exit difficulty score from 0 to 60, where a higher score means it is easier. The score is split into three bands:

• 40–60: good. Forecast conditions look favourable.
• 20–39: caution. Conditions are less straightforward, so take more care.
• 0–19: avoid. Forecast conditions look difficult.

It is an estimate of diveability based on forecast conditions. It is not a guarantee of safety, and you should always assess conditions on site before diving.

What goes into it

VicVIZ collects conditions and metrics from external sources, including:

• Wind
• Wave height
• Swell height
• Rain
• Air temperature
• Sea levels
• Currents

The weather data comes from the Bureau of Meteorology’s ACCESS-G forecast model, delivered through Open-Meteo. The marine wave data also comes from Open-Meteo. I’m using established forecast sources rather than trying to produce forecasts myself.

How the model works

The current scoring model is labelled version 2. Beyond the raw numbers, it takes account of the characteristics of each site:

• Per-site directional exposure. A site faces a particular direction, so the same wind or swell can be harmless at one site and a problem at another, depending on whether it comes from the open side or the sheltered side.
• Refraction. Waves bend as they approach the coast. That changes how much wave energy actually reaches a particular site compared with what the open-water forecast suggests.
• Tide sensitivity. Some sites are affected more than others by the state of the tide, which can change how easy it is to enter and exit.

Putting these together is what makes a per-site score more useful than a single regional forecast.

What it doesn’t tell you

It is not a measure of underwater visibility. The score covers surface conditions and entry–exit difficulty only. Visibility isn’t measured by the Bureau of Meteorology; it is reported by divers or admins.

Where it goes from here

VicVIZ sits where two of my interests overlap: diving and building things with data. You can see the project at vicviz.com.au. I’ll keep documenting it here on Watti as it develops.

— Daniel (Watti)

This is a development-journal entry about ScubaMAN, a personal technology project that combines two of my interests: scuba diving and building software. On its own site it goes by SCM — Scuba Centre Management, and it is aimed at the day-to-day running of a dive centre. It isn’t a finished commercial product, and I’m not presenting it as one. This is an account of what I’m building and why.

Where the idea came from

I built ScubaMAN because I saw a need to help the dive centre operator I use bring everything together. At the moment, doing their job means logging into several different places on the fly: dive boat operators’ portals, PADI course portals and others. Creating a single booking can mean a lot of going back and forth between the operators and the customer, and all of that takes time.

Servicing was the other concern. Equipment service records weren’t capturing things like serial numbers or the date an item was last serviced. For safety-critical gear such as regulators and cylinders, that is exactly the information you want to have to hand.

So the idea is simple: one workspace where the centre can see and manage all of this, instead of juggling portals, spreadsheets and memory.

What it does

ScubaMAN is organised around how a dive shop actually runs. These are the areas it covers:

• Courses and training. Course offerings and rosters, so you can see who is in which course.
• Trips and boats. Scheduling for boat dives and charters, using the same data as the rest of the shop. That suits things like capacity limits, manifests and coordinating staff.
• Equipment service. Service jobs that move from open to complete, with a status that can be shown to customers. The workflow is built around work orders for items like regulators and cylinders.
• Inventory and point of sale. Inventory, sales orders, invoices and payments together in one system.
• Customers. A single customer directory per centre, plus profile and password management for staff.

An important part of the project is working with real information rather than demo data: live data from boat operators, stock inventory and course dates from PADI instructors.

How it’s put together

I’ll be upfront that I haven’t covered the full technology stack in this entry; I’ll write about that separately. What I can say is how the system is designed to behave, and the main idea is multi-tenancy.

In plain English, that means one system can serve several dive centres, with each centre’s data kept strictly separate from the others. Customer email addresses, for example, are unique within a single centre only, so there is no chance of one shop’s customer data leaking into another’s.

On top of that sit a few platform features:

• A multi-tenant control plane for operators, to manage the centres on the system.
• Impersonation for support, so a problem can be investigated as the user sees it, with audit trails recording that it happened.
• Rate limiting at the API edge, which stops any one client from overwhelming the service.

The design aims for a clean API and tenant-safe data, which keeps the door open to extending and integrating it later.

What might come next

I want to be clear about the difference between what exists and what is only an idea. The following are directions I’m interested in exploring, not promises or dated plans:

• Certification issuance and reminders, once connected to the relevant providers.
• Messaging and receipts to customers, once email is wired up.
• A richer product catalogue and syncing with other sales channels.
• Agency-related workflows.

Why it matters to me

ScubaMAN sits right where my interests overlap. I spend time around dive centres and boats, and I build software, so it feels natural to use one to improve the other. If it saves a dive centre time on bookings and gives its service work a proper paper trail, it will have done its job.

You can find the project at scubaman.app. I’ll share more about how it’s built and how it develops here on Watti.

— Daniel (Watti)

I mentioned ixFabric in my introduction as one of the projects closest to my heart. It deserves a proper write-up of its own, and not just the polished parts. This is the story of what ixFabric is, why I think it matters, what went wrong in September 2026, and the substantial work that has gone into rebuilding it.

What is ixFabric?

ixFabric is a distributed Internet infrastructure and BGP routing project. It provides route-server infrastructure across multiple geographical locations, allowing participating networks to exchange routing information and establish peering relationships with one another.

If you work in networking, you will know exactly what a BGP route server is. If you don't, here is the short version.

The Internet is a collection of thousands of independent networks, known as autonomous systems, that exchange reachability information using the Border Gateway Protocol (BGP). When two networks want to exchange traffic directly, they set up a BGP session between them and announce the prefixes they are willing to carry. That is called a bilateral session. It works well, but it doesn't scale gracefully: if you want to peer with fifty other networks, you need fifty sessions to configure, monitor and maintain, and each one needs agreement from the other side.

A route server simplifies this. Instead of every network peering with every other network individually, each participant establishes a session with the route server. The route server receives the routes each participant announces and passes them on to the other participants, according to the policies those participants have configured. In effect, one session can give you routing information from many peers.

One point is worth stating clearly, because it is often misunderstood. A route server does not carry your traffic. It only handles routing information. The actual data still flows directly between the participating networks. A route server also doesn't take control of anyone's routing decisions: each participant remains in charge of what it announces, what it accepts and how it prefers to route.

What ixFabric provides

ixFabric is more than a handful of servers. It is a set of connected pieces that work together:

• Distributed BGP route servers. Route-server infrastructure spread across multiple geographical locations, so participants can connect to infrastructure that suits them.
• Internet peering infrastructure. The foundation that lets participating networks exchange routes and build peering relationships.
• Centralised management through the Portal. The place where participants manage their connection to the project: portal.ixfabric.net.
• Routing visibility through the Looking Glass. A way to see what the route servers are seeing, which is invaluable when you are checking or troubleshooting routing: lg.ixfabric.net.
• Supporting infrastructure, automation and operational systems. The less visible machinery that keeps everything consistent, deployable and manageable.

Why is ixFabric useful?

I built and care about this project because I think it genuinely helps the wider networking community.

• It makes peering more accessible. Getting started with peering can feel daunting. A route-server model lowers that barrier.
• It reduces administrative overhead. Fewer bilateral BGP sessions to negotiate, configure and maintain means less time spent on housekeeping.
• It helps smaller networks and operators participate. Smaller operators often don't have the time or staff to manage dozens of individual sessions.
• It provides routing visibility and troubleshooting. Being able to look at the routing information directly takes a lot of the guesswork out of diagnosing a problem.
• It supports a distributed networking community. Networks in different places can connect through a shared, common framework.
• It improves connectivity opportunities. More ways for participating networks to find and reach one another is good for everyone involved.

The security incident — September 2026

I want to be honest about this part. In early September 2026, the project experienced a significant security incident. At the time, it was operating under its previous name, BGP.Exchange.

The systems identified as affected were:

• The application platform
• The database
• The email systems
• The Sydney hypervisor

It is important to be clear about what was not identified as affected. The route servers themselves, and the other hypervisors, were not identified as affected. This was not a case of the entire routing infrastructure being compromised.

That said, the incident was a serious disruption. When core platform systems are affected, the work that follows is demanding: services have to be disrupted or taken offline, the situation has to be investigated carefully, and the scope has to be properly assessed. Working out what was affected, and just as importantly what wasn't, takes time and discipline. It is easy to be tempted to move quickly, but a hurried response to a security incident can create more problems than it solves. I would rather be slow and certain than fast and wrong.

Rebuilding and rebranding

The transition from BGP.Exchange to ixFabric is much more than a simple rebrand. A new name on top of the same systems would not have been good enough. What followed was a substantial recovery and rebuilding effort.

Rebuilding the application and management infrastructure

The affected application and management systems were rebuilt rather than patched and put back. Starting from a clean foundation gave me the chance to make better decisions about how the platform is put together.

Restoring services in a controlled manner

I chose to bring services back in a controlled way rather than flipping everything on at once. Each step needed to be deliberate, so that I could be confident about what was running and why.

Reviewing security and operational practices

An incident like this forces an honest look at how things were being done. I reviewed security and operational practices as part of the rebuild, and that review has shaped how the new platform is run.

Validating systems and infrastructure

Rebuilt systems need to be checked, not assumed to be correct. Validation was an important part of restoring services, and it continues to be.

From BGP.Exchange to ixFabric

The new name marks a fresh start. It reflects what the project is: a fabric of distributed infrastructure connecting networks together. The rebrand is mostly complete, and the remaining work is being finished off.

Where the project stands — November 2026

I'm proud of how far the project has come in a short time. These are the confirmed milestones as of 6 November 2026:

• 47 active, production route servers have been rebuilt and are operational.
• The Portal has been relaunched at portal.ixfabric.net.
• The rebuilt Looking Glass has launched at lg.ixfabric.net.
• The rebranding to ixFabric is mostly complete.

Rebuilding 47 production route servers, relaunching the Portal and bringing the Looking Glass back are real achievements, and I don't take them lightly.

Challenges and lessons learned

Operating distributed Internet infrastructure is rewarding but demanding, and doing it in the wake of a security incident sharpens every lesson. A few themes stand out.

• Infrastructure reliability. Participants depend on the service being there. Reliability isn't a feature you add later; it has to be designed in.
• Security and access control. Who can reach what, and with what privileges, matters enormously. Tight access control limits the damage when something goes wrong.
• Recovery planning. It is far better to have thought through recovery before you need it. A plan that exists only in your head isn't a plan.
• System isolation and boundaries. Clear separation between systems helps contain a problem. The fact that the route servers and other hypervisors were not identified as affected is a reminder of how valuable good boundaries are.
• Automation and operational consistency. With dozens of route servers, doing things by hand invites drift and mistakes. Automation makes the infrastructure consistent and repeatable.
• Documentation. Good documentation makes rebuilding, validating and operating all easier. I have come to value it even more.
• Rebuilding trust and confidence. Technical recovery is only part of it. People who rely on the project need to be able to trust it, and that is earned through honesty, consistency and good work over time.

What's next?

The rebuild is a milestone, not the finish line. I intend to keep improving ixFabric: strengthening the infrastructure, improving the platform and supporting the wider networking community that makes a project like this worthwhile.

I also plan to publish further technical articles here on Watti about BGP, route-server operations, infrastructure, automation and the lessons I've learned along the way. If that sounds interesting, keep an eye on the journal.

In the meantime, you can explore the project yourself:

Thanks for reading, and thank you to everyone who has been patient and supportive while this was rebuilt.

— Daniel (Watti)

Welcome to Watti! I'm Daniel Watson, although most people who know me online will recognise me as Watti.

I've always had a strong interest in technology, computers, networking and understanding how things work behind the scenes. I enjoy getting hands-on, experimenting with new technologies, solving problems and building things rather than simply reading about them.

But technology isn't my whole life. I also enjoy scuba diving, exploring shipwrecks, working on my vehicle and its electrical setup, camping away from populated areas, boating and aviation. This blog is where all of those interests can live together.

Technology, networking and infrastructure

Networking is one of my biggest technical interests. I'm particularly interested in BGP, routing, autonomous systems, Internet exchanges, peering, RPKI, IPv4 and IPv6. I enjoy learning how the Internet operates and what makes large-scale infrastructure work.

I also spend plenty of time working with Linux, Debian, Ubuntu, servers, virtualisation, containers, databases, DNS, automation and security. I like building systems, understanding the underlying details and making them reliable and practical.

One of the major projects I'm involved with is ixFabric, an Internet infrastructure and routing project that brings together many of these interests.

Scuba diving — exploring beneath the surface

Scuba diving is one of my major personal interests. I'm an Advanced Open Water certified diver, with additional Nitrox and Drysuit certifications.

Wreck diving is my favourite. I enjoy exploring the history and structure of vessels resting beneath the surface, particularly the historic HMAS vessels and J-class submarines scuttled around the Port Phillip Heads area of Victoria.

Getting out to those sites isn't always practical, so I also enjoy shore-entry dives around the Mornington Peninsula whenever I can. I'll use the blog to share diving experiences, equipment, training, underwater exploration and the maritime history that makes these places so fascinating.

My vehicle — a 2019 Holden Colorado RG

I'm also interested in practical electrical work, especially 12V automotive and camping systems. My vehicle is a 2019 Holden Colorado RG 4x2, and I've been building it into a capable, connected off-grid camping platform.

The setup includes a dual-battery 12V system with a BCDC charger, solar input and a camping fridge. I've also incorporated Starlink, 4G connectivity with failover, GPS tracking and Wi-Fi-based remote control of selected 12V power systems.

Being able to remotely access and control parts of the setup over Starlink or 4G brings together two of my interests: practical vehicle systems and networking. I'll document the installation, equipment, wiring, configuration and future improvements as the project develops.

Off-grid camping — getting away from reality

I'm not particularly focused on hardcore four-wheel driving. What I enjoy is getting away from reality and population: finding somewhere to camp, spending time outdoors and taking a break from the usual routines.

I like having a comfortable, self-sufficient setup with independent power, a fridge and connectivity available when I need it. The goal isn't to stay connected to everything all the time; it's to have the choice when I'm somewhere remote.

Boating and marine electronics

I'm interested in boating and the technology used aboard modern vessels. Simrad displays, AIS, NMEA 2000 networking, GPS, navigation, marine communications and safety equipment all combine practical engineering with real-world use.

I enjoy understanding how these systems communicate and how different pieces of equipment can be integrated, including underwater cameras and marine rescue technology.

Aviation, RC aircraft and home automation

Aviation is another interest, particularly large commercial aircraft such as the Airbus A380. I'm also interested in large-scale radio-controlled aircraft and the engineering involved in building and operating them.

At home, I enjoy experimenting with Home Assistant, smart devices, Zigbee, ESPHome, sensors and automation. I like making different technologies work together to create something genuinely useful.

Why Watti?

I wanted somewhere to document the things I work on, share discoveries and keep a record of projects and experiences. Some posts will be detailed technical walkthroughs; others will be about diving, camping, equipment or something interesting I've been exploring.

I'm a hands-on person who enjoys learning by doing. I value practical solutions, good documentation, safety and systems that are built properly. I also believe there's always something new to learn.

Whether that means configuring a route server, installing a 12V electrical system, exploring a historic wreck or setting up camp somewhere quiet, I enjoy understanding how things work and getting involved.

Technology is a big part of my life, but it's certainly not all of it.

Thanks for stopping by. I hope you'll follow along as I share projects, tutorials, experiences and discoveries here at Watti.

— Daniel (Watti)