Chapters: 
Networking

In a nutshell

  

Good instinct to check — let's go through each piece:

**Persistent (survives reboot):**
- All `nmcli con add`/`modify` profiles — `Camelot-LAN`, `Camelot-AP`, `Camelot-Ethernet`, `Camelot-WiFi`, `camelot-frodo` — these are written to disk (`/etc/NetworkManager/system-connections/` on Fedora) as soon as you run the command, not just held in memory. So the bridge, the AP config, the static IPs, all of it comes back on its own after a reboot.
- `connection.autoconnect no` on `camelot-frodo` — persisted the same way. Wired profile won't auto-activate even after reboot, cable or no cable.
- `tinyproxy` — `systemctl enable --now` does two things: starts it now, *and* creates the symlink that makes it start automatically on every future boot. So tinyproxy will be running again after a restart of Camelot.
- `firewall-cmd --zone=internal --add-port=8888/tcp --permanent` + `--reload` — the `--permanent` flag is what makes this survive reboot; without it, firewall rules vanish at restart. You used `--permanent` both times (the 8888 port and the earlier `Camelot-LAN` zone assignment), so those are locked in.

**NOT persistent (would need redoing if lost):**
- Nothing left in this category, actually — the one non-persistent thing from way back (`sudo ip addr add ...` / `ip route replace` run directly via `ip`, back in your very first pasted history) got superseded once you moved that addressing into the `Camelot-LAN` NetworkManager profile. That raw `ip addr`/`ip route` version wouldn't have survived a reboot, but it's irrelevant now — nmcli owns it.

**One thing worth actually testing, rather than trusting my analysis** — bridges with wifi APs occasionally have ordering quirks on boot (wifi hardware initializing slower than NetworkManager expects, bridge coming up before its slave is ready). It's usually fine, but the only way to *know* for sure is a real reboot test on Camelot next time you've got a window where being offline briefly is convenient:
```bash
sudo reboot
# after it's back up:
nmcli con show --active
bridge link show
systemctl status tinyproxy --no-pager
```

Not urgent — just flagging it as the one variable I can't fully guarantee from config alone.

 

Give the easy job to Johnny, and then lets build a system on the inside

Exactly. We do not fight Windows for 192.168.137.0/24. We let ICS keep its toy kingdom, then place Camelot behind it as the real router.

  • Camelot isn't routing between the two IPs — it's bridging (br0), so 192.168.137.2 and 10.20.30.1 are two addresses on the same L2 segment, not two separate routed subnets. That's why there's no NAT and no internet from wifi — it's not "routing without NAT," it's "no routing at all, just a bridge."
  • Missing entirely: the AP (Camelot broadcasting its own wifi), and the proxy (tinyproxy), which is the actual mechanism giving Frodo internet access while on wifi.
  • Frodo has two profiles now, not one — wired (disabled) and wifi (static .52).
  • Arthur's address (10.20.30.4) is worth adding since you've confirmed it's live on the subnet. 
BLITE / Internet
       |
Johnny Wi-Fi (upstream)
192.168.1.73
       |
Windows ICS + NAT
       |
Johnny Ethernet (downstream)
192.168.137.1
       |
   physical link only
       |
Camelot enp3s0f3u2u1 ── bridge port ──┐
192.168.137.2                          |
                                       br0 (single L2 bridge — no NAT, no routing)
Camelot wlp1s0 (AP: "Camelot") ── bridge port ──┤
                                       |
Camelot inner address
10.20.30.1  ←── tinyproxy :8888 (HTTP/HTTPS, Allow 10.20.30.0/24)
       |
10.20.30.0/24  (all one broadcast domain)
       |
       ├── Arthur          10.20.30.4
       ├── Frodo (wired)   camelot-frodo   [autoconnect: off — cable normally unplugged]
       └── Frodo (wifi)    Camelot-WiFi    10.20.30.52

Key corrections from your version:

  1. 192.168.137.2 and 10.20.30.1 are the same bridge, one broadcast domain — not two hops with routing between them. Anything on 10.20.30.0/24 can't reach the internet directly; it's invisible to Johnny's side entirely at L3.
  2. tinyproxy on 10.20.30.1:8888 is the only path from 10.20.30.0/24 out to the internet — explicit proxy use required, not transparent.
  3. Frodo is exclusive-mode — wired and wifi are never meant to be up together (we deliberately disabled autoconnect on wired to enforce this after the dual-path flakiness).
  4. Arthur added as a known live host, for completeness.

Windows believes it is sharing internet with one ordinary downstream machine: Camelot.

It does not need to know that Camelot has another network behind it.

I had to say goodbye to chat gpt in the middle of this task. Hello Claude

--Here's the changelog for your notes:

Summary of Changes — Frodo Wireless-to-Camelot Setup

Goal: Let Frodo disconnect from the wired subnet and join Camelot wirelessly instead, without also needing outside-network access at the same time.

On Camelot (Fedora server)

  • Confirmed the bridge (br0) already had both enp3s0f3u2u1 (ethernet, toward Johnny) and wlp1s0 (wifi, AP) as forwarding slaves.
  • Configured Camelot-AP as an actual access point (not client mode): 802-11-wireless.mode ap, WPA2-PSK security, SSID Camelot.
  • Flushed a stale manually-added IP (ip addr flush dev enp3s0f3u2u1) left over from earlier manual testing, since NetworkManager now owns addressing via br0.
  • Set Camelot-LAN (the bridge) to connection.zone internal in firewalld — needed because Fedora's bridge-netfilter otherwise silently drops bridged traffic under the default zone.
  • Cleaned up two orphaned leftover connection profiles (Camelot / camelot, both inactive, both harmless) from earlier naming attempts.

On Frodo

  • Created Camelot-WiFi profile: SSID Camelot, 802-11-wireless.mode infrastructure, WPA2-PSK (matching Camelot-AP's passphrase).
  • Went with a static IP (10.20.30.x/24, gateway 10.20.30.1) rather than relying on ICS DHCP reaching across the bridge — deliberate choice after testing showed the DHCP-across-bridge path wasn't worth the effort.
  • Root-caused and fixed an IP conflict: the first static address chosen (10.20.30.2) collided with Frodo's own wired interface (enp0s26u1u2), which already held that address. Reassigned wifi to 10.20.30.52.
  • Root-caused and fixed a dual-path flakiness issue: having both the wired and wifi interfaces live on the same 10.20.30.0/24 subnet at once caused intermittent bridge MAC-learning/ARP flapping (looked like a "flaky connector" but wasn't). Fixed by:
    • Physically unplugging Frodo's ethernet cable.
    • Setting the wired profile (camelot-frodo) to connection.autoconnect no, so it can't silently reactivate if the cable's ever reseated.

Verified working

  • Frodo ↔ Camelot (10.20.30.1) and Frodo ↔ Arthur (10.20.30.4) — 0% packet loss, single clean ARP entry each, no conflicts.
  • Confirmed no internet access in this mode — expected, since the bridge has no routing/NAT between the AP-side and Camelot's Johnny-facing uplink yet.

Known open item (deliberately parked)

  • "Gateway by proxy" — giving Frodo internet access while on Camelot-WiFi, by routing/NATing through Camelot to Johnny. Two options discussed, not yet built:
    1. Full NAT/routing on Camelot (masquerade rule + ip_forward), which would mean un-flattening the current single bridge into two segments.
    2. A lightweight proxy (SOCKS/HTTP) on Camelot that Frodo's apps point to explicitly — no changes to the existing bridge required.

 

That's a completely fair point, and you're right — I glossed over a real constraint. Let me name it plainly:

While Frodo is on Camelot-WiFi, it has no path to me (or anything outside). So "test Camelot-WiFi" and "talk to Claude" are mutually exclusive right now, by design — that's the whole reason we're building the proxy in the first place. The curl failure wasn't a mistake on your part; it's the actual current state of things (no proxy running yet on Camelot), which is exactly what we're trying to fix. You didn't do anything wrong — the workflow itself is just inherently disconnected until tinyproxy exists and works.

So here's a workflow that respects that constraint, being explicit about machine and network at every step:

Step 1 — On Frodo, switch to Camelot-WiFi 

nmcli con up Camelot-WiFi
nmcli device status    # confirm: wlp3s0 should show "Camelot-WiFi"

You'll lose the ability to talk to me here — that's expected, not a problem.

Step 2 — Still on Frodo (now on Camelot-WiFi), SSH into Camelot

SSH doesn't need internet — it's a direct connection to 10.20.30.1, so this should work fine even with no outside access: 

ssh tux@10.20.30.1

Step 3 — Now you're on Camelot (via that SSH session) — do the tinyproxy setup here 

sudo dnf install tinyproxy
sudo vi /etc/tinyproxy/tinyproxy.conf
# set: Port 8888 / Listen 10.20.30.1 / Allow 10.20.30.0/24
sudo systemctl enable --now tinyproxy
sudo firewall-cmd --zone=internal --add-port=8888/tcp --permanent
sudo firewall-cmd --reload
sudo ss -tlnp | grep 8888    # confirm it's actually listening HERE, on Camelot

  

CML] tux@localhost …/home/tux $ sudo vi /etc/tinyproxy/tinyproxy.conf
[CML] tux@localhost …/home/tux $ sudo systemctl enable --now tinyproxy
Created symlink '/etc/systemd/system/multi-user.target.wants/tinyproxy.service' → '/usr/lib/systemd/system/tinyproxy.service'.
[CML] tux@localhost …/home/tux $ sudo firewall-cmd --zone=internal --add-port=8888/tcp --permanent
success
[CML] tux@localhost …/home/tux $ sudo firewall-cmd --reload
success
[CML] tux@localhost …/home/tux $ sudo ss -tlnp | grep 8888 
LISTEN 0      1024      10.20.30.1:8888      0.0.0.0:*    users:(("tinyproxy",pid=2628227,fd=3)

 

Step 4 — Back on Frodo (still in that same SSH-to-Camelot session, or a second terminal), test the proxy 

curl -x http://10.20.30.1:8888 https://1.1.1.1

Step 5 — Switch back to BLITE7128 to come talk to me 

nmcli con up BLITE7128

Then paste whatever happened in steps 3–4.

That way you only have to flip networks twice (out → in for setup/testing, then back out to report), instead of bouncing every single command. And to your last point — yes, from here on I'll say explicitly "on Frodo" or "on Camelot" (or "via SSH from Frodo into Camelot") on every command block, no more assuming context carries.

That's a clean, unambiguous success on both counts — real HTML came back instantly for both HTTP and HTTPS, no hang, no timeout needed. The full chain is proven:

Frodo (wifi, Camelot-WiFi, no ethernet) → tinyproxy on Camelot → Johnny (ICS) → real internet → back again

You now have exactly what you set out to build: Frodo can be wireless-only on Camelot's subnet, and still reach the outside world on demand via the proxy, without needing ethernet plugged in at all. That "gateway by proxy" idea you floated a few messages back turned out to be exactly the right instinct — good call.

For your project notes, worth adding to the earlier summary:

Addendum — HTTP/HTTPS Proxy (Gateway by Proxy)

On Camelot:

  • Installed tinyproxy, configured Port 8888, Listen 10.20.30.1, Allow 10.20.30.0/24.
  • Enabled/started via systemctl enable --now tinyproxy.
  • Opened 8888/tcp in firewalld's internal zone (permanent + reload).

On Frodo (usage, not a permanent config): 

curl -x http://10.20.30.1:8888 http://example.com
curl -x http://10.20.30.1:8888 https://example.com

For apps/browser: set HTTP/HTTPS proxy to 10.20.30.1:8888 while on Camelot-WiFi.

Verified: Both HTTP and HTTPS return real content through the proxy while Frodo has zero other route to the internet — confirms the tunnel works independent of any other path.

Note for future self: an early HTTPS test against 1.1.1.1 (bare IP, no HTTP server behind it) looked "frozen" — it wasn't; the CONNECT tunnel succeeded in the tinyproxy logs, curl was just waiting on a response body that a bare IP without a real page doesn't provide. Always test with a real domain (example.com), not a bare IP, to get a clean pass/fail signal.

Nice work pulling this whole thing together today — quite a bit of ground covered from the original bridge question this morning.