{/* 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**, so 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 and 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 and 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**, so 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, so 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, because 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


355ea4deb3cfd87cda66307bdf758a2f1c27d20b73a087ded7145c8a5517131b

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, with 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, or 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, with 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, with 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**, because `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, because 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`, which 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 and 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 by adding 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.*

e8479c4c8a0735d56539ded3d444abb51329c469dedde23e34a1f7099446d78a

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, with no expensive hardware required.

Tag: Nat

Tag: Nat

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

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