Bridged AP Mode

[Taikuh]

See #522 for the original issue.
For more info on setting up a bridged access point, see here.

My implementation is based on the above link. The above link is confirmed to be working for the latest Raspbian Lite Buster on RPi 3 and 4. My implementation is confirmed to be working on my own Raspbian Lite Buster Rpi 4.

Currently, my implementation consists of a few changes to the original setup in common.sh, dhcpcd.conf, hostapd.conf as well as the addition of a couple networkd files. Everything is tied up with installers/toggle-bridged-routed.sh.

toggle-bridged-routed.sh will automatically detect if the virtual bridge device is initialized and has been assigned an IP address. If so, it will toggle back to the default routed AP mode. If not, it will toggle to the bridged mode. There are also two "subcommands" / options:
toggle-bridged-routed.sh force-bridged and toggle-bridged-routed.sh force-routed that force their respective configuration.

I have not been able to see if the simultaneous client-AP mode works with the bridged configuration, namely because I can't get that mode to work in the first place.

I also haven't tested the bridge mode with OpenVPN. Please refer to the #522 to see what else I need help on.

[billz]

Merged with master and #527. OpenVPN and the managed mode AP will need a look. On the UI side, I can imagine a switch on the hostapd advanced tab to enable the bridged-routed AP. I like that this approach makes it toggleable from the front-end, rather than setting an either/or option at install time.

I'll pull this shortly and put it into testing. Thanks for the PR

[Taikuh]

Hi billz, can I confirm with you what you mean by managed mode AP (simultaneous client + AP)? Is it that the Pi's onboard wireless card both acts as the client to another AP while itself serving as an AP without needing any other network devices like a USB-WiFi dongle?

[billz]

Is it that the Pi's onboard wireless card both acts as the client to another AP while itself serving as an AP without needing any other network devices like a USB-WiFi dongle?

@Taikuh yes, exactly right. It was developed initially to extend AP support to the Pi Zero W

[Taikuh]

I've had trouble getting the simultaneous mode to work even on the master branch circa one week ago. I've consulted the FAQ and other people's Issues. I must be missing something somewhere and will look into it more in the coming days. If I'm still stuck, I'll open a proper issue for it.

Meanwhile, I've pushed a change. A Bridged AP mode toggle appears below the Client AP mode toggle. Unlike the Client AP toggle, the Bridged AP toggle is never disabled. It works like the other toggles on the page: toggle > Save Settings > Restart hotspot. Some issues:

1. the Pi's IP changes when in Bridged mode. The br0 device is automatically assigned an IP by the DHCP server in your upstream router, as bridged APs should be. I haven't tested yet if assigning a static IP to the br0's MAC addr works from the webgui.
2. Because the Pi's IP changes in Bridged mode, the address used to access the webgui is different. To find it, enter ifconfig br0 in prompt and look for the address after inet.
3. I don't know how other options will affect the Bridged Mode setup.

Possible solution for 1 and 2:
Automate finding br0's or wlan0's IP and use dnsmasq(?) or dhcpcd(?) to redirect http://rasp.ap to br0's or wlan0's IP, depending on the mode.

In addition, I'm operating under the assumption that Bridged mode and Client AP mode are incompatible. If anybody can confirm this, it would help with future headaches trying to get them to work together.

[billz]

@Taikuh excellent work. Integrates nicely into the project and works more or less flawlessly.

I tested this using the --repo Taikuh/raspap-webgui --branch bridge-mode options with the installer on a fresh Buster Lite. The br0 interface is enabled as expected with the UI toggle and joining the AP presents no issues.

$ ip addr show br0
br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether [snip]

Connected clients are given leases by the router and do not appear in the Pi's DHCP logs or dnsmasq leases.

Re: automating discovery of br0 or wlan0's IP and redirecting depending on the mode, Avahi responds to mDNS requests on the local network, so accessing the Pi via hostname.local should work. Although in practice it can take time for mDNS to resolve the new IP. An http redirect might be possible but could be tricky with timing. Failing this, we can provide a FAQ for discovering the Pi's new IP on the local network. Let's think on this.

I haven't tested yet if assigning a static IP to the br0's MAC addr works from the webgui

I assigned a static IP for br0 in the UI and after rebooting this appears to have made my Pi inaccessible, so I'd suggest avoiding this for now 😅Probably this conflicts with the router's DHCP (my test router doesn't permit static leases), so one option would be to disable management of this interface in the UI or provide a warning.

I've had trouble getting the simultaneous mode to work even on the master branch circa one week ago

I'll run through another test cycle with the managed mode AP. Feel free to create an issue in the meantime. In any case, I think it's safe to assume that a managed mode + bridged AP won't be supported, at least initially.

[Taikuh]

Thanks for testing and for the feedback, @billz

Accessing the RaspAP web portal by hostname

accessing the Pi via hostname.local should work

I can confirm that using hostname.local is the simplest solution for now. I'm trying to learn as I go, but for now terms like Avahi and mDNS are going above my head. In the meantime regarding hostname.local, it seems like different browsers behave differently:

Safari, macOS & iOS: hostname.local resolves to RaspAP's web portal and asks for authentication (admin:secret). For my intents and purposes, works as intended.
Chrome, macOS & iOS: hostname.local redirects to a Google search. Entering http://hostname.local or pi.local/ will correctly resolve to RaspAP's web portal and ask for authentication. Once RaspAP's web portal is stored in Chrome's history, a simple pi.local in the address bar works as intended.
Firefox Focus, iOS: hostname.local seems to resolve to RaspAP's web portal. But the browser doesn't ask for authentication and instead just displays Not authorized on the page. This also happens when entering the Pi's IP address, so I'd conclude it's to do with Firefox Focus.

Assigning a static IP to br0

I assigned a static IP for br0 in the UI and after rebooting this appears to have made my Pi inaccessible

DHCP Server > Static Leases seems to have had no effect.

Networking > br0 > Static IP seems to be on the right track. After setting the Static IP to xxx.xxx.xxx.xxx, Save Settings, then Apply Settings, the end result is that /etc/dhcpcd.conf is reset to the default config (the system's default, not RaspAP's) with interface br0 and static ip_address=xxx.xxx.xxx.xxx. However, this breaks the bridge configuration by removing the denyinterfaces eth0 wlan0 line. Save Settings and Apply Settings on this page seems to do some AJAX stuff which I'm not familiar with.

My router allows static IP assignment and I can confirm I can give the br0 a static IP with the following steps:

1. Fresh install
2. Enable Bridged AP mode
3. add static ip_address=xxx.xxx.xxx.xxx/24 under interface br0 in /etc/dhcpcd.conf
4. sudo ip address flush dev br0
5. sudo systemctl restart dhcpcd

All without having to enter my router's own portal. With the caveat that the router's DCHP server isn't already trying to assign xxx.xxx.xxx.xxx to another device in the network. I do think this option should be disabled for now, as it's probably better to assign the static IP from the upstream router's interface.

Simultaneous Client and Bridged AP mode

It seems like bridging a wifi client interface is not possible.

First full paragraph, here:

The Raspberry Pi is able to work as a wireless hotspot and simultaneously connect to another hotspot as a client. But the wifi device on the RasPi has a general limitation. The client connection cannot be bridged because lack of WDS (wireless distribution system) that is needed for bridging on the wireless.

Also, in the RPi forums here:

the WiFi alliance decided bridging a client interface was forbidden

An Aside

Might I suggest standardizing the web portal's button's actions. For example, the Networking > br0 settings uses AJAX and seems to reset /etc/dhcpcd.conf to either the backup file made by the installer or just a system default, then modifies this file.

Meanwhile, Hotspot > Restart Hotspot re-creates the conf files from scratch through the config array created in php. PHP populates this array with some default values and 'changes' other values with if/else statements and input from POST.

This Aside is out of this PR scope; I'm just throwing it out here for now and seeing what you think.

Next Steps

Disable incompatible settings in Bridged AP mode.

Perhaps change the 'Enable Bridged AP mode' toggle to a set of two radio buttons:

• Routed AP mode
• Bridged AP mode

to emphasize that RaspAP is running under one mode or the other.

[Taikuh]

Changes in the latest push

The following pages and settings are disabled when in Bridged AP mode:

• Client AP, the whole page
• DHCP, the whole page
• Networking, the individual network device tabs are disabled; the Summary tab is untouched
• Hotspot > Advanced > Wifi Client AP mode toggle is disabled during Bridged AP mode

In addition, I moved some logic around so that Bridged mode settings take precedence over Client mode. This makes sense to me because it's either/or for Bridged AP vs Routed AP modes (routed being the RaspAP default). Whereas Client mode is more an optional extension of Routed AP mode and is incompatible with Bridged mode.

However, I also moved some code around so that the previous "Client mode enabled" status is saved yet ineffective when Bridged mode is enabled. So, disabling Bridged mode should also revert the Client mode to its previous state.

Note that I haven't tested any change regarding the Client mode toggle and save-state.

[billz]

Thanks for commenting on each block of commits (and rebasing with master). I'll do my best to follow up on some key points you raise...

My router allows static IP assignment and I can confirm I can give the br0 a static IP with the following steps [...]. I do think this option should be disabled for now, as it's probably better to assign the static IP from the upstream router's interface.

Good to know and agreed. For now, this could be documented with a FAQ or wiki page for users who want a static IP for the bridge interface.

It seems like bridging a wifi client interface is not possible

There is no practical way, that I know of, to bridge a wifi client. Most of the documented wifi client "bridges" one finds online are actually routed configurations. Also worth mentioning that @epoch1970 certainly knows his stuff :)

I moved some logic around so that Bridged mode settings take precedence over Client mode

Noted and makes sense.

Might I suggest standardizing the web portal's button's actions. This aside is out of this PR scope; I'm just throwing it out here for now and seeing what you think.

Absolutely. I've started feature branches several times in the past to address this, but haven't arrived yet at the holy grail of logical config handling. This is partly the result of historical inertia with the project and different authors' approaches and also a function of my limited time to overhaul the code. A possible(?) step forward was defining wireless regulatory info in /config/wireless.json. @glaszig followed up with dns-servers.json. Not advocating moving all project configs to .json, but clearly a better solution is needed.

Note that I haven't tested any change regarding the Client mode toggle and save-state.

I'll do a fresh test pass with this feature branch today. It's really shaping up nicely.

[Taikuh]

Your feedback is greatly appreciated. And yes epoch1970 is a networking wizard!

For now, this could be documented with a FAQ or wiki page for users who want a static IP for the bridge interface.

I'm thinking an introductory section in the README similar to Simultaneous AP and Wifi Client, along with a wiki page for more details such as setting the static IP.

This is partly the result of historical inertia with the project and different authors' approaches and also a function of my limited time to overhaul the code.

Most understandable. Luckily, I have plenty of free time but unfortunately haven't any formal training in any of these matters. Once the initial documentation of Bridged AP mode is finished and we iron out any remaining kinks with Client mode, I'll have more energy to devote to this.

Changes in latest commit (OpenVPN)

I couldn't get OpenVPN to work with Bridged AP mode. I really hope it's possible though; my objective with this project was to have my Apple TV connect to my Pi's AP and through a VPN in order to spoof my location. This setup works perfectly well using RaspAP's default Routed AP mode. But I was looking into Bridged AP mode because I also want my Apple TV to be visible to other devices in my LAN that aren't connected to the Pi's AP.

• disabled the entire OpenVPN page while Bridged AP mode is enabled
• stop and disable the OpenVPN service automatically before enabling Bridged AP mode
• made OpenVPN > Stop/Start OpenVPN stick across Pi reboots using systemctl enable/disable

Next up

Documentation and resolving any Client mode incompatibility problems. After that, I feel it's safe to say that Bridged AP mode is ready, albeit in a much more limited fashion than the default Routed AP mode.

[billz]

I was about to suggest disabling OpenVPN but you beat me to it ;)

Ran through the following test with a fresh install on a Pi Model 4:

• With the default config, enabled bridged AP > started hostapd
• Confirmed AP active with new IP from upstream router
• Bringing up the UI on hostname.local presented no issues (MacOS Chrome)
• Connected several clients > rebooted the Pi > reconnected to bridged AP
• Stop hostapd > toggled bridge to 'off' (routed) > default nav items re-enabled
• Configured a wireless client > enabled wifi client AP mode > start hostapd
• Client mode toggle and save state work as expected
• Confirmed interface uap0 is up on 192.168.50.1/24 > connected several clients
• Rebooted the Pi > reconnected to uap0 AP as before > no issues
• Uploaded an .ovpn file > started OpenVPN with uap0 active > connected clients
• Confirmed public IP matched OpenVPN config on clients (iPhone + Android)

I haven't looked at the logs, but the user-facing functionality appears solid.

[Taikuh]

Whew what a ride! After all that, what happens if you go straight to Hotspot > Advanced, then directly toggle/enable Bridged AP mode > Save Settings > Restart Hotspot?

I expect OpenVPN to gracefully stop (may take a few seconds) and br0 to be up. But I'm not sure what will happen to uap0.

---

I got simultaneous routed AP and client mode to work and did a similar test to above.

• Configured a wireless client > enabled wifi client AP mode > start hostapd
• Confirmed interface uap0 is up on 192.168.50.1/24 > connected one client
• Hotspot > Advanced > Enable Bridged AP mode > Save > Restart Hotspot
• Client connect to raspap-webgui hotspot, using wlan0 as interface
• br0 IP and hostname.local both resolve to raspap portal, good.
• uap0 is still up and has new IP at 169.254.xxx.xxx which also resolves to raspap portal.
• Disable Bridged AP mode > save > restart hotspot
• uap0 still on 169.254.X.X subnet without an easy way to get things working as intended through the webgui portal

I will add in some lines to correctly disable uap0 when toggling Bridged AP mode.

[billz]

I couldn't get OpenVPN to work with Bridged AP mode. I really hope it's possible though

It should be possible. With a bridged AP I had no problems enabling OpenVPN via the UI and connecting a client. Using curl ifconfig.me from the Pi's shell resolved my VPN provider's public IP, however this did not apply to clients on br0. This describes a different network topology but is instructive nonetheless. At any rate, I think we can release bridged AP mode with OpenVPN disabled for now and circle back to it later.

Documentation and resolving any Client mode incompatibility problems. After that, I feel it's safe to say that Bridged AP mode is ready.

Yep, agreed. I also think this deserves an introductory section in the README with a link to a wiki page.

what happens if you go straight to Hotspot > Advanced, then directly toggle/enable Bridged AP mode > Save Settings > Restart Hotspot?

I left that one out ;) Thanks for testing this case. Sounds good re: disabling uap0 when in bridged mode. Should be the final piece.

[Taikuh]

With a bridged AP I had no problems enabling OpenVPN via the UI and connecting a client. Using curl ifconfig.me from the Pi's shell resolved my VPN provider's public IP, however this did not apply to clients on br0.

I can confirm this as well. I wrongly assumed br0's clients would use the VPN's public IP, so I initially wrote it off as non-functional.

I have concluded what I can comfortably say is the initial release of Bridged AP mode for RaspAP. Switching between the different possible configurations doesn't seem to break anything:

• default routed <--> bridged modes
• simultaneous AP+client <--> bridged mode
• all of the above with OpenVPN active
• toggling OpenVPN while bridged mode is active

I've added the initial draft for the README's Bridged AP section. And the following comment can be used as a draft for a wiki page:

[Taikuh]

Bridged AP mode

By default RaspAP configures a routed AP as its hotspot, where your RPi creates a subnet and assigns IP addresses to its hotspot clients. If you would rather have your upstream router assign IP addresses, RaspAP lets you easily change the hotspot configuration to an alternative bridged AP. This is also useful if you want your RPi and its hotspot clients to be visible to other devices in your router's network.

Toggling bridged AP mode

In the RaspAP web interface, go to Hotspot > Advanced tab, then slide the Bridged AP mode toggle. Save settings then Restart hotspot.

Bridged AP mode limitations

Bridged AP mode has some limitations compared to RaspAP's default routed AP.

Hotspot > Advanced tab > Wifi Client AP mode is disabled. Your RPi cannot connect as a client to another Wifi network while simultaneously hosting its own bridged AP (hotspot).

DHCP Server page is disabled. In bridged AP mode, your upstream router is the DHCP server. Use your router's web interface to configure DHCP settings.

Clients connected to a bridged AP with OpenVPN enabled will not have their traffic routed through the VPN server. Your RPi itself will still have its own traffic routed through the VPN server.

Accessing the RaspAP web interface

In bridged AP mode, you will no longer be able to access RaspAP's web interface using the default 10.3.141.1 address. This is because your RPi no longer creates its own 10.3.141.0/24 subnet for its hotspot. Instead, access RaspAP's web interface by entering your RPi's hostname followed by .local. By default this will look like raspberrypi.local.

Some browsers have trouble resolving .local addresses. You might have to modify the address depending on your browser: http://raspberrypi.local or raspberrypi.local/.

If none of the above work, use your RPi's local IP address. Find it by checking your router's web interface or by entering the following command from your RPi terminal.

ifconfig br0 | grep 'inet ' | awk '{print $2}'

[billz]

I have concluded what I can comfortably say is the initial release of Bridged AP mode for RaspAP

Agreed. I repeated these tests with your most recent commits. Bridged mode worked as expected with the existing services/functionality. Services also returned to their various configurations following a reboot of the Pi. No issues connecting a variety of clients (iOS, Android, MacOS, etc).

I've added the initial draft for the README's Bridged AP section. And the following comment can be used as a draft for a wiki page

Outstanding, thank you. I've added the wiki page with your text, which incidentally has the same voice as the other project docs :) Will link it post-merge from the readme and also update the manual installation steps.

This is a significant update that the RaspAP community has wanted for a long time. I also appreciate the thoroughness of your integration and testing. Sincere gratitude!

[tarikaltuncu]

I'm not master at this but I was annoyed change of IPs everytime I run raspap (I need to use it in Bridge mode)

So, I set the following run on boot which replaces br0 MAC address with the MAC address I provide (I put the eth0's MAC address instead of 00:00:00:00:00:00)

ifconfig br0 down hw ether 00:00:00:00:00:00 && ifconfig br0 up

Now it gets the same IP.

Also, interestingly, my raspberry itself couldn't connect to internet before I made this change although its wifi clients could connect well.