Bridge-mode (AP + Ethernet bridge) issues on Raspberry Pi OS Trixie

[Petran54]

Setting up RaspAP's wireless bridge mode (hw_mode=g, bridge=br0 combining eth0 + wlan0) surfaced several problems:

1. Leftover dhcpcd.conf static IP for wlan0 persists even after switching to bridge mode. RaspAP's own /etc/dhcpcd.conf sets a static 10.3.141.1/24 on wlan0. When wlan0 is enslaved into br0, that address should be removed automatically, it wasn't, and stayed there until manually flushed with ip addr del.

2. dhcpcd.service reported disabled via systemctl is-enabled, but was active at boot regardless, reapplying the stale static IP even though it was supposedly turned off. Had to systemctl mask dhcpcd to actually stop it from coming back.

3. The web GUI silently overwrites manual hostapd.conf edits. Adding bridge=br0 by hand and then touching any Hotspot setting in the GUI regenerates hostapd.conf from RaspAP's internal DB and drops the bridge=br0 line without warning.

4. Switching the hotspot to 5GHz/AC while bridge=br0 is set breaks hostapd completely, no error shown in the GUI, no SSID broadcast, service just fails silently. No validation preventing this known-bad combination.

5. wlan0's DHCP server (dnsmasq dhcp-range in /etc/dnsmasq.d/090_wlan0.conf) stays active even in bridge mode, so unless manually disabled, the Pi runs its own rogue DHCP server on the same segment as the upstream network's DHCP, a real risk of double-DHCP conflicts for clients.

6. No rollback or fallback if a hostapd config change fails. The broken 5GHz+bridge combination left the device with no wifi and no SSH, requiring a full reinstall to recover.

• On your SSH vs GUI question: yes, SSH-based troubleshooting is noticeably more fragile here, but not because SSH itself is flaky. It's because:

The GUI and manual file edits fight over the same config files (see point 3 above), so anything done via SSH can get silently undone the next time the GUI is touched.

Bridging depends on a hostapd option (bridge=) the GUI doesn't expose, forcing SSH or manual edits in the first place.

If a change, like a hostapd restart, breaks the network, you lose your only path back in via SSH, there's no local console fallback the way a directly connected GUI user would have. That's what caused the no wifi, no SSH situation requiring a physical reinstall.

So the underlying bugs are identical either way, SSH just removes any safety net when they trigger.

I'm a first-time RaspAP user setting this up for a bridge/hotspot project on Raspberry Pi OS Trixie, not a developer on the project, just ran into these while trying to get bridge mode working. Happy to share logs and configs if useful.

Peter
Sweden

[billz]

My LLM estimates 85-92% probability that the main content of this post is entirely agent-generated.
The probability that I will invest effort in thinking and replying to this is inversely proportional to these figures.

tl;dr: compose a human post, get a human reply.

[Petran54]

Hi billz, and thanks for the reply. You and your agent are right, I let Claude summarize it. Here's what happened: I made several attempts as admin in the GUI but couldn't get it working. So I got Claude to help, letting it SSH into the rpi and try to sort it out. It did, but we ran into problems here too, as mentioned. Ended up with a restart and reinstall etc.

The idea was that Claude would just translate for me, but I took the easy way out and had it summarize my post instead. Maybe not the most thought-through move, but it could still be informative for someone who understands all this better than I do. I'm just a simple human with too little knowledge once you're down in the prompt digging around, hahah.

Best,
Peter

[Petran54]

Petran54 doesn't stand for my age, it's because I was born in 1954. So I need all the assistive tools I can get.