
{/* banner prompt: A matte clay-render still life in soft diffuse studio lighting: a cream-and-grey clay desktop computer on a low pedestal with a small terracotta drive-letter tile marked X floating just out of reach above it, connected by a dangling clay cable whose plug misses its socket, a faint clay signal-wave arcing off to one side into empty space, simple sage-green background with one terracotta accent block, soft long shadows, fingerprinted clay texture, minimal props, cinematic depth, 16:9, no text, no words */}

Every so often a support problem is interesting not because it is hard, but because every obvious explanation is wrong. This was one of those. A user at a branch office had a mapped drive — good old `X:` — pointing at the head-office file server. Several times an hour it would simply stop working. Open it from Explorer or try to save into it from a browser, and Windows threw up the dialog everyone has seen and nobody has ever found helpful:

![The Windows "Location is not available" dialog — "X:\... is unavailable. If the location is on a network, make sure you're connected to the network or Internet, and then try again."](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/09/when-a-mapped-network-drive-keeps-going-not-available/location-not-available.png)

Click OK, wait a moment, try again, and it usually worked. Then a few minutes later it would be gone again. The user's summary was blunt and accurate: *"X: is very unstable, it keeps saying not available."*

The dialog's own advice — check that you are connected to the network — is a dead end here, because the network was never the problem. Let us walk through how to prove that, and then find the thing that actually was.

## Ruling out the usual suspects

An intermittently missing network drive has a short list of usual causes, and it pays to knock them down with evidence rather than assumption.

**Was it a permissions problem?** No. Reads worked, and a scripted write test — create a temp file at the share root, in a subfolder, and via the raw UNC path — succeeded every time. If the account could not write, it would fail *consistently*, not intermittently. Permissions were fine.

**Was it a bad link?** This is the one everybody reaches for, and it was wrong too. The server was reached over the internet, so a flaky WAN would have been a plausible story. Except the numbers said otherwise:

```text
Resolve  fileserver  -> 202.1.123.10   (the public/reachable address)
Ping     8 of 8 replies, 0% loss, 30-31 ms, near-zero jitter
TCP 445  reachable: True
```

Zero packet loss, rock-steady 30 ms, and port 445 open. That is a *healthy* path. Whatever was happening, the link between the two sites was not dropping.

**Was the drive just idle-disconnecting?** Windows does tear down idle SMB sessions and a mapped drive can show a red X until you touch it again — mildly annoying but cosmetic. That was part of the picture, but it did not explain why *reconnecting* was so unreliable. So we went to the one place that actually knows: the SMB client's own event log.

## The SMB client keeps a detailed diary

This is the part worth stealing for your own toolkit. The Windows SMB **client** logs its connection lifecycle in two logs that almost nobody opens, under **Applications and Services Logs → Microsoft → Windows → SMBClient**:

- **`SMBClient/Connectivity`** — connects, reconnects, and connection failures.
- **`SMBClient/Operational`** — the redirector's decisions about which connection to actually use.

You can read them straight from PowerShell. Group by event ID first to see the shape of the problem:

```powershell
Get-WinEvent -LogName 'Microsoft-Windows-SmbClient/Connectivity' -MaxEvents 40 |
  Group-Object Id | Sort-Object Count -Descending |
  Select-Object Count, Name
```

On the misbehaving machine, that came back looking like this — a connection being *re-established over and over*, interleaved with two kinds of failure:

<Table data={
    {
        headers: ['Event ID', 'Count', 'Meaning'],
        rows: [
            ['30833', '15', 'The initial connection to the share was established'],
            ['30822', '10', 'Failed to establish an SMB multichannel network connection'],
            ['30827', '5', 'Could not find a certificate mapping that matches the server name'],
        ]
    }
} />

A stable drive connects **once** and stays put. Fifteen "initial connection established" events in a few minutes is not stability — it is a drive reconnecting constantly. And sitting right next to each burst were multichannel failures and a certificate error. The full text of a single 30822 event is where the case cracked open:

```text
Failed to establish an SMB multichannel network connection.
Error: {Device Timeout}
Server name:    fileserver
Server address: 192.168.10.8:445      <-- a private address
Client address: 192.168.20.245        <-- a different private subnet
Connection type: TCPIP

... and a second one:
Server address: 192.168.10.8:443
Connection type: Quic
```

And in the Operational log, the matching verdict:

```text
The SMB redirector did not select the connection initiated with the following parameters:
  IP Address: 192.168.10.8:445
  The failure status associated with this decision:
  The network path cannot be located.
```

## The root cause: SMB Multichannel dialling the wrong number

Here is what was actually going on.

The file server is **dual-homed**. From the branch office you reach it over the internet at its public address (`203.0.113.10`). But when an SMB session sets up, part of the negotiation is **SMB Multichannel**: the server helpfully tells the client about *all* the network interfaces it has, so the client can open extra parallel connections for throughput and resilience. Great feature — on a LAN.

The trouble is that one of the interfaces the server advertised was its **internal LAN address**, `192.168.10.8`. The branch office is on a completely different private subnet (`192.168.20.0/24`), with no route to the server's internal network. So every time the drive reconnected, the client dutifully tried to open a multichannel connection to `192.168.10.8` — an address it can *never* reach — and sat there until it hit a device timeout. For good measure it also tried **SMB over QUIC** (UDP 443) to the same dead address, which failed on a certificate mismatch (the `30827` events).

None of those extra channels can succeed, so the redirector eventually falls back to the one connection that works — the public path. But by then the user has already been staring at "Location is not available," because the drive appeared dead during the seconds Windows spent timing out on the phantom address. Combine that with the normal ~10-minute idle disconnect, and you get a drive that feels broken several times an hour on an otherwise perfect link.

Microsoft's own guidance text in the 30822 event even says these extra-channel failures "will not result in an application error" — and strictly that is true, the *failure* is harmless. What is not harmless is the **time spent failing**. That delay is the whole user-visible symptom.

## The fix: one line

On a single-link workstation, SMB Multichannel buys you nothing — there is only one path to the server. So the correct move is to stop the client from probing for extra channels at all:

```powershell
Set-SmbClientConfiguration -EnableMultichannel $false -Force
```

It is a client-side setting, it takes effect on the next connection, and it is trivially reversible (`$true` to restore). No feature is lost on a machine with a single route to the server; the client simply stops chasing addresses it cannot reach and goes straight to the working one.

The proof is in the same event log afterwards. With Multichannel disabled and 22 hours of normal use:

<Table data={
    {
        headers: ['Symptom', 'Before', 'After (22 h)'],
        rows: [
            ['30822 multichannel failures', 'every reconnect', '0'],
            ['30827 QUIC certificate errors', 'every reconnect', '0'],
            ['Redirector "did not select" churn', 'every ~10 min', 'gone'],
            ['Reconnects', 'slow, stalling', 'clean and instant'],
        ]
    }
} />

The reconnects that remain are normal, healthy idle reconnects — they just complete instantly now, via the good path, instead of stalling on a dead one. The drive stopped vanishing.

## A related trap, while we are here

There is a *second*, unrelated reason a mapped drive can read "not available" that is worth knowing, because it looks identical from the user's chair: the **UAC linked-connection split**.

If the signed-in user is a local administrator, Windows gives them two security tokens — a normal one and an elevated one — and **mapped drives are not shared between them**. So a drive mapped in the normal session is invisible to any app running *as administrator*. Launch a program elevated, and your perfectly good `X:` is simply not there. The fix is a documented registry value:

```text
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLinkedConnections = 1   (DWORD)   then reboot
```

That was not the cause of *this* case — the flapping was — but it is the first thing to check if a drive is visible in Explorer yet missing inside one specific elevated application.

## Takeaways

- **"Location is not available" is a symptom, not a cause.** The dialog blames the network; believe the evidence instead.
- **Prove the link before you blame it.** Loss, latency and a TCP 445 check take thirty seconds and rule out the most tempting wrong answer.
- **The SMBClient event logs are gold.** `Connectivity` and `Operational` under `Microsoft-Windows-SmbClient` tell you exactly which address the client tried and why the redirector rejected it — no packet capture required.
- **SMB Multichannel assumes a LAN.** Point a client at a dual-homed server across the internet and it will happily try to reach the server's private interfaces. On a single-path client, `EnableMultichannel $false` is a clean, reversible fix.

Sometimes the machine really is doing exactly what you told it to. It was just trying to call a number that no longer answers.


181a360bb678ce5569ef15ed37c575d8db2b810b5046d939bbdbb899d0dd00a3

A mapped network drive kept showing 'Location is not available' despite a healthy link; here is how to diagnose SMB Multichannel churn from the Windows event log and fix it with one line of PowerShell.

A mapped drive to a remote-office file server kept flapping to 'Location is not available' — yet the network link was rock solid. The culprit was SMB Multichannel quietly chasing an address it could never reach. Here is how the Windows SMB event log gave it away, and the one-line fix.

When a Mapped Network Drive Keeps Going 'Not Available'

{/* banner prompt: Clean isometric diorama on a white background: a miniature network cable plugs into a small server tower, but instead of connecting, a stylized red "RST" shockwave bounces off an invisible barrier. Beside it, a magnifying glass reveals tiny binary/protobuf-like blocks hidden inside the cable's data stream. Minimalist, crisp shadows, matte sage-green/cream/terracotta color palette, soft studio lighting, 16:9. */}

Our IBKR market data gateway had been streaming quotes for hours without a hitch. Then, with no code change and no configuration change on our end, every single connection attempt started failing the same way:

```
IBKR error id=-1 code=-1: Connection reset by peer
```

Instantly. Every time. Regardless of client ID. Regardless of which host we connected from. It survived restarting TWS. It survived a full reboot of the machine. Settings were fine, the account was fully logged in, no prompt was waiting for a click. By every conventional signal, everything was correct — and it still reset in under a fifth of a second, every single attempt.

This is the story of chasing that down: five real bugs fixed along the way, none of which were the actual cause, and the one root cause that finally showed up when we stopped trusting the application layer and went straight to the wire.

## The bugs that were real, but weren't it

Before the actual culprit, it's worth walking through what we *did* fix, because each of these was a genuine, confirmed bug — just not the one causing this particular symptom.

**A reconnect storm.** The gateway had two independent, uncoordinated reconnect paths — one inside the connector class, one in the process's own connection-status handler — that could both fire for the same disconnect event and both call the underlying socket's connect method concurrently. Under the right conditions this produced an exponential explosion: a `systemctl status` check showed the task count climbing past 120 and still rising. Fixed by making one path the sole owner of reconnect logic.

**A stale timestamp defeating the backoff.** Even after fixing the storm, retries were still hammering the server every 300 milliseconds instead of backing off. The backoff logic decided "fast retry vs. exponential backoff" based on how long the *previous* session had been alive — but that timestamp was only updated on a *successful* connect. On a run that never once succeeded, it stayed stale, making every immediate rejection look like "this was healthy for ages," which took the fast-retry branch forever. The fix: stamp the timestamp at the start of each attempt, not just on success.

**A busy loop pegging an entire CPU core.** This one had nothing to do with the reset at all, and we only found it because we happened to check `ps aux` while debugging something else and saw a process sitting at a sustained 100% CPU. A `dotnet-dump` capture and a managed stack trace showed the real story:

```
System.IO.StreamReader.ReadLine()
Program+<>c__DisplayClass93_0.<Main>b__1(System.Object)
System.Threading.ThreadPoolWorkQueue.Dispatch()
```

The process had an interactive "press x to exit" input loop reading from stdin — completely reasonable for a console app run by hand. Under systemd, though, stdin is closed. `Console.ReadLine()` on a closed stream returns `null` *immediately*, forever, and the loop had no check for that — so it called `ReadLine()` again at full speed, permanently. This is the shared entry point every one of our broker connectors goes through, not something specific to this one gateway, so it had almost certainly been burning a full core on every systemd-managed instance in the fleet, for as long as any of them had been running. One `if (null == line) break;` and CPU usage on that process dropped from 100% to under 2%.

**A double subscription with a silent side effect.** After the actual fix (below) got the connection stable, we noticed every persisted symbol produced a `Duplicate ticker id` error on every connect. The connection-established handler fires synchronously, and the resubscribe loop inside the connector's own "restore market data after reconnect" logic ran *after* the process's separate, canonical resubscribe path had already resubscribed the same symbols moments earlier — so it fired again, reusing the same ticker IDs. Worse: that redundant loop called the market-less subscribe overload, meaning on a genuine reconnect it would have silently dropped market context and re-resolved exchange-specific symbols against the wrong venue. Removed entirely — the canonical path already covers it correctly.

Four real, verified fixes. None of them touched the reset.

## Going to the wire

At this point we'd validated login, TWS settings, trusted-IP configuration, client ID uniqueness, and machine state, and restarted or rebooted at every layer available to us. The application-level signal — "Connection reset by peer" — kept pointing everywhere and nowhere. So we stopped trusting it and captured the actual packets:

```sh
sudo tcpdump -i lo -w reset.pcap 'port 7496'
```

The capture told a different story than the error message did. TWS accepted the plaintext version handshake fine — negotiated server version 223 — and then, the instant it received the client's *next* message, it sent a graceful `FIN`. Not a `RST`. Our own error handling was mislabeling an orderly, voluntary close as a socket reset.

That next message was the payload of interest:

```
20:42:05.070228 ... length 11
0x0030:  76fa 62b5 0000 0007 0000 010f 08e8 07
20:42:05.070642 ... length 10
0x0030:  76fa 62b5 0000 0006 0000 0103 0803
```

That's not the classic IB API wire format — a null-byte-delimited text protocol we'd tested by hand with a raw socket and confirmed worked, every time, for the exact same connection sequence and client ID. This was binary, varint-shaped data. `0xe8 0x07` decodes to 1000 — our client ID, Protobuf-encoded.

## The one-line fix

Our vendored IB API client library automatically switches specific outgoing messages to Protobuf encoding once the negotiated server version clears a threshold:

```csharp
public static bool useProtoBuf(int serverVersion, OutgoingMessages outgoingMessage)
{
    return Constants.PROTOBUF_MSG_IDS.TryGetValue(outgoingMessage, out int unifiedVersion)
        && unifiedVersion <= serverVersion;
}
```

`StartApi` — the message sent automatically, immediately after every connection — was mapped to require server version 213. Our negotiated version was 223. The threshold cleared, so the library always sent `StartApi` as Protobuf. And this particular TWS build, despite reporting a version that the client library's own table says should support it, evidently doesn't actually parse a Protobuf-encoded `StartApi` — it just closes the connection the instant it arrives.

We confirmed this the only way that actually proves anything: hand-crafting the identical connection sequence over a raw socket, with the plaintext format instead of Protobuf, same client ID, same host, same everything else. It connected immediately and stayed open.

The fix was one dictionary entry:

```csharp
// StartApi deliberately excluded: this TWS build doesn't support Protobuf
// for it despite reporting a version that implies it should.
{ OutgoingMessages.ChangeServerLog, MinServerVer.MIN_SERVER_VER_PROTOBUF_REST_MESSAGES_3 },
```

No other message at that version tier is used anywhere in our codebase, so removing just the `StartApi` entry was the entire change.

## Why it "worked before"

If this is deterministic given a fixed server version, why did the same code stream data reliably for hours before this started? The most likely explanation is that it wasn't the same server version — TWS auto-updates itself, and its daily scheduled restart is exactly the mechanism that would pull in a new build mid-session. Before whatever update happened, the negotiated version was presumably below the Protobuf threshold, so the client used the classic format the whole time and never touched this code path. After the update, every connection attempt crossed the threshold and hit a gap in that specific build's Protobuf support.

We can't directly confirm TWS's build history — that detail lives inside an encrypted session log we don't have tooling to read — but it's the only explanation consistent with every observed fact: hours of stable streaming beforehand, a sudden onset with zero configuration changes on our side, and a packet capture proving the break point is version-gated behavior that only exists above a specific threshold.

## What actually mattered

None of the individual debugging steps here were exotic. `ps aux`, `dotnet-dump`, `tcpdump`, a raw socket in twenty lines of Python. What mattered was the discipline of not stopping at the first plausible-looking bug. Four of the five things we fixed were real, and it would have been easy to declare victory after any one of them — the reconnect storm alone was dramatic enough (task count climbing past 120) to feel like *the* bug. It wasn't. The actual fix only showed up once we stopped reading the application's own description of the failure and looked at what was actually on the wire.

If you're chasing a "connection reset" that survives every fix that should have worked: check whether it's really a reset at the TCP level before you believe the error message, and check what your client is *actually* sending, not what you assume it sends.

*If you're running the IB API client library and see a similarly unexplainable reset immediately after connecting, checking whether a Protobuf-eligible message is involved is worth five minutes before anything else.*


710cb12b6a8a2248378b97525bbe585c1decc93be251377d5959c488532d90df

Root-causing an IBKR TWS API 'Connection reset by peer' bug with tcpdump and a raw socket client - the real cause was a Protobuf-encoded StartApi message the TWS build didn't support.

A market data gateway that worked fine for hours started rejecting every single connection with 'Connection reset by peer' - and stayed broken through TWS restarts, a full machine reboot, and every conventional fix. Here's how a raw packet capture and a hand-crafted socket client found the real bug: a version-gated Protobuf auto-switch that TWS silently didn't support.

The Connection Reset That Wasn't: Hunting a Protobuf Bug in IBKR's TWS API


{/* banner prompt: A playful but polished 3D clay-render, matte materials in sage green, cream and terracotta, of a stylized detective magnifying glass hovering over a small padlock icon that is cracking open, with a tangled network cable looping around a proxy-server box in the background, soft studio shadows, simple background, 16:9. */}

`yt-dlp` gave us the least helpful error message it has: `HTTP Error 410: Gone`. The standard fix is `yt-dlp -U`. We ran it. Already on the latest stable release. The video was not, in fact, gone — but proving that took three separate bugs stacked on top of each other, and the last one had nothing to do with `yt-dlp` at all.

We were debugging a small local downloader tool — a browser extension that hands a page URL and cookies to `yt-dlp` on the user's own machine, optionally routed through a local HTTP proxy for geo-unblocking. One specific site started failing every time, on a URL that worked fine a week earlier.

## The first clue was buried in `-v`

The plain error told us nothing. Adding `-v` for verbose output surfaced a line that's easy to scroll past:

```
WARNING: [SiteExtractor] The extractor is attempting impersonation, but no
impersonate target is available. If you encounter errors, then see
https://github.com/yt-dlp/yt-dlp#impersonation for information on
installing the required dependencies
```

That's the real signal. A growing number of sites fingerprint the TLS handshake and HTTP/2 frame ordering of incoming requests to tell a real browser apart from a scripted client — even when every header looks identical. `yt-dlp` can spoof a browser's TLS fingerprint via an optional dependency, `curl_cffi`, which wraps `libcurl` with impersonation profiles for Chrome, Safari, Firefox and so on. Without it, some extractors still try the request, get rejected at the TLS layer, and the site's edge returns a generic `410` instead of anything that explains what actually happened. The video was fine. `yt-dlp` just didn't look enough like a browser to be allowed to ask.

## The version window nobody tells you about

The fix looked trivial:

```sh
python3 -m pip install curl_cffi
```

It installed cleanly — `curl_cffi-0.16.0`, the latest release. `yt-dlp` still refused to use it, and `--list-impersonate-targets` came back with every target marked `(unavailable)`. The debug line was the giveaway:

```
[debug] Optional libraries: ... curl_cffi-0.16.0 (unsupported) ...
```

`yt-dlp` doesn't just check that `curl_cffi` is importable — it pins a narrow set of versions it actually trusts, because `curl_cffi`'s impersonation API has changed shape across releases. Digging through the installed `yt-dlp` build (it ships as a zip-app; `python -m zipfile` opens it like any other zip) turned up the exact check:

```python
curl_cffi_version = tuple(map(int, re.split(r'[^\d]+', curl_cffi.__version__)[:3]))

if curl_cffi_version != (0, 5, 10) and not (0, 10) <= curl_cffi_version < (0, 16):
    curl_cffi._yt_dlp__version = f'{curl_cffi.__version__} (unsupported)'
    raise ImportError('Only curl_cffi versions 0.5.10 and 0.10.x through 0.15.x are supported')
```

Latest-and-greatest was one minor version too new. The fix was to pin below the ceiling:

```sh
python3 -m pip install "curl_cffi>=0.10,<0.16"
```

**Lesson:** when a library depends on another native-extension package for an optional feature, don't assume "latest" is "supported" — check for a version gate specifically on the feature you're trying to turn on, not just on whether the import succeeds.

## Collateral damage from `--force-reinstall`

The first install attempt used `--force-reinstall` to make sure the correct version actually took. It did — but it also silently upgraded packages that were already correctly pinned for something else entirely: `certifi`, `cffi`, `markdown-it-py`, and `pygments` all jumped to newer versions than another tool in the same shared Python environment required. `pip` said so plainly, right at the end of the install:

```
ERROR: pip's dependency resolver does not currently take into account all
the packages that are installed. This behaviour is the source of the
following dependency conflicts.
some-other-tool 2.15.0 requires certifi==2026.4.22, but you have
certifi 2026.7.22 which is incompatible.
some-other-tool 2.15.0 requires cffi==2.0.0, but you have cffi 2.1.1 ...
```

None of those four packages actually needed upgrading — `curl_cffi`'s own requirement (`cffi>=2.0.0`, `certifi>=2024.2.2`) was already satisfied by the versions in place. `--force-reinstall` doesn't just reinstall the package you named; it re-resolves and reinstalls its entire dependency subtree, and when it does that it grabs the latest version satisfying each constraint rather than leaving an already-satisfied pin alone. In a shared base environment with several unrelated tools installed, that's a quiet way to break something you weren't even looking at.

The fix was to pin those four straight back:

```sh
python3 -m pip install "certifi==2026.4.22" "cffi==2.0.0" \
  "markdown-it-py==4.0.0" "pygments==2.20.0"
```

**Lesson:** avoid `--force-reinstall` in a shared or base Python environment. If you need a specific version of one package, ask for exactly that (`pip install "pkg==x.y.z"`) rather than forcing a full dependency re-resolve you don't control.

## A new error, and a wrong theory

With the right `curl_cffi` version in place, the impersonation warning was gone — replaced by a new one, appearing on every single attempt:

```
SSLError: Failed to perform, curl: (35) TLS connect error:
error:00000000:invalid library (0):OPENSSL_internal:invalid library (0)
```

This looks exactly like a known class of `curl_cffi` bug: its bundled BoringSSL build can clash with another OpenSSL-family library already loaded in the same Python process — commonly `cryptography`, pulled in transitively by something unrelated like browser-cookie decryption support. The natural fix is isolation: a clean virtual environment with only `yt-dlp` and `curl_cffi`, nothing that could drag in a conflicting crypto library.

We built that environment. Same error, 100% reproducible, in complete isolation — no `cryptography`, no `secretstorage`, nothing else installed at all.

That result was more useful than a fix would have been. A clean-environment reproduction rules out an entire category of theories in one shot. It wasn't a Python packaging conflict. It had to be something outside Python's import graph.

## Stripping back to the dumbest possible test

The next step was to remove every layer of abstraction and test the actual thing that was failing: a TLS handshake over the proxy. Not `curl_cffi`. Not even `yt-dlp`. Plain, unimpersonated `requests`:

```python
import requests
r = requests.get("https://www.example.com",
                  proxies={"https": "http://127.0.0.1:8082"})
```

Same SSL error. Against a domain with nothing to do with the original site. That was the moment the whole investigation flipped: this was never a `curl_cffi` bug, or even a Python bug. Something about the proxy itself was breaking HTTPS.

Raw `curl` confirmed it in the plainest terms available:

```
* CONNECT tunnel established, response 200
> Client hello (1)
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.example.com:443
```

The proxy's `CONNECT` tunnel came up cleanly — a `200 Connection Established` — and then the TLS handshake died immediately afterward, for every client, on every site. Nothing about `curl_cffi`'s TLS fingerprint mattered; the tunnel itself wasn't relaying bytes correctly once real TLS traffic started flowing through it.

The proxy client had several selectable exit gateways by region. Switching from one region to another and rerunning the exact same `curl` command fixed it instantly — clean `200`, valid response, every time. The original gateway node was in a broken state for HTTPS relaying specifically; nothing in our code, `yt-dlp`, or `curl_cffi` was ever going to fix that from the client side.

## What actually shipped

Three real problems, three real fixes, none of them where the first error message pointed:

<Table data={
    {
        headers: ['Symptom', 'Looked like', 'Actually was'],
        rows: [
            ['HTTP 410: Gone', 'Stale yt-dlp / dead video', 'Site requires TLS impersonation'],
            ['curl_cffi "(unsupported)"', 'Broken install', "Version above yt-dlp's pinned ceiling"],
            ['Unrelated tool broke after install', 'Unrelated bug', '--force-reinstall re-resolved shared deps'],
            ['SSL "invalid library" error', 'curl_cffi vs OpenSSL clash', 'Proxy gateway failing the TLS relay'],
        ]
    }
} />

The lasting fix was to isolate `curl_cffi`-enabled `yt-dlp` into its own virtual environment — so a future dependency bump anywhere else on the machine can never touch it again — and to symlink the `PATH`-resolved `yt-dlp` at that environment's build, so every caller picks it up without extra configuration.

## The general shape of this kind of bug

None of the individual fixes here are exotic. What made this one take longer than it should have was trusting each error message's own framing for too long:

- **"410 Gone" told us the video was gone.** It wasn't — it was an anti-bot response wearing the shape of a different error.
- **"unsupported" told us the install was broken.** It wasn't broken, it was one version too new for a pin we didn't know existed.
- **"invalid library" pointed straight at `curl_cffi` and OpenSSL.** It was neither — it was a proxy gateway with a bad TLS relay.

The pattern that actually broke each false lead was the same one every time: reproduce with the fewest possible moving parts. A clean virtual environment ruled out the packaging theory. Plain `requests` with no impersonation ruled out `curl_cffi` entirely. Raw `curl` against an unrelated domain ruled out the target site. Each step removed one whole category of suspects instead of guessing at the next fix — and the actual root cause, when it finally showed up, wasn't in any of the code we'd been staring at.


9fa2ef35cdb16bce3f05bf518227a3d6de0d42440772c0f4c3b4eaddebedb611

How we debugged a yt-dlp 410 Gone error that wasn't staleness: curl_cffi TLS impersonation, a strict version-pinning gotcha, a --force-reinstall dependency mishap in a shared Python environment, and a proxy gateway failure that mimicked a library bug.

A yt-dlp download kept failing with 'HTTP Error 410: Gone' even on the latest version. The real cause was three layered problems stacked on top of each other: missing TLS impersonation, a narrow curl_cffi version-compatibility window, and an unrelated proxy gateway fault that looked exactly like a library bug.

Debugging a Fake 410: yt-dlp, curl_cffi, and a Proxy That Lied


{/* banner prompt: A vivid infographic-style scene where a stream of glowing data blocks flows through a semi-transparent proxy filter that visibly plucks out a single red block, labelled "0x08", causing a connection icon downstream to display a red error symbol "0x609". Clean light-gray background, sharp isometric perspective, muted blue-and-red palette, technical but clear. */}

RDP error 0x609 — "An authentication error has occurred" — is a CredSSP failure. The standard advice is to check your NLA settings, patch your CredSSP version, or relax the encryption level. None of it helped us, because the error only appeared when connecting *through a proxy*. Direct connections to the same server worked perfectly every time.

That asymmetry is the only clue you need. If direct works and proxied doesn't, the proxy is transforming something it shouldn't be.

## The setup

We were relaying RDP over a WebSocket tunnel — client connects to a local port, a relay forwards the raw TCP stream through a WebSocket connection to a gateway, gateway connects onward to the Windows machine. A standard CONNECT-style proxy, just over WebSocket instead of a raw TCP pipe.

The first phase of an RDP connection (X.224 → CredSSP → MCS → RDP) is negotiated in the clear before any screen data flows. Our relay passes bytes through untouched, so in theory the server should see exactly the same handshake whether or not a proxy is in the middle.

In theory.

## What 0x609 actually tells you

The Windows error 0x609 maps to `STATUS_LOGON_FAILURE` inside the CredSSP layer, but that description is misleading. It doesn't necessarily mean the credentials are wrong. It can also mean the CredSSP negotiation *completed* but the session couldn't be established afterwards — the error surfaces at the CredSSP layer because that's where the TLS channel lives, and whatever went wrong downstream comes back through it.

The useless nature of this error code is part of what makes 0x609 hard to debug. You're essentially told "something authentication-related failed" without any pointer to where in the multi-phase handshake the failure occurred.

## Reading the X.224 handshake

RDP starts with an X.224 Connection Request (CR) from the client. Buried inside the TPKT/X.224 framing is a `requestedProtocols` field — a bitmask that advertises which security layers the client supports:

- `0x01` — SSL/TLS
- `0x02` — NLA (CredSSP over NTLM/Kerberos), also called HYBRID
- `0x08` — HYBRID_EX (an extension to NLA used by modern Windows)

Modern `mstsc` sends `0x0b` — all three bits set. The server responds with an X.224 Connection Confirm (CC) that includes a `selectedProtocol` field indicating which mode it chose.

Here is where we found the divergence.

**Direct connection:** the CC came back with `selectedProtocol = 0x08` (HYBRID_EX).

**Through the proxy:** the CC came back with `selectedProtocol = 0x02` (HYBRID, plain NLA).

Same client. Same server. Different `selectedProtocol`. The proxy was changing something in the CR before it reached the server.

## The hidden transformation

The proxy had a small normalisation function applied to the first TCP frame on each new connection. Its purpose was compatibility: some older Windows environments support NLA but reject HYBRID_EX outright, returning an immediate RST. So the function detected the X.224 CR structure, read the `requestedProtocols` field, and cleared the `0x08` bit before forwarding.

The intent was conservative — strip the extended mode, keep plain NLA, everything still authenticates. It worked on the servers we originally tested it against.

What we hadn't accounted for: some Windows Server versions advertise both HYBRID and HYBRID_EX, but internally require the HYBRID_EX flow to complete a session correctly. When forced into HYBRID mode by the altered CR, they complete CredSSP — all five steps of the NTLM exchange succeed, credentials are verified — and then the MCS Connect-Initial fails. The session can't start.

The mechanism: HYBRID_EX adds a step that HYBRID omits. After the CredSSP exchange, the server sends an Early User Authorization Result PDU before the MCS layer begins. This PDU is part of the HYBRID_EX contract. When the server is put into HYBRID mode (because `0x08` was stripped from the CR), it doesn't send this PDU — but if the server's internal session setup expects it, or if the subsequent MCS framing depends on state that only HYBRID_EX establishes, the session fails. From the client's side it arrives as a 0x609.

In pseudo-code, what was happening:

```
# CR goes out with 0x0b (SSL | NLA | HYBRID_EX)
# proxy strips 0x08 → 0x03 (SSL | NLA)
# server selects HYBRID (0x02) — the highest it can given the offer
# CredSSP runs normally and succeeds
# server tries to start MCS in HYBRID_EX mode internally
# HYBRID_EX Early User Authorization PDU never arrives
# MCS Connect-Initial fails
# error surfaces as 0x609 on the CredSSP channel
```

## The fix

Remove the stripping entirely. Pass `requestedProtocols` through unchanged.

The original compatibility concern — older servers rejecting HYBRID_EX — turned out to be unwarranted in practice. Modern `mstsc` has been sending HYBRID_EX for years and servers handle it gracefully: if they don't support it they simply select a lower mode in the CC. The server's CC is the right place for that negotiation to happen, not a proxy in the middle.

## What to check if you hit this

If you're seeing 0x609 only through a proxy and direct connections work:

1. **Capture both sides of the relay.** You want the raw bytes the server sees, not the bytes the client sent. Log the first frame in each direction.

2. **Find the X.224 CC and read `selectedProtocol`.** It's a 4-byte little-endian value a few bytes into the CC. If it differs between direct and proxied connections, the proxy is rewriting the CR.

3. **Check for any transformation applied to the first message.** Header parsers, encoding normalizers, protocol fixups — anything that touches the first frame of a new TCP connection is a candidate.

4. **Compare `requestedProtocols` in the CR.** If the proxy is changing the bitmask, restore it to pass through verbatim and retest.

The broader principle: a byte-stream proxy should be transparent. Any transformation that modifies the protocol negotiation — even a seemingly harmless bit-clear — can break assumptions downstream that neither the proxy nor its author can fully anticipate.

The server, not the proxy, decides which protocol variant to use. Let it.


6a01956bb020c50d9f63b34a3f6be7e108447b2e7a723fabe945abf36bfa1498

How we debugged RDP error 0x609 appearing only through a WebSocket proxy, and why stripping the HYBRID_EX bit from the protocol negotiation breaks the entire session.

A CredSSP 0x609 error appearing only through a proxy but not on direct connections — traced to a single HYBRID_EX bit being silently stripped from the RDP X.224 handshake.

Debugging RDP 0x609: The Protocol Bit a Proxy Should Never Touch

{/* banner prompt: ### Style: Abstract Technical Architecture / Neon-Futurism

A sleek, abstract 16:9 banner representing a home office network gateway. Instead of a realistic router, the "gateway" is a translucent, crystalline geometric node glowing with internal pulses of cyan and deep violet light. From this central node, intricate, glowing circuits of neon data stream out into a dark, minimalist digital landscape. 

Thin, sharp lines of light represent IPv6 traffic (cyan) and IPv4 traffic (violet), flowing through the node and branching into a complex web of connections. Subtle, floating holographic code snippets like `ipv6 address autoconfig` and `ip route` shimmer in the air around the node. The background is a deep charcoal with a faint, receding digital grid, creating a sense of depth and sophisticated technical architecture. No realistic hardware, no ports, just the essence of a high-performance network bridge. --ar 16:9 */}

## The Goal

We have an old **Cisco 1941/K9** sitting on the shelf as a backup router. The main router — another Cisco 1941 — is handling NAT, DHCP, and internet access for a home office LAN on `192.168.8.0/24`. The ISP provides both IPv4 (DHCP) and IPv6 (native, with a `/48` delegation).

It's important to note that the Cisco 1941 is now quite outdated hardware and is no longer supported by Cisco. If your budget allows, you should definitely look into upgrading to a newer model. However, for a home office environment, if managed properly, these devices are absolute warhorses. They remain relatively safe, highly stable, and can still perform significantly better than most consumer-grade routers currently on the market.

The plan:

1. Access the backup router's console via a serial cable from an Alpine Linux machine (`alpine`)
2. Pull the running config from the main router
3. Add IPv6 (SLAAC + DHCPv6 for LAN clients)
4. Push the full config to the backup router over serial
5. Verify internet works through the backup router before doing the physical swap

## The Setup

```
ISP (IPv4 DHCP + IPv6 /48)
        |
   [Backup Cisco 1941]  ← Gi0/1 (WAN)
   192.168.8.1          ← Gi0/0 (LAN)
        |
   [alpine - Alpine Linux]  ← eth1 (192.168.8.2, connected to backup router)
   192.168.8.99         ← eth0 (connected to main router)
        |
   [Main Cisco 1941]
   192.168.8.1
```

`alpine` also has a DB9 serial cable going to the backup router's console port (`/dev/ttyS0`).

## Step 1: Console Access via Serial

Modern SSH clients don't support SSHv1, so until we configure SSHv2, serial console is our only way in. Alpine Linux has `screen` which works perfectly for this.

```bash
# Start a detached screen session on the console port
sudo screen -dmS cisco /dev/ttyS0 9600

# Attach to it
sudo screen -r cisco
```

The Cisco console defaults are **9600 baud, 8N1** — no need to change anything.

### Sending a Break Signal for ROMmon

Getting to `rommon>` requires sending a break signal within 60 seconds of power-on. The trick is to automate this so timing isn't an issue — fire the break loop, then power-cycle the router:

```bash
# Send break every second for 60 seconds
for i in $(seq 1 60); do
  sudo screen -S cisco -X break
  sleep 1
done
```

Power-cycle the router as soon as the loop starts. When it works, you'll see:

```
rommon 1 >
```

## Step 2: Pulling the Main Router's Config

The main router is running **SSHv1** (Cisco IOS default). Modern OpenSSH 8.0+ dropped SSHv1 entirely, so a standard `ssh` command will fail:

```
Protocol major versions differ: 2 vs. 1
```

The fix: run an old **Ubuntu 14.04** container which ships with OpenSSH 6.6 — the last version to support SSHv1.

```bash
docker run --rm -it --network host ubuntu:14.04 bash
```

Inside the container:

```bash
apt-get update && apt-get install -y openssh-client sshpass
sshpass -p 'yourpassword' ssh -1 -o StrictHostKeyChecking=no \
  admin@192.168.8.1 'show running-config'
```

Save the output — this is your baseline config to replicate on the backup router.

## Step 3: Building the Config with IPv6

The main router config becomes the template. The key additions for IPv6:

### Enable IPv6 Routing

```
ipv6 unicast-routing
ipv6 cef
```

### DHCPv6 Pool for LAN Clients

```
ipv6 dhcp pool LAN-V6
 dns-server 2001:4860:4860::8888
 dns-server 2001:4860:4860::8844
 domain-name yourdomain.com
```

### WAN Interface (Gi0/1)

```
interface GigabitEthernet0/1
 ip address dhcp
 ip nat outside
 ip virtual-reassembly in
 ipv6 address dhcp
 ipv6 address autoconfig default
 ipv6 enable
 ipv6 dhcp client pd ISP_PREFIX
 no shutdown
```

- `ipv6 address dhcp` — requests a WAN IPv6 address from the ISP via stateful DHCPv6
- `ipv6 address autoconfig default` — accepts SLAAC prefix and installs a default route via RA
- `ipv6 dhcp client pd ISP_PREFIX` — requests a delegated prefix (IA-PD); the ISP assigns a `/48` (e.g. `2403:580c:d9d4::/48`) which is bound to the label `ISP_PREFIX`

> **If DHCPv6-PD stays in SOLICIT indefinitely**, prefix delegation is not enabled on your account. Contact the ISP — ask them to enable "IPv6 Prefix Delegation (IA-PD)" for your service. They will assign you a static prefix (e.g. a `/48`). Once enabled it negotiates in seconds.
>
> Without PD, the ISP may assign the WAN address from the *same* `/64` as your LAN prefix, causing an "overlapping" conflict in IOS when you try to configure both interfaces. The workaround is to drop `ipv6 address dhcp` from the WAN, use only `ipv6 enable`, and assign the `/64` statically to the LAN — but LAN clients won't have IPv6 internet routing until PD is sorted.

### LAN Interface (Gi0/0)

```
interface GigabitEthernet0/0
 ip address 192.168.8.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
 ipv6 address ISP_PREFIX ::1/64
 ipv6 enable
 ipv6 nd other-config-flag
 ipv6 dhcp server LAN-V6
 no shutdown
```

- `ipv6 address ISP_PREFIX ::1/64` — assigns the first `/64` from the delegated `/48` to the LAN interface. With `2403:580c:d9d4::/48` delegated, this gives the router `2403:580c:d9d4::1/64` and advertises `2403:580c:d9d4::/64` to LAN clients via SLAAC. The remaining `/64`s (`2403:580c:d9d4:1::/64`, `2403:580c:d9d4:2::/64`, ...) are available for future VLANs or subnets.
- `ipv6 nd other-config-flag` — tells clients to use **SLAAC** for their address but get DNS/domain via DHCPv6 (stateless DHCPv6)
- `ipv6 dhcp server LAN-V6` — serves the DNS info from our pool above

### Static IPv6 Default Route

With only `ipv6 enable` or `autoconfig` on the WAN interface, you need a static default route so the router knows to send IPv6 traffic via the ISP:

```
ipv6 route ::/0 GigabitEthernet0/1 FE80::2A2:FF:FEB2:C2
```

Replace `FE80::2A2:FF:FEB2:C2` with your ISP gateway's link-local address — visible via `show ipv6 neighbors GigabitEthernet0/1` once the interface is up. If `ipv6 address autoconfig default` is configured, IOS will install a default route via RA automatically, so the static route is a belt-and-suspenders fallback.

### Enable SSH Version 2

While we're at it, fix the SSHv1 problem for the future:

```
ip domain name yourdomain.com
crypto key generate rsa modulus 1024
ip ssh version 2
```

## Step 4: Pushing Config via Serial

`screen`'s paste buffer drops characters at serial speeds. The most reliable approach is writing directly to the TTY device:

```bash
#!/bin/sh
TTY=/dev/ttyS0
stty -F $TTY 9600 cs8 -cstopb -parenb clocal -echo raw

send_line() {
    printf '%s\r\n' "$1" > $TTY
    sleep 0.8
}

# Authenticate
printf '\r\n' > $TTY; sleep 1
send_line "hello"           # console password
send_line "enable"
send_line "cisco2"          # enable password
send_line "configure terminal"

# Send config line by line
while IFS= read -r line; do
    printf '%s\r\n' "$line" > $TTY
    sleep 0.6
done < /home/dev/cisco/delta.cfg

send_line "end"
send_line "write memory"
```

Key points:
- Use `stty raw` to disable line buffering on the serial device
- 0.6–0.8 seconds per line is safe at 9600 baud
- Include `exit` commands between sub-modes (e.g. after `interface`, `line`) to avoid the router getting confused about context
- Read the config back with `show running-config` to verify

### Reading Output Back from the Serial Port

To capture what the router is saying, read from the TTY in the background while sending commands:

```bash
sudo cat /dev/ttyS0 > /tmp/router_output.txt &
CAT_PID=$!

# ... send commands ...

kill $CAT_PID
cat /tmp/router_output.txt
```

## Step 5: Verifying the Config

Once applied, check interfaces and IPv6:

```
show ip interface brief
show ipv6 interface brief
show ip nat statistics
show ip ssh
```

Expected output after correct configuration:

```
GigabitEthernet0/0    192.168.8.1     YES manual up   up
GigabitEthernet0/1    192.168.1.x     YES DHCP   up   up
```

And on the LAN client connected to `alpine`'s eth1:

```
eth1: inet6 2403:580c:ffff:35db:xxxx:xxxx:xxxx:xxxx/64
```

SLAAC is working when clients automatically pick up a `2403:580c:ffff:35db::/64` address.

## Step 6: Fixing Dual-NIC Asymmetric Routing on alpine

With `alpine` having two NICs on the same subnet (`192.168.8.0/24`) — one to the main router, one to the backup — Linux routing gets confused. Both are on `192.168.8.0/24`, so the kernel uses whichever it prefers (usually `eth0`) for both.

This means pings sent **out** `eth1` get their **replies routed back via eth0** — the backup router never sees the return traffic.

The fix is **policy routing** — a separate routing table for traffic sourced from `eth1`:

```bash
# Create a routing table for eth1
echo '200 eth1table' >> /etc/iproute2/rt_tables

# Populate it
ip route add 192.168.8.0/24 dev eth1 src 192.168.8.2 table 200
ip route add default via 192.168.8.1 dev eth1 table 200

# Rule: if source is eth1's IP, use table 200
ip rule add from 192.168.8.2 table 200
```

Verify:

```bash
ping -I eth1 -c 3 8.8.8.8
# Should succeed with ~20ms latency
```

To make it persistent, add to `/etc/network/interfaces`:

```
auto eth1
iface eth1 inet dhcp
    post-up ip route add 192.168.8.0/24 dev eth1 src 192.168.8.2 table 200
    post-up ip route add default via 192.168.8.1 dev eth1 table 200
    post-up ip rule add from 192.168.8.2 table 200
    pre-down ip rule del from 192.168.8.2 table 200
```

## Step 7: SSH Shortcut on alpine

Add to `~/.ssh/config` on `alpine` so you can reach the backup router with a simple alias:

```
Host backup-router
    HostName 192.168.8.1
    User admin
    BindAddress 192.168.8.2
    KexAlgorithms +diffie-hellman-group14-sha1
    HostKeyAlgorithms +ssh-rsa
    Ciphers +aes128-cbc
```

Then just:

```bash
ssh backup-router
```

The `BindAddress 192.168.8.2` forces SSH to source from `eth1`, which the policy routing table picks up and routes correctly through the backup router.

## Step 8: Lock Down SSH to LAN Only

Once the router is live on the internet, its public WAN IP (`117.20.x.x`) is immediately visible to automated scanners. By default, SSH is accessible from anywhere. Lock it down to LAN-only with an access-class:

```
ip access-list standard SSH_ACCESS
 permit 192.168.8.0 0.0.0.255
 deny any log
!
line vty 0 4
 access-class SSH_ACCESS in
```

The `deny any log` is important — it logs every blocked attempt, so you can see `show ip access-lists SSH_ACCESS` and watch the hit counter climb. Within minutes of the router going live, you'll see external scanners already hitting it.

The router still listens on TCP port 22 from the WAN side (Cisco doesn't close the port), but drops the connection before authentication for any source IP outside `192.168.8.0/24`. SSH from inside your LAN works normally.

## The Swap

Once verified, the physical swap is straightforward:

1. Unplug the main router's WAN and LAN cables
2. Plug them into the backup router's Gi0/1 (WAN) and Gi0/0 (LAN)
3. The backup router takes over at `192.168.8.1` with identical config + IPv6

LAN clients don't notice — same gateway IP, same DHCP pool, same DNS. They'll additionally start getting IPv6 addresses via SLAAC automatically.

> **Note — give the modem time after the swap.** After plugging the WAN cable into the new router, `Gi0/1` may show `up/up` physically but receive zero DHCP response for several minutes. This is normal — the modem (especially after a reset) needs time to fully come back up and accept a new client. If `show dhcp lease` shows state `Purging` and `DHCP Lease server: 0.0.0.0`, just wait 2–5 minutes before troubleshooting further. You can monitor with:
> ```
> show interface GigabitEthernet0/1 | include input rate|Last input
> ```
> Once you see `input rate` climbing above 0 and `Last input` ticking, the modem is responding and a DHCP lease will follow shortly.

{/* ## Scripts

All scripts used in this process are saved at `/home/dev/cisco/` on `alpine`:

<Table data={{
    headers: ["Script", "Purpose"],
    rows: [
        ["backup_router.cfg", "Full config mirrored from main router + IPv6"],
        ["delta.cfg", "Interface, NAT, line configs (the parts applied separately)"],
        ["send_config.sh", "Push full config via /dev/ttyS0"],
        ["send_delta.sh", "Push delta config via /dev/ttyS0"],
        ["get_config.sh", "Read show running-config from router via serial"],
        ["check_wan.sh", "Check WAN interface + test ping from router"],
        ["check_wan2.sh", "Check interface brief + NAT + ping alpine"],
        ["check_nat.sh", "Check NAT translations and statistics"],
        ["fix_ssh.sh", "Generate RSA keys + enable SSH v2"],
        ["fix_users.sh", "Reset admin/eric passwords via console"],
    ],
}}
/> */}

## Key Takeaways

- **SSHv1 routers**: use an old Ubuntu 14.04 Docker container with OpenSSH 6.6 — it's the cleanest solution
- **Serial config push**: write directly to the TTY device, not through `screen`'s paste buffer — it's more reliable
- **IPv6 on Cisco IOS**: `ipv6 nd other-config-flag` + `ipv6 dhcp server` gives you SLAAC addresses + DHCPv6 DNS info, which is all most LAN clients need
- **ISP IPv6 PD**: if DHCPv6-PD stays in SOLICIT indefinitely, your ISP doesn't have it enabled — contact them and ask for "IPv6 Prefix Delegation (IA-PD)". Once enabled, the ISP assigns a `/48` and LAN clients get full IPv6 internet via SLAAC automatically
- **Dual-NIC same subnet**: always use policy routing — two default routes with different metrics is not enough when both NICs share a subnet
- **Lock down VTY immediately**: apply `access-class` to restrict SSH to LAN-only before the router goes live on the internet — scanners hit public IPs within minutes


bf27aa21c6f355c8c62478779933e48cb61fddb92f0f1202b983b75a35c64e0c

A practical walkthrough of configuring a Cisco 1941/K9 router as a home office gateway backup. Covers console access from Alpine Linux using screen, pulling config from a live router via SSHv1 in Docker, adding IPv6 (SLAAC + DHCPv6), pushing config over serial, and fixing policy routing on a dual-NIC Linux host.

How to set up a Cisco 1941/K9 as a home office gateway — including console access via serial, cloning config from a running router, adding IPv6 with SLAAC and DHCPv6, and fixing dual-NIC asymmetric routing on Alpine Linux.

Configure a Cisco 1941 Router as Your Home Office Gateway with IPv6

{/* banner prompt: Of course! Here are a few creative and engaging prompts for a banner image, designed to capture the essence of the blog post.

### Main Prompt (Cinematic & Evocative)

This prompt focuses on the "resurrection" theme of bringing old hardware back to life with modern, efficient software.

**Prompt:**
> A cinematic, dramatic shot of a dusty, forgotten 90s-era beige PC tower sitting on a workbench in a dimly lit workshop. A brilliant, glowing blue USB cable connects a modern Android smartphone to the PC's front port, acting as a lifeline. Ethereal, glowing data streams, shaped subtly like the Alpine Linux mountain logo, emanate from the PC's vents, illuminating the scene and casting long shadows. The old machine hums with new purpose, transformed into a powerful network gateway. Moody, high-contrast lighting, tech noir aesthetic, hyper-realistic, 8k. --ar 16:9

---

### Alternative Prompts

Here are two other options with different artistic styles.

#### Option 2 (Technical & Stylized)

This prompt emphasizes the technical, blueprint-like nature of the project.

**Prompt:**
> A stylized, futuristic blueprint schematic on a dark grid background, illustrating the post's network topology. At the top, a sleek icon of an Android phone connects via a glowing USB data line to a central, semi-transparent block representing an old computer. The iconic Alpine Linux mountain logo glows brightly from within this central block. From the block, a solid ethernet data stream flows out to a home router icon. The entire image has a clean, technical, and cyberpunk feel, with digital annotations and connection labels. Widescreen, vector illustration style, highly detailed. --ar 16:9

#### Option 3 (Minimalist & Symbolic)

This prompt focuses on the core components in a clean, modern, and symbolic way.

**Prompt:**
> A minimalist composition on a clean, dark grey background. In the center, a simple, iconic representation of an old PC case is given new life. A single, vibrant cyan USB cable plugs into it from one side, originating from an abstract smartphone shape. From the other side, a stable, glowing ethernet cable extends outwards. The Alpine Linux mountain symbol is subtly but clearly etched onto the side of the PC case, glowing with a soft white light. The image conveys elegance, efficiency, and the concept of "powerful simplicity." Professional product shot style, soft studio lighting. --ar 16:9 */}

# Building a 4G/5G Backup Mobile Gateway with Alpine Linux on Old Hardware

*How to repurpose an outdated PC into a reliable backup internet gateway using Android USB tethering*

---

## The Problem

Internet goes down. It always does at the worst possible time. However, even though that only happens a couple of times a year, an always-on 4G/5G backup isn't strictly necessary. It would be nice to have a plug-and-play solution—like using your phone (which probably has plenty of data) as a rescue for those few hours of downtime.

If you have a spare Android phone and an old PC gathering dust, you can build a proper backup gateway that kicks in when your main connection fails — no expensive hardware required.

This guide walks through the entire process, including the real-world gotchas encountered along the way.


## Hardware Requirements

- An old/low-powered PC (sub 1GHz, even under 512MB RAM is workable)
- One or two ethernet NICs (two is ideal, one works fine)
- A USB port for the Android phone
- An Android phone with a mobile data plan
- A USB stick (2GB+ is plenty) to install from

For this project, I used a rugged industrial PC made by **Advantech Australia**. It's equipped with an **Intel Atom D510 CPU** and **2GB of memory**. Its industrial build and dual NIC cards make it a perfect "warhorse" for a dedicated gateway role. 

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/04/repurpose-your-old-pcs-how-to-install-alpine-linux-on-them/2026-04-20-19-42-33.png)

The machine used in this guide had two onboard NICs, an 8GB internal flash module (DOM — Disk on Module), and a larger hard drive set aside for backups. Very modest specs, perfectly adequate for a router role. Please execute me for the dust collected on this machine.


## Why Alpine Linux?

For low-powered hardware doing a single job, Alpine Linux is the right tool:

- Boots in under 5 seconds
- Idles at ~30–50MB RAM
- Tiny base install (~130MB on disk)
- Uses OpenRC (no systemd overhead)
- The `rndis_host` kernel module handles Android USB tethering natively — no extra drivers needed
- Actively maintained, security-focused

Other options like Debian minimal or OpenWrt on x86 are also viable, but Alpine wins on resource footprint for truly constrained hardware.


## Network Topology

With two NICs the setup is clean — no double-NAT:

```
Android Phone (USB tethering)
        |
        | usb0
  [Alpine Linux PC]
   eth0  |  eth1
    |         |
Your Router  (spare / unused)
 (WAN port)
```

With a single NIC, the same approach works — `eth0` connects to your router's WAN port, `usb0` is the phone. Your router handles the LAN side as normal. The Alpine box just NATs between `usb0` and `eth0`.

> **Note on double-NAT:** With a single NIC and a typical home router, you'll have three layers of NAT (phone → Alpine → router). For general internet use this is completely fine. Port forwarding gets complicated, but for a backup scenario it's a non-issue.


## Step 1: Creating the Install USB

Download the Alpine Linux "standard" x86 ISO from [alpinelinux.org](https://alpinelinux.org/downloads/).

Write it to a USB stick using `dd`:

```bash
dd if=alpine-standard-x.x.x-x86.iso of=/dev/sdX bs=4M status=progress
```

Replace `/dev/sdX` with your USB stick's device. **Double-check this** — `dd` will happily wipe whatever you point it at.

> **Important:** Use `dd` directly, or Rufus in **DD mode** if on Windows. Do not let Rufus create a FAT32 partition layout — old BIOSes can choke on it. Alpine ISOs are hybrid MBR images and work correctly when written raw.


## Step 2: BIOS Boot Gotchas (American Megatrends)

Old AMI BIOS boards have a few quirks that can stop USB boot from working even when USB is set as first priority:

- **Plug the USB in before powering on.** USB drives often only appear in the boot device list if they're present at POST time.
- **Check for two separate boot priority menus.** AMI BIOS often has a top-level device-type priority (Removable → HDD → CD) *and* a separate submenu for ordering within each type. The USB stick needs to be first in *both* places.
- **Enable Legacy USB Support** — usually found under Advanced or Integrated Peripherals.
- **Use a rear USB 2.0 port.** Front panel ports and USB 3.0 ports are often ignored by old BIOSes during boot enumeration.
- **Use a USB 2.0 flash drive** if possible. USB 3.0 sticks can fail to enumerate on old BIOSes.
- **Try the one-time boot menu first** — on most AMI boards, hit **F8** or **F11** at POST. This bypasses the boot order entirely and lets you pick the USB stick directly, which is useful for confirming the stick itself is bootable before adjusting BIOS settings.

In my case, I was finally able to have it boot into the Alpine Linux installation interface after plugging the USB drive into the back (rear) of the machine.

---

## Step 3: Identifying Your Disks

Once booted into the Alpine live environment, identify your drives before installing:

```sh
cat /proc/partitions
```

Example output:

```
8    0  312571224  sda     ← ~150GB (Windows drive)
8   16    7880544  sdb     ← ~7.5GB (target install drive)
8   32    3910656  sdc     ← ~3.7GB (Alpine USB stick)
```

To confirm the nature of a drive — particularly whether it's a USB device or an internal flash module:

```sh
dmesg | grep sdb
```

If the output references `sd X:X:X:X` (SCSI enumeration) rather than `usb-storage`, the drive is connected internally — likely a DOM (Disk on Module), common on older appliance-grade hardware. These are perfectly fine for Alpine and handle the low write workload of a router OS well.

> **Tip:** A drive formatted as FAT32 with write cache disabled and a single partition spanning the whole disk is a typical signature of a factory-installed DOM or embedded flash device.

---

## Step 4: Installing Alpine

Run the setup script:

```sh
setup-alpine
```

Work through the prompts:

- **Keyboard layout:** your preference
- **Hostname:** something useful, e.g. `mobile-gateway`
- **Network interface:** configure `eth0` for DHCP during install; skip `eth1` for now
- **Root password:** set something strong
- **Timezone:** your local timezone
- **NTP client:** choose **chrony** (see note below)
- **Mirror:** pick a geographically close one or `r` for auto-detect
- **SSH:** `openssh` is fine
- **Disk mode:** type `sys` — this is a standard permanent install to disk
- **Which disk:** type the device name of your target drive (e.g. `sdb`)

The installer will wipe the selected disk and install Alpine. When finished, remove the USB stick and reboot.

### Why chrony for NTP?

For a machine that's offline frequently or has intermittent connectivity — exactly the backup router use case — chrony is the best choice. It handles time jumps gracefully when connectivity comes and goes, and compensates for clock drift between connections. `busybox-ntpd` is too basic for this, and `openntpd` handles irregular connectivity less gracefully than chrony.

---

## Step 5: Post-Install — Making It Boot

If the machine boots back into another OS after install, the BIOS is still preferring the wrong drive. Go back into BIOS and find the **Hard Disk Drive Priority** submenu — set your Alpine drive (the 8GB/DOM one) as first in that list.

Use the one-time boot menu (F8/F11) to test first — select your Alpine drive directly to confirm it boots before making the BIOS change permanent.

---

## Step 6: Configuring USB Tethering

Plug in the Android phone and enable **USB Tethering** from the phone's settings (usually under Settings → Network → Hotspot & Tethering).

The Alpine kernel will load `rndis_host` automatically and a new interface will appear — typically `usb0`:

```sh
ip link show
```

Bring it up and get an IP via DHCP from the phone:

```sh
udhcpc -i usb0
```

Test connectivity:

```sh
ping -c 3 1.1.1.1 -I usb0
```

---

## Step 7: NAT and IP Forwarding

Install iptables if not already present:

```sh
apk add iptables
```

Enable IP forwarding:

```sh
echo 1 > /proc/sys/net/ipv4/ip_forward
```

Set up NAT (assuming `usb0` = WAN, `eth0` = LAN out to router):

```sh
iptables -t nat -A POSTROUTING -o usb0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o usb0 -j ACCEPT
iptables -A FORWARD -i usb0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
```

Make IP forwarding persistent — add to `/etc/sysctl.conf`:

```
net.ipv4.ip_forward = 1
```

Save and persist iptables rules across reboots:

```sh
rc-update add iptables
/etc/init.d/iptables save
```

---

## Step 8: Hotplug Script (Plug In and It Just Works)

Rather than running commands manually every time, Alpine's `mdev` can detect when the phone is plugged in via USB and automatically bring up the tethering interface and routing.

Create `/etc/mdev/usb-tether.sh`:

```sh
#!/bin/sh
# Called by mdev when a USB network interface appears

IFACE="usb0"

if [ "$ACTION" = "add" ] && ip link show "$IFACE" > /dev/null 2>&1; then
    udhcpc -i "$IFACE" -q
    iptables -t nat -A POSTROUTING -o "$IFACE" -j MASQUERADE
    iptables -A FORWARD -i eth0 -o "$IFACE" -j ACCEPT
    iptables -A FORWARD -i "$IFACE" -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
fi
```

Make it executable:

```sh
chmod +x /etc/mdev/usb-tether.sh
```

This gives you plug-in activation — connect the phone, USB tethering enables on the phone, and the gateway comes up automatically. Unplug to deactivate.

---

## Second NIC — What to Do With It

If your machine has two NICs, you have more flexibility:

- **eth0** — connect to your router's WAN port (LAN out)
- **eth1** — leave unconfigured unless you need a second downstream device connected directly

There's no need to bridge or assign an IP to `eth1` for a basic single-router setup. Leave it unconfigured and use it later if needed.

---

## Summary

{/* | Component | Choice | Reason |
|-----------|--------|--------|
| OS | Alpine Linux | Minimal footprint, fast boot, good hardware support |
| NTP | chrony | Handles intermittent connectivity gracefully |
| Tethering | Android USB (rndis_host) | Native kernel support, no extra drivers |
| Install mode | sys | Standard permanent disk install |
| Activation | mdev hotplug | Plug-in and it just works | */}

The end result is a machine that sits quietly on the shelf, draws minimal power, and becomes a functional mobile gateway the moment you plug a phone into it — no GUI, no fuss, no expensive hardware.

---

*Built and tested on an old low-powered PC with AMI BIOS, dual onboard NICs, and an internal DOM flash drive. Alpine Linux 3.x.*

2c3a46c60c6e9cc4ef710506425dabc985899f2bfc048c9968ed99cf2fe490db

A step-by-step guide to installing Alpine Linux on old, low-powered hardware and configuring it as a mobile backup gateway using Android USB tethering. Covers BIOS quirks, disk identification, NAT/iptables setup, and hotplug automation with mdev.

Turn an old, dusty PC into a reliable 4G/5G backup internet gateway using Alpine Linux and Android USB tethering — no expensive hardware required.

Repurpose Your Old PCs: How To Install Alpine Linux on Them

{/* banner prompt: Of course! Based on the blog post, here are three creative and engaging banner image prompts, each with a different artistic direction. They all capture the core idea of using a phone as a clever, cost-effective backup internet solution.

---

### Option 1: The Digital Lifeline (Conceptual & Dynamic)

**Prompt:**

A dynamic, conceptual illustration of network failover. In the center, a large, futuristic fiber-optic data highway is visibly broken and dark, representing a failed primary internet connection. From the side, a glowing green USB cable connects a modern Android smartphone to a small, sleek mini-PC. This connection creates a vibrant, glowing data bridge that bypasses the broken highway, seamlessly redirecting streams of light (data packets) to a small office network. The scene is set in a dark, tech-themed environment with blue and green neon accents. Style: digital art, high detail, cinematic lighting. **--ar 16:9**

**Why it works:** This prompt visualizes the core concept of a "backup bridge" in a dramatic and futuristic way. The contrast between the broken primary path and the active mobile lifeline makes the solution's purpose instantly clear.

### Option 2: The Smart Switch (Infographic & Clean)

**Prompt:**

A sleek, futuristic infographic-style artwork. Visualize two incoming data streams: a massive, primary blue stream labeled "WAN" that is flickering and disrupted, and a secondary, vibrant green stream originating from an Android phone, labeled "Mobile Backup". Both streams converge on a central, intelligent cube-like gateway device featuring a subtle Alpine Linux penguin logo. The gateway is actively routing the green stream forward, while the blue stream is blocked. The background is a clean, dark gray with a digital grid pattern. The entire image has a clean, high-tech aesthetic with glowing lines and crisp vectors. **--ar 16:9**

**Why it works:** This prompt focuses on the "intelligence" of the solution. It presents the Alpine Linux box as the central brain making a smart decision, which aligns perfectly with the technical, how-to nature of the blog post.

### Option 3: The DIY Hero (Photorealistic & Relatable)

**Prompt:**

A photorealistic shot of a modern tech enthusiast's desk. In the foreground, a compact mini-PC (like an Intel NUC) is the hero, with a subtle Alpine Linux logo visible on a tiny monitor next to it. A braided USB-C cable connects the PC to an Android smartphone, its screen showing the 'USB Tethering Active' notification. Glowing ethernet ports show data flowing out. In the soft-focus background, a primary internet router is clearly visible with a blinking red warning light, indicating an outage. The mood is resourceful and clever, with warm, focused lighting on the foreground setup. **--ar 16:9**

**Why it works:** This prompt grounds the concept in reality, showing the actual components described in the article. It creates a relatable, "I can build that" feeling and highlights the cost-effective, DIY spirit of the solution.

Additional instructions: a flying angel holding a mobile phone */}

## The Problem

For small businesses and home offices, internet downtime is painful. When your primary NBN connection goes down — whether it's a cable fault, an ISP outage, or a modem failure — everything grinds to a halt. Emails stop, video calls drop, cloud tools become unreachable.

The obvious fix is a backup WAN connection, but most solutions involve:
- A dedicated 4G/5G router (~$200–$500)
- A second SIM card with a separate data plan (~$20–$50/month)

That's recurring cost for something you only need occasionally.

## The Better Solution: Use Your Existing Phone

Here's the insight: you almost certainly already have a mobile phone on a plan that includes data. When NBN goes down, that phone in your pocket already *is* a backup internet connection — you just need a way to share it with your whole network instead of just your phone.

Android's **USB tethering** feature turns your phone into a USB network adapter. Plug it into a Linux box and it appears as a regular ethernet interface (`usb0`). From there, you can route your entire network's traffic through it.

**What this costs you:**
- An old PC, mini PC, or single-board computer (even a Raspberry Pi works) — something you may already have spare
- A USB cable
- Your existing phone and mobile plan
- No extra SIM, no extra monthly bill

## Architecture

The setup uses a dedicated Alpine Linux box (we'll call it `mg`) sitting on your LAN alongside your primary NBN router.

```
Normal (NBN up):
  Clients → mg (192.168.8.99) → NBN router (192.168.8.1) → Internet

Failover (NBN down):
  Clients → mg (192.168.8.99) → usb0 (Android phone) → Mobile Internet
```

Clients point their default gateway to `mg`. When NBN is up, `mg` transparently forwards traffic to the NBN router. When NBN fails, you run one command on `mg` and it switches to routing via the phone. Clients don't change anything.

## Requirements

- A PC or mini box with at least one ethernet port, running **Alpine Linux**
- An **Android phone** with USB tethering capability (virtually all modern Android phones)
- A USB cable (USB-A to USB-C or Micro-USB depending on your phone)
- SSH access to the Alpine box

## Step 1: Install iptables

Alpine Linux is minimal by default. Install `iptables` for NAT:

```bash
sudo apk add iptables
```

## Step 2: Enable IP Forwarding

The box needs to forward packets between interfaces like a router:

```bash
echo "net.ipv4.ip_forward = 1" | sudo tee /etc/sysctl.d/99-forwarding.conf
sudo sysctl -w net.ipv4.ip_forward=1
```

## Step 3: Add USB Interface to Network Config

When Android USB tethering is active, it appears as `usb0`. Tell Alpine to obtain a DHCP address from the phone on that interface:

```bash
sudo tee -a /etc/network/interfaces > /dev/null << 'EOF'

# USB tethering (Android backup WAN)
iface usb0 inet dhcp
EOF
```

The kernel modules `rndis_host` and `cdc_ether` handle Android USB tethering. On a standard Alpine install with a reasonably modern kernel, these are already present and loaded automatically when the phone is plugged in with tethering enabled.

## Step 4: iptables Rules at Boot

Create a startup script that sets up NAT and forwarding rules every time the machine boots:

```bash
sudo tee /etc/local.d/wan-setup.start > /dev/null << 'EOF'
#!/bin/sh
# WAN gateway iptables setup

sysctl -w net.ipv4.ip_forward=1

# FORWARD chain — drop by default, allow LAN traffic out via either WAN
iptables -P FORWARD DROP
iptables -F FORWARD
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o usb0 -j ACCEPT

# NAT — masquerade outbound on both WAN paths
iptables -t nat -F POSTROUTING
iptables -t nat -A POSTROUTING -o eth0 ! -d 192.168.8.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o usb0 -j MASQUERADE
EOF

sudo chmod +x /etc/local.d/wan-setup.start
sudo rc-update add local default
```

Apply the rules immediately without rebooting:

```bash
sudo sh /etc/local.d/wan-setup.start
```

**Why MASQUERADE on `eth0`?** When `mg` forwards a client's packet to the NBN router, without masquerading the source IP is the client's (e.g. `192.168.8.50`). The NBN router sends the reply directly back to that client, bypassing `mg` — breaking the connection tracking. MASQUERADE rewrites the source to `mg`'s own IP (`192.168.8.99`), so all return traffic flows back through `mg` correctly.

## Step 5: The Failover Script

This script handles detecting whether the primary WAN is up and switching routes accordingly. Save it to `/usr/local/bin/wan-failover.sh`:

```bash
sudo tee /usr/local/bin/wan-failover.sh > /dev/null << 'EOF'
#!/bin/sh
# wan-failover.sh — WAN failover between NBN (eth0) and USB tethering (usb0)
# Usage: wan-failover.sh [auto|primary|backup|status|check]

PRIMARY_GW="192.168.8.1"
LAN_IFACE="eth0"
USB_IFACE="usb0"
CHECK_HOST="8.8.8.8"
CHECK_HOST2="1.1.1.1"
STATE_FILE="/var/run/wan-mode"
LOG="/var/log/wan-failover.log"

log() {
    printf '%s %s\n' "$(date '+%Y-%m-%d %H:%M:%S')" "$1" | tee -a "$LOG"
}

get_mode() {
    cat "$STATE_FILE" 2>/dev/null || echo "primary"
}

check_primary_wan() {
    # Force the check through the primary gateway by adding temporary host routes.
    # This ensures the test uses eth0 even if the current default route is via usb0.
    ip route replace "${CHECK_HOST}/32" via "$PRIMARY_GW" dev "$LAN_IFACE" 2>/dev/null
    ping -c 3 -W 2 "$CHECK_HOST" > /dev/null 2>&1
    result=$?
    ip route del "${CHECK_HOST}/32" 2>/dev/null

    if [ $result -ne 0 ]; then
        ip route replace "${CHECK_HOST2}/32" via "$PRIMARY_GW" dev "$LAN_IFACE" 2>/dev/null
        ping -c 3 -W 2 "$CHECK_HOST2" > /dev/null 2>&1
        result=$?
        ip route del "${CHECK_HOST2}/32" 2>/dev/null
    fi
    return $result
}

bring_up_usb() {
    if ! ip link show "$USB_IFACE" > /dev/null 2>&1; then
        log "ERROR: $USB_IFACE not found — enable USB tethering on the phone first"
        return 1
    fi
    ip link set "$USB_IFACE" up
    udhcpc -i "$USB_IFACE" -q -n -t 5 > /dev/null 2>&1
    ip addr show "$USB_IFACE" | grep -q 'inet ' && return 0
    log "ERROR: Failed to get DHCP lease on $USB_IFACE"
    return 1
}

clear_default_routes() {
    # Remove all current default routes to start clean
    while ip route del default 2>/dev/null; do :; done
}

switch_to_backup() {
    log "Primary WAN DOWN — switching to USB backup..."
    bring_up_usb || return 1

    USB_GW=$(ip route show dev "$USB_IFACE" | awk '/^default/{print $3}' | head -1)
    if [ -z "$USB_GW" ]; then
        log "ERROR: Could not determine USB gateway IP"
        return 1
    fi

    clear_default_routes
    ip route add default via "$USB_GW" dev "$USB_IFACE" metric 10
    echo "backup" > "$STATE_FILE"
    log "Routing via USB ($USB_GW). Mode: BACKUP"
}

switch_to_primary() {
    log "Primary WAN UP — switching back to NBN..."
    clear_default_routes
    ip route add default via "$PRIMARY_GW" dev "$LAN_IFACE" metric 1
    echo "primary" > "$STATE_FILE"
    log "Routing via $PRIMARY_GW. Mode: PRIMARY"
}

status() {
    printf 'Mode:     %s\n' "$(get_mode)"
    printf 'Default:  '; ip route show default
    printf 'eth0:     '; ip addr show "$LAN_IFACE" | awk '/inet /{print $2}'
    if ip link show "$USB_IFACE" > /dev/null 2>&1; then
        printf 'usb0:     '; ip addr show "$USB_IFACE" | awk '/inet /{print $2}'
    else
        printf 'usb0:     not present\n'
    fi
}

case "${1:-auto}" in
    auto)
        mode=$(get_mode)
        if check_primary_wan; then
            if [ "$mode" = "backup" ]; then
                switch_to_primary
            else
                log "Primary WAN OK"
            fi
        else
            if [ "$mode" = "primary" ]; then
                switch_to_backup
            else
                log "Primary WAN still DOWN, staying on backup"
            fi
        fi
        ;;
    primary)  switch_to_primary ;;
    backup)   switch_to_backup ;;
    status)   status ;;
    check)
        if check_primary_wan; then echo "Primary WAN: UP"
        else echo "Primary WAN: DOWN"; fi
        ;;
    *)
        echo "Usage: $0 [auto|primary|backup|status|check]"
        exit 1
        ;;
esac
EOF

sudo chmod +x /usr/local/bin/wan-failover.sh
```

## Step 6: Point Clients to mg

For each machine on your network that you want covered by the failover, change its default gateway from the NBN router's IP to `mg`'s IP (`192.168.8.99`).

- **Windows:** Network adapter settings → IPv4 → Default gateway
- **macOS:** System Settings → Network → Details → TCP/IP → Router
- **Linux:** See below

Alternatively, do it centrally: log into your NBN router's admin page and change the **DHCP gateway option** to `192.168.8.99`. All clients pick this up on their next DHCP renewal with no per-machine changes required.

### Linux: Gateway Switcher Scripts

On Linux, DHCP may leave behind its own default route when you try to change the gateway, resulting in two conflicting defaults. The safest approach is to flush all default routes first, then add the one you want.

Create two convenience scripts in `~/bin/`:

**`~/bin/gw-backup`** — switch to mg (backup WAN):

```bash
#!/bin/bash
while sudo ip route del default 2>/dev/null; do :; done
sudo ip route add default via 192.168.8.99 dev enp2s0 metric 100
echo "Gateway → mg (192.168.8.99) [backup WAN]"
ip route show default
```

**`~/bin/gw-primary`** — switch back to NBN router:

```bash
#!/bin/bash
while sudo ip route del default 2>/dev/null; do :; done
sudo ip route add default via 192.168.8.1 dev enp2s0 metric 100
echo "Gateway → NBN router (192.168.8.1) [primary WAN]"
ip route show default
```

Make them executable:

```bash
chmod +x ~/bin/gw-backup ~/bin/gw-primary
```

Then switching is just:

```bash
gw-backup    # route via mg when NBN is down
gw-primary   # route via NBN router when NBN is back
```

> **Note:** Replace `enp2s0` with your actual interface name (`ip link show` to check). These changes are not persistent across reboots or DHCP renewals — run the script again if needed.

## Using the Failover Script

```bash
wan-failover.sh            # auto: check primary WAN, switch if needed
wan-failover.sh check      # test if primary WAN is up (without switching)
wan-failover.sh status     # show current mode and interface IPs
wan-failover.sh backup     # manually force switch to phone
wan-failover.sh primary    # manually force switch back to NBN
```

## When NBN Goes Down: Step by Step

**1. Enable USB tethering on your Android phone**

On your phone: *Settings → Network & Internet → Hotspot & Tethering → USB Tethering* (on)

Plug the phone into `mg` via USB.

**2. SSH into mg and switch to backup**

```bash
ssh mg
sudo wan-failover.sh backup
```

**3. Verify**

```bash
sudo wan-failover.sh status
ping 8.8.8.8
```

You should see `usb0` with an IP address and pings going through. Clients on the network are now using mobile data transparently — no changes needed on their end.

**4. When NBN comes back**

```bash
sudo wan-failover.sh primary
```

Clients resume using NBN automatically.

## How It Works Under the Hood

When you run `wan-failover.sh backup`, the script:

1. Checks `usb0` exists (phone is plugged in with tethering on)
2. Brings the interface up and runs `udhcpc` to get a DHCP lease from the phone
3. Reads the gateway IP assigned by the phone (typically `192.168.42.129`)
4. Flushes all existing default routes, then adds a single clean one: `ip route add default via 192.168.42.129 dev usb0`

The flush step matters. When `udhcpc` gets a lease it automatically injects its own default route. Without clearing first, you end up with two default routes — the old primary and the new backup — and the kernel picks whichever has the lower metric, which may not be what you want. The `clear_default_routes` loop removes all of them before adding the correct one.

Android's USB tethering uses the RNDIS protocol, which the `rndis_host` kernel module handles. The phone acts as both a DHCP server and a NAT gateway to the mobile network. From the kernel's perspective, `usb0` is just another ethernet interface.

The `check_primary_wan` function tests internet reachability *through* the primary gateway specifically — even if the default route is already pointing at `usb0`. It does this by temporarily injecting a host-specific route (`8.8.8.8/32 via 192.168.8.1`), pinging, then removing it. This prevents the check from falsely succeeding via the backup connection while testing the primary.

## Keeping Costs at Zero

The entire ongoing cost of this solution is **zero**. Your phone's existing mobile plan absorbs the data usage during outages. Most modern plans include more than enough data for light business use — email, web browsing, cloud tools for a small team — for the duration of a typical NBN outage.

Contrast this with a dedicated 4G router plus a SIM plan that costs money every single month regardless of whether your NBN ever goes down.

## Conclusion

A spare computer, Alpine Linux, a USB cable, and a phone you already own is all it takes to give your home or small business network a solid backup WAN. The setup is straightforward, the failover is a single command, and the ongoing cost is nothing.

For the occasional outage — which is exactly the scenario most small businesses and home offices face — this is hard to beat.

<ContactFooter />


57ae585892c55092a1811e25a229f03d24e86b9b9f6fe0cd022c43794f3059dc

A step-by-step guide to setting up an Alpine Linux box as a backup WAN gateway for your home or small business network, using Android USB tethering as the mobile data source. Includes a failover script and full network configuration.

Turn an old PC or mini box running Alpine Linux into a backup WAN gateway using your existing Android phone's USB tethering — no extra SIM, no extra plan, no extra cost.

Create a Backup Mobile Data WAN for Your Small Business / Home Network

{/* banner prompt: Of course! Here are a few creative and engaging prompts for a banner image, designed to capture the essence of the blog post. I've provided three distinct options, each with a different creative angle.

### Option 1 (The Human-Centric "Battle")

This prompt focuses on the stressful, hands-on experience of the network administrator, creating a dramatic, cinematic scene.

**Prompt:**
> A cinematic, wide-angle shot of a network administrator in a dimly lit server room, bathed in the glow of a monitor and the ominous amber alert light of a dead router on a rack. On the screen, the Ubiquiti UniFi interface shows a configuration error, while tangled ethernet cables snake across the desk like digital vines. The administrator's face, a mix of intense focus and frustration, is partially visible. The scene should convey a sense of a high-stakes digital battle against time and technology. --ar 16:9 --style photorealistic, dramatic lighting

**Why it works:**
*   **Theme:** Captures the "3-Day Battle" and "Network Disaster" themes.
*   **Keywords:** Incorporates router, server room, Ubiquiti, and the "amber LED."
*   **Emotion:** Evokes the stress and urgency described in the post.
*   **Aspect Ratio:** The wide-angle shot is perfect for 16:9.

---

### Option 2 (The Abstract "VLAN Gotcha")

This prompt visualizes the technical problem itself in a more abstract, high-tech way, focusing on the story's climax.

**Prompt:**
> An abstract, high-tech visualization of a digital network. In the center, a fractured, dark monolith labeled "Meraki" represents the failed router. From one side, glowing blue data packets flow smoothly through a complex, sleek gateway labeled "Ubiquiti." However, these packets are stopped dead by an imposing, semi-transparent red wall labeled "VLAN: DROP UNTAGGED." The entire scene is set against a dark, grid-like background, symbolizing the network infrastructure. The image should be clean, modern, and conceptual. --ar 16:9 --style digital art, cyberpunk, minimalist

**Why it works:**
*   **Theme:** Directly visualizes the core technical conflict, especially the final "VLAN gotcha."
*   **Keywords:** Abstractly represents Meraki, Ubiquiti, and VLANs.
*   **Creativity:** Offers a unique, non-literal interpretation of the problem.
*   **Aspect Ratio:** The horizontal flow of data is ideal for a 16:9 banner.

---

### Option 3 (The Narrative "Cascade of Failure")

This prompt tells the story chronologically within a single image, showing the progression of the problem.

**Prompt:**
> A triptych-style digital illustration within a single 16:9 frame. The left panel shows a sleek Meraki router with a glowing red "CONNECTION FAILED" symbol above it. The center panel shows a complex diagram of PPPoE settings and network switches, with question marks and tangled red lines indicating confusion and struggle. The right panel shows the final solution: a network diagram where ethernet ports are highlighted, with a glowing green shield icon labeled "VLAN 1" finally allowing data to flow to computers and printers. The overall aesthetic is a blend of schematic diagrams and dynamic energy. --ar 16:9 --style infographic, graphic illustration, tech-noir

**Why it works:**
*   **Theme:** Follows the narrative arc of the blog post—failure, struggle, and resolution.
*   **Keywords:** Visually represents the key concepts: Meraki failure, PPPoE struggle, and the VLAN fix.
*   **Clarity:** Clearly communicates the main ideas of the post in a visually engaging way.
*   **Aspect Ratio:** The three-panel layout works perfectly in a 16:9 widescreen format. */}

Nothing strikes fear into a network administrator's heart quite like a dead router during peak business hours. What started as a routine internet outage on a Wednesday afternoon turned into a three-day odyssey through hardware failures, vendor limitations, and configuration nightmares that taught me invaluable lessons about network resilience and the hidden complexities of modern networking equipment.

## The Initial Disaster: When Redundancy Fails

Our office's Meraki router had been rock-solid for years. When the internet went down Wednesday morning, I initially wasn't concerned – these things happen, and our ISP usually resolves fiber issues quickly. But as minutes turned to hours, and our backup USB mobile data modem showed no signs of life in the Meraki dashboard, I knew this wasn't a typical outage.

### The Investigation Begins

Arriving on-site, the symptoms were clear but puzzling:
- Solid amber LED on the Meraki router
- No WAN link lights on the fiber optic connection
- No activity from the USB mobile data modem
- All ethernet ports and USB appeared powerless

The smoking gun came when I connected the WAN cable directly to a switch – instant link lights. The fiber wasn't the problem; the router was dead.

```bash
# Quick fiber connectivity test
# Connect WAN cable directly to switch/laptop
# If link lights appear immediately = router hardware failure
# If no link lights = ISP/fiber issue
```

To confirm my suspicions, I grabbed a consumer-grade home router from our emergency stash. One connection attempt later, we had internet – but with constant WiFi dropouts serving 30+ devices. Not exactly a sustainable business solution.

## The Search for an Emergency Replacement

Here's where the real challenge began. Meraki products come with lifetime warranty, but RMA (Return to Manufacturer Authorization) processes don't respect business emergencies. Even in the best-case scenario, we were looking at several days without proper networking infrastructure.

### Why Finding Business-Grade Alternatives Is Hard

The requirements seemed simple enough:
- Available immediately (no ordering delays)
- Cost-effective for temporary use
- Support 30+ concurrent devices
- Business-grade security and firewall features
- Compatible with our PPPoE internet connection

After researching our options, we settled on:
- **Ubiquiti Cloud Gateway Ultra (UCG-ULTRA)** for routing
- **Ubiquiti U7 Lite WiFi 7** for wireless access
- **24V DC 30W PoE Injector** for powering the access point

## The Ubiquiti Configuration Nightmare

### PPPoE Connection Struggles

What should have been a straightforward setup turned into hours of frustration. The initial PPPoE configuration simply refused to work – the router kept displaying "no internet found" regardless of what I tried.

```yaml
# Initial PPPoE Configuration Attempt
Connection Type: PPPoE
Username: [ISP_USERNAME]
Password: [ISP_PASSWORD]
VLAN ID: [if required by ISP]
MTU: 1500 (or ISP-specific value)
```

Suspecting a faulty unit, I implemented a workaround by converting Port 4 to a WAN port and using the Ubiquiti router as a client of our temporary home router. This bridged connection worked, proving the hardware was functional.

### The Mysterious PPPoE Success

Then something inexplicable happened – after extensive testing and configuration changes, the direct PPPoE connection suddenly started working. No clear explanation, no obvious trigger. Sometimes networking equipment just needs time to "settle in," though this isn't documented anywhere in the manual.

### WiFi Access Point Woes

The networking gods weren't finished with us yet. Our 24V PoE injector turned out to be completely dead – it couldn't power the WiFi access point or even our office VoIP phone. 

**Emergency solution**: We sourced a TP-LINK 8-port PoE Gigabit Switch, which successfully powered the U7 Lite (confirmed by the characteristic blue LED ring).

### UniFi Console Connection Issues

The WiFi access point refused to find the UniFi console during initial setup, consistently failing at exactly 2 minutes and 53 seconds with a "setup was disrupted" error message.

**Resolution**: A factory reset of the access point solved this issue entirely. Sometimes the simplest solutions are the most effective.

### UniFi Settings for the Business Workflow

Beyond the basic setup, we ran into some extra settings we needed for our specific business workflow. With our old Meraki router, we had this sweet IP-based access control for port-forwarding. It let us get to our in-premise NAS drive right from the cloud server.

Now, this Ubiquiti Cloud Gateway Ultra router? It *seems* like it's got that functionality, but honestly, we just couldn't get it to work (I assumed it was my fault entirely). Other than that, the UniFi dashboard itself can feel a bit overwhelming, too. There's info everywhere, but finding exactly what you need? That's another battle entirely.

It has some nice business features though. Take VPNs, for example:
*   You *can* set up WireGuard, OpenVPN, and L2TP servers. I hit a snag trying to create the OpenVPN server though; it kept spitting out an error with a cryptic "default" message.
*   Site-to-site VPN. But didn't test it.

I also had a few headaches setting up fixed IP addresses for certain devices. The error message kept saying the addresses were "already assigned," which was pretty frustrating. But hey, these weren't critical blockers for us, as we're just biding our time for new replacement devices from Cisco anyway. Just a couple more days to wait!

## Meraki RMA: When "Plug and Play" Isn't

Friday arrived with our RMA replacement Meraki router. The promise of Meraki's cloud management is simple: swap the hardware, and everything should work seamlessly. Reality had other plans.

### The PPPoE Déjà Vu

Despite using the correct credentials via the local configuration page (http://192.168.0.1), the new Meraki router refused to establish a PPPoE connection. The status LED remained stubbornly amber.

```bash
# Meraki Local Configuration Access
URL: http://192.168.0.1
Username: [Router Serial Number]
Password: [Leave blank for initial setup]
```

### USB Modem Drama

I still had that USB modem—definitely not the best 4G mobile data modem that Meraki supports, let's just say that. It's temperamental. Sometimes it's a contact issue where it won't even recognize the SIM card. Other times, the SIM registers, but it barely grabs a signal. 

So, here was the situation: 
1) The new router couldn't connect to the internet through the main WAN port.
2) It couldn't connect through the ethernet ports as a client of the Ubiquiti Cloud Gateway.
3) And it definitely wasn't connecting through that USB modem.

Talk about a triple failure, right?

Luckily, after fidgeting with the USB modem on a PC for a while, I finally got an internet connection out of it. My hands were actually shaky as I plugged it back into the router. I was literally praying it would keep working once it was connected. And then—the miracle happened. The router light went from that dreaded amber to a solid, beautiful white. Voilà!

### Multiple WAN Port Strategy

With our temperamental USB mobile data modem providing intermittent connectivity, I configured Port 4 as WAN 2. Using the Ubiquiti router as an intermediate gateway (WAN 2 → Ubiquiti → Internet), we achieved connectivity through DHCP. Another milestone.

The breakthrough came when I switched WAN 2 from DHCP to PPPoE and connected the WAN 2 port with the ISP cable while maintaining the connection through the USB modem. Suddenly, the direct ISP connection worked perfectly.

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/02/router-down-my-3-day-battle-with-meraki-ubiquiti--vlans/2026-02-10-17-22-01.png)

## The VLAN Gotcha That Almost Broke Everything

With internet connectivity restored, I assumed our troubles were over. Wrong. All ethernet-connected devices – computers, printers, phones – couldn't reach the network. WiFi devices worked perfectly.

### The Diagnostic Process

The printer's error message provided the crucial clue: "Cannot connect to DHCP server." This suggested a Layer 2 connectivity issue rather than a DHCP configuration problem.

### The VLAN Configuration Trap

Consulting various resources (including AI assistants), the consensus pointed to VLAN configuration issues. In the Meraki dashboard's "Per-port VLAN Settings" every ethernet port was configured to "Drop Untagged Traffic" instead of the expected "VLAN 1 (Default)."

Go to the VLAN setting page, and find the "Per-port VLAN Settings" section:

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/02/router-down-my-3-day-battle-with-meraki-ubiquiti--vlans/Screenshot_2026-02-10_17-37-04.png)

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/02/router-down-my-3-day-battle-with-meraki-ubiquiti--vlans/Screenshot_2026-02-10_17-36-22.png)

```yaml
# Problematic VLAN Configuration
Port 1-8: Drop Untagged Traffic ❌

# Correct VLAN Configuration  
Port 1-8: VLAN 1 (Default) ✅
```

After changing this setting across all ports, ethernet connectivity was immediately restored.

![VLAN Configuration Fix](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/02/router-down-my-3-day-battle-with-meraki-ubiquiti--vlans/2026-02-10-17-21-01.png)

## Lessons Learned: Building Resilient Networks

### 1. Hardware Redundancy Is Non-Negotiable

- Maintain spare networking equipment appropriate for your business size
- Don't rely solely on warranty replacement timelines
- Consider keeping emergency consumer-grade equipment for absolute emergencies

### 2. Understand Your Network's Critical Dependencies

- Document all configuration requirements (PPPoE credentials, VLAN settings, port forwarding rules)
- Test backup connectivity methods regularly
- Ensure mobile data modems are properly maintained and tested

### 3. VLAN Configuration Can Break Everything Silently

Modern networking equipment often ships with conservative security defaults that may not match typical business network expectations. Always verify:
- Default VLAN assignments
- Tagged vs. untagged traffic handling
- Port-specific VLAN policies

### 4. Vendor Lock-In Has Real Costs

While Meraki's cloud management is convenient, the inability to quickly source compatible replacement hardware during emergencies creates significant business risk.

## Configuration Reference for Future Emergencies

### Essential Network Documentation

```yaml
ISP Configuration:
  Connection Type: PPPoE
  Username: [DOCUMENT_THIS]
  Password: [DOCUMENT_THIS]  
  DNS Servers: [PRIMARY], [SECONDARY]
  
VLAN Settings:
  Default VLAN: 1
  Management VLAN: [if different]
  Port Assignments: [document per-port requirements]
  
Critical Port Forwarding:
  Service: [Port Range] → [Internal IP]
  NAS Access: [External Port] → [Internal IP:Port]
```

### Emergency Replacement Checklist

1. **Hardware Inventory**
   - [ ] Spare router compatible with current configuration
   - [ ] PoE switch or injectors
   - [ ] Ethernet cables of various lengths
   - [ ] Console cables for configuration

2. **Configuration Backup**
   - [ ] Current router configuration export
   - [ ] ISP connection parameters
   - [ ] DHCP reservations and ranges
   - [ ] Firewall and port forwarding rules

3. **Testing Procedures**
   - [ ] Verify internet connectivity
   - [ ] Test all VLANs and port assignments
   - [ ] Confirm wireless access point connectivity
   - [ ] Validate critical service access (VPN, port forwarding)

## Conclusion: Preparation Prevents Panic

This three-day networking nightmare reinforced the critical importance of preparation in network administration. While we ultimately resolved every issue and restored full functionality, the business impact of extended downtime could have been significantly reduced with better emergency planning.

The combination of hardware failure, vendor dependency, and subtle configuration issues created a perfect storm that tested every aspect of our network knowledge. The VLAN configuration issue, in particular, demonstrates how modern networking equipment's security-first approach can create unexpected gotchas for administrators familiar with older, more permissive defaults.

Moving forward, we've implemented a more robust emergency response plan, including spare hardware inventory and comprehensive configuration documentation. Because the next networking emergency isn't a matter of if – it's when.

*Have you experienced similar networking emergencies? What lessons did you learn from your network disasters? Share your war stories in the comments below.*

7eebb7d684418cff4f3e73314d49d2f5428041027d2c15cb0d578590825155df

When our office Meraki router died, we scrambled through Ubiquiti replacements, PPPoE struggles, and a sneaky VLAN configuration that taught us valuable lessons.

A real-world network disaster story: router failure, emergency replacement, and the VLAN gotcha that almost broke everything

Router Down! My 3-Day Battle with Meraki, Ubiquiti & VLANs


I run a custom trading gateway on a Windows 10 machine, primarily because it needs to interface with MetaTrader 5. I rely on MetaTrader to access market data and place orders for specific symbols and exchanges, like the ASX, that aren't available through my other tools. This setup is usually reliable, with the gateway using an SMB-based shared drive for data storage. However, that stability broke after I upgraded the machine to Windows 11, a necessary move with Windows 10 support ending. The first challenge I hit was the gateway losing access to its SMB share, which means I could no longer save the market data to the shared drive where my other pieces of trading software read the data from.

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/10/fix-cannot-connect-to-smb-share-on-windows-11/windows-no-access.jpg)

After some investigation, I found that Windows 11 had tightened its security around SMB guest authentication, which was causing the connection issues. The data server hosting the SMB share only supported guest access without authentication, and with the new security measures in place, Windows 11 was blocking the connection.

## Quick sanity checks

Before diving into configuration changes, I ran through a checklist to rule out common issues:

- Verified the NAS was still reachable by IP using `ping` and `Test-NetConnection`.
- Confirmed other machines on the LAN could mount the share, isolating the failure to the trading PC.
- Cleared cached credentials with `cmdkey /list` and `net use * /delete`.
- Rebooted after installing the latest cumulative Windows updates in case a patch hardened SMB defaults.


> ⚠️ **Security note:** Insecure guest logons remove authentication from SMB connections. Only use this on a machine you control, on a trusted network, and keep it firewalled from the public internet. Disable the setting again once you retire legacy storage.

## The fix: allow guest logons again

A simple way to allow guest logons again is to enable the "insecure guest logons" setting via Group Policy as follows.

1. **Enable Insecure Guest Logins via Group Policy:**

   - Press **Win + R**, type `gpedit.msc`, and press Enter to open the Group Policy Editor.
   - Navigate to **Computer Configuration** > **Administrative Templates** > **Network** > **Lanman Workstation**.
   - Double-click **Enable insecure guest logons** and set it to **Enabled**.
   - Apply the changes and restart your computer.

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/10/fix-cannot-connect-to-smb-share-on-windows-11/gpedit.png)

However, if you are using Windows 11 Home, you will need to use the Registry Editor method, as Group Policy Editor is not available.

2. **Enable Insecure Guest Logins via Registry Editor:**

   - Press **Win + R**, type `regedit`, and press Enter to open the Registry Editor.
   - Navigate to `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters`.
   - If the `AllowInsecureGuestAuth` entry does not exist, right-click and select **New** > **DWORD (32-bit) Value**, and name it `AllowInsecureGuestAuth`.
   - Set the value of `AllowInsecureGuestAuth` to `1`.
   - Close the Registry Editor and restart your computer.


After making the group policy change, you may still not be able to connect to the SMB share. The difference is that you probably don't have to wait for a few minutes for that error to come up. If you try to connect to the SMB share via `net use`, you may see an error like this:

```
C:\> net use Z: \\data-server\share
System error 3227320323 has occurred.
```

Try running the following command via PowerShell:

```powershell
Set-SmbClientConfiguration -RequireSecuritySignature $false
```

The above command is a PowerShell cmdlet that controls the SMB client "RequireSecuritySignature" setting. Running it sets whether the SMB client requires SMB packet signing for connections (our instance sets `RequireSecuritySignature` to `$false`). The `error 3227320323` indicates that the SMB client is requiring security signatures, but the server does not support it. So when set to true (the default), connections to servers that do not support signing will fail.

Restart your computer after running the command. After that, you should be able to connect to the SMB share again.

## Conclusion

After upgrading to Windows 11, I encountered SMB share connectivity issues due to Windows 11's stricter security policies around guest authentication. By enabling insecure guest logons through Group Policy (or the Registry Editor for Windows 11 Home) and disabling the security signature requirement with PowerShell, I was able to restore access to my legacy SMB share. This allowed my MetaTrader 5 gateway to resume saving market data to the shared drive.

Remember that these changes reduce security, so only apply them on trusted networks and on machines you control. Keep your firewall enabled and consider upgrading your storage solution to support modern authentication methods when possible.

2bcf2f01dea26dfa4c1a354137a47432623e072b57ca54cdc6a9cdb041fb777d

Troubleshooting checklist and final registry and group policy changes to let a MetaTrader 5 gateway reconnect to a legacy SMB share on Windows 11.

Steps I used to restore MetaTrader 5 access to an SMB share after Windows 11 hardened guest authentication.

Tag: Networking