Bridged AP does not work on BananaPiPro (Armbian_community_26.8.0-trunk.170_Bananapipro_trixie_current_6.18.35_minimal)

[loeriver]

Armbianmonitor:

https://paste.armbian.com/fawolicoki

I tried to build an bridged AP so that I can reach the Internet from a WiFi net spawned from the BananaPiPro. By this I followed the procedure from armbian-config (config.network.sh).

 

After install the AP is shown in the login screen:

 

WiFi AP:      SSID: (BPi), channel 7 (2442 MHz), width: 20 MHz, center1: 2442 MHz

 

When I try to connect from my mobile phone it either says "connecting without Internet".

The output in syslog is then:

 

026-07-06T12:35:02.645970+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e IEEE 802.11: associated
2026-07-06T12:35:02.690671+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e RADIUS: starting accounting session 500A81EDD1715454
2026-07-06T12:35:02.691497+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e WPA: pairwise key handshake completed (RSN)

 

Ort otherwise the phone just says "cannot connect".

 

My netplan file is as follows:

 

network:
  version: 2
  renderer: networkd
  ethernets:
    end0:
      dhcp4: false
      dhcp6: false
      macaddress: "02:cd:08:83:3c:f3"
    wlan0:
      dhcp4: false
      dhcp6: false
  bridges:
    br0:
      addresses:
      - "192.168.178.29/24"
      nameservers:
        addresses:
        - 9.9.9.9
        - 1.1.1.1
      interfaces:
      - wlan0
      - end0
      routes:
      - metric: 200
        to: default
        via: "192.168.178.1"

 

The hostapd.conf is:

 

interface=wlan0
driver=nl80211
ssid=BPi
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=secret
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

ctrl_interface=/var/run/hostapd
ctrl_interface_group=0

ieee80211n=1
ht_capab=[DSSS_CK-40][HT20+]

preamble=1

bridge=br0

 

The output of network list is:

 

root@bananapipro:/etc/hostapd# networkctl list
IDX LINK  TYPE     OPERATIONAL SETUP     
  1 lo    loopback carrier     unmanaged
  2 end0  ether    enslaved    configured
  3 br0   bridge   routable    configured
  4 wlan0 wlan     enslaved    failed   

 

Does anybody have an idea where to look further for a solution? As I have an AP running on my other BananaPiPro (Bookworm CLI / Networkmanager, manual config, not bridged) it cannot be a complete HW limitation, I think.

[eselarm]

I had a quick look at the script, but it is too complex for me to see what could be wrong. Also there is netplan layer in between that I am not familiar with anymore. Maybe you can look at what is generated in terms of systemd-networkd files (e.g. in /etc/systemd/network/ ). And also use commands like ip route etc to see the actual state.

 

Edited 22 hours ago by eselarm

[loeriver]

Well, netplan is the advertised / provided solution for Armbian. So when you look into /etc/systemd/network you find a readme from armbian pointing you to /etc/netplan. I think what netplan does is generating the following files for systemd-networkd under /run/systemd/network:

 

10-netplan-end0.network:

[Match]
Name=end0

[Link]
MACAddress=02:cd:08:83:3c:f3

[Network]
LinkLocalAddressing=no
Bridge=br0

 

10-netplan-wlan0.network

[Match]
Name=wlan0

[Network]
LinkLocalAddressing=no
Bridge=br0

 

10-netplan-br0.network 

[Match]
Name=br0

[Network]
LinkLocalAddressing=ipv6
Address=192.168.178.29/24
DNS=9.9.9.9
DNS=1.1.1.1
ConfigureWithoutCarrier=yes

[Route]
Destination=0.0.0.0/0
Gateway=192.168.178.1
Metric=200

 

10-netplan-br0.netdev 

[NetDev]
Name=br0
Kind=bridge

 

And this is the ip output:

 

ip route:

default via 192.168.178.1 dev br0 proto static metric 200 
192.168.178.0/24 dev br0 proto kernel scope link src 192.168.178.29 

ip link:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 02:cd:08:83:3c:f3 brd ff:ff:ff:ff:ff:ff
    altname enx02cd08833cf3
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether a2:67:ed:53:cb:f1 brd ff:ff:ff:ff:ff:ff
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000
    link/ether e0:76:d0:03:53:bc brd ff:ff:ff:ff:ff:ff
    altname wlxe076d00353bc

 

 

[eselarm]

I made a comparable setup on a raspberrypi3b+ and I see in the journal:

Jul 07 17:37:01 raspi7 systemd-networkd[292]: wlan0: Configuring with /etc/systemd/network/10-wlan0.network.
Jul 07 17:37:01 raspi7 systemd-networkd[292]: wlan0: Failed to set master interface: Device does not allow enslaving to a bridge. Operation not supported
Jul 07 17:37:01 raspi7 systemd-networkd[292]: wlan0: Failed

It worked many years ago when it was buster or bullseye and using ifupdown interfaces network setup. Also ported that to NetworkManager before Bookworm and that works, also in Trixie.

 

This is my first manual setup, as it is Debian Trixie based, I can avoid the use of netplan.io. I remember I have seen this issue somewhere, It might be a newer release systemd issue. But have not searched internet now, will see later why this is.

Edited 17 hours ago by eselarm

[eselarm]

Problem seems to be that the wlan0 somehow must have a carrier, else it cannot be added to the bridge. A quick hack in a running system, done via serial terminal is:

root@raspi7:/etc/systemd/network# systemctl stop systemd-networkd ; systemctl restart hostapd ; systemctl start systemd-networkd

Then:
root@raspi7:/etc/systemd/network# networkctl  
IDX LINK  TYPE     OPERATIONAL SETUP      
 1 lo    loopback carrier     unmanaged
 2 eth0  ether    enslaved    configured
 3 br0   bridge   routable    configured
 4 wlan0 wlan     enslaved    configured

I did some more testing and also with wlan0 stated as fail, I could browse the internet on my smarthone via the AP.

 

Note that in the meantime, I also simplified the 10-* files a bit, added a MACAddress same as eth0 for br0, so my routers issues same IP address when DHCP, but that is not fundamental to this issue I think, i more how I do it also via NM and how it was automatically in old Linuxes.

 

Google/Gemini suggests to add Before=systemd-networkd.service to hostapd.service, maybe I try, but I find that a dirty hack, it should be already in the OS, although Trixie is not the latest Linux.

[eselarm]

52 minutes ago, eselarm said:

Google/Gemini suggests to add Before=systemd-networkd.service to hostapd.service, maybe I try, but I find that a dirty hack, it should be already in the OS, although Trixie is not the latest Linux.

This is no success, it id wrong implementation, it is AI, from concept/principel it seems OK, but implementation is NOK

 

So I think I stop experimenting and will use NM if bridged WiPi AP is needed, I have several optional working in Debian Trixie and other distro. For wired lines, systemd-networkd with brideges and VLANs work OK.

 

As said already, Debian has netplan optional, so in Armbain Trixie I simply do apt purge --autoremove netplan.io (and install NM via apt install network-manager).

Then via nmtui it is easy to setup a bridged WiFi AP, no hostapd needed.

 

By the way, you have several errors w.r.t. your SD-card, might be a sunxi kernel issue, but also you brad SD-card or so.

[loeriver]

Many thanks for your investigations! SD card issues are solved, I obviously stopped the system during a write operation - after a shutdown (and card check with an PCs adapter) the errors are gone. But this had no impact.

 

What I did for comparison: I applied the same semi-manual netplan / networkd / hostapd setup sequence to an OrangePiZero, also trixie ( v26.8 rolling for Orange Pi Zero running Armbian Linux 6.18.37-current-sunxi). And guess what: this works without a hiccup!

 

So I looked into the syslog output when connecting. This is the output for the OPi (success!):

2026-07-07T20:47:35.333876+02:00 orangepizero hostapd: wlan0: STA ee:79:bc:4f:11:45 IEEE 802.11: authenticated
2026-07-07T20:47:35.336530+02:00 orangepizero hostapd: wlan0: STA ee:79:bc:4f:11:45 IEEE 802.11: associated (aid 1)
2026-07-07T20:47:35.406476+02:00 orangepizero hostapd: wlan0: STA ee:79:bc:4f:11:45 RADIUS: starting accounting session 01344FB459DCA3B1
2026-07-07T20:47:35.407484+02:00 orangepizero hostapd: wlan0: STA ee:79:bc:4f:11:45 WPA: pairwise key handshake completed (RSN)
2026-07-07T20:47:35.409156+02:00 orangepizero kernel: ieee80211 phy0: CCMP_PAIRWISE keylen=16!

 

And this is the output for the failing BPi:

2026-07-06T17:54:46.957014+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e IEEE 802.11: associated
2026-07-06T17:54:46.983182+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e RADIUS: starting accounting session 9B014BB4D748D33B
2026-07-06T17:54:46.984065+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e WPA: pairwise key handshake completed (RSN)
2026-07-06T17:55:28.848201+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e IEEE 802.11: disassociated


or: (worst case)

2026-07-07T16:52:15.236724+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e IEEE 802.11: associated
2026-07-07T16:52:15.270595+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e RADIUS: starting accounting session E501E4B1A6220EF1
2026-07-07T16:52:15.271648+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e WPA: pairwise key handshake completed (RSN)
2026-07-07T16:52:30.104160+02:00 bananapipro kernel: ieee80211 phy0: brcmf_psm_watchdog_notify: PSM's watchdog has fired!
2026-07-07T16:55:07.185663+02:00 bananapipro kernel: brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
2026-07-07T16:55:07.185794+02:00 bananapipro kernel: ieee80211 phy0: brcmf_cfg80211_get_channel: chanspec failed (-110)
2026-07-07T16:55:09.745805+02:00 bananapipro kernel: brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
2026-07-07T16:55:09.749180+02:00 bananapipro kernel: ieee80211 phy0: brcmf_cfg80211_get_tx_power: error (-110)
2026-07-07T16:57:18.001649+02:00 bananapipro kernel: brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
2026-07-07T16:57:20.561670+02:00 bananapipro kernel: ieee80211 phy0: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
2026-07-07T16:57:20.562221+02:00 bananapipro kernel: ieee80211 phy0: brcmf_cfg80211_get_station: GET STA INFO failed, -110
2026-07-07T16:58:23.281661+02:00 bananapipro kernel: ieee80211 phy0: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
2026-07-07T16:58:23.282246+02:00 bananapipro kernel: ieee80211 phy0: brcmf_cfg80211_get_channel: chanspec failed (-110)
.... (more errors)

 

The ip link/ ip route is identical, for the OPi also the networkctl output is clean:

 

root@orangepizero:/home/thomas/work# networkctl
IDX LINK  TYPE     OPERATIONAL SETUP     
  1 lo    loopback carrier     unmanaged
  2 end0  ether    enslaved    configured
  3 wlan0 wlan     enslaved    configured
  5 br0   bridge   routable    configured

4 links listed.

 

I also started to compare the log outputs for the start of hostapd, many things look equal / "similar" (maybe due to different underlaying hardware). I could provide the 2 (streamlined) logs, here only the most obvious deltas:

 

nl80211: flush -> DEL_STATION wlan0 (all) -->
	nl80211: Station flush failed: ret=-14 (Bad address)  (BPi)
	<none> (OPi)
  
<TX queue cmds OPi>
  nl80211: TX queue param set: queue=0 aifs=1 cw_min=3 cw_max=7 burst_time=15 --> res=0
  nl80211: TX queue param set: queue=1 aifs=1 cw_min=7 cw_max=15 burst_time=30 --> res=0
  nl80211: TX queue param set: queue=2 aifs=3 cw_min=15 cw_max=63 burst_time=0 --> res=0
  nl80211: TX queue param set: queue=3 aifs=7 cw_min=15 cw_max=1023 burst_time=0 --> res=0

<TX queue cmds BPi>  
  nl80211: TX queue param set: queue=0 aifs=1 cw_min=3 cw_max=7 burst_time=15 --> res=-95
  Failed to set TX queue parameters for queue 0.
  nl80211: TX queue param set: queue=1 aifs=1 cw_min=7 cw_max=15 burst_time=30 --> res=-95
  Failed to set TX queue parameters for queue 1.
  nl80211: TX queue param set: queue=2 aifs=3 cw_min=15 cw_max=63 burst_time=0 --> res=-95
  Failed to set TX queue parameters for queue 2.
  nl80211: TX queue param set: queue=3 aifs=7 cw_min=15 cw_max=1023 burst_time=0 --> res=-95
  Failed to set TX queue parameters for queue 3.

 

Question is, if I have to give up on the hardware or try a SW workaround (as my old solution running on BPiPro Bookworm / NM: wifi set to umanaged and using a hand-made hostapd / dnsmasq / iptables solution - will this work for Trixie? Do not know.) 

[eselarm]

I would not give up on the BPiPro just because this networking stack/tool issues. As I indicated, a bridged WiFi AP works fine with NetworkManager.  Armbian images are there to get you started very easily, even without Linux know-how. But it still is Linux, open-source, all DIY and no company you can manage to blame (try to find the engineer(s) who designed the SBC ... ). I know the majority of SBC users throws away working older installations and then get stuck with some new pre-installed image. You can instead just dist-upgrade in-place 

 

Netplan is from Canonical and there to uniform Ubuntu so NM and systemd-networkd can be used. Debian does not need netplan, there is no dependency on NM nor systemd-networkd.

 

Now look at this: A script from Armbian does netplan yaml that does .netdev/.network files or .nmconnection files. As long as it works, fine. But 3 layers, from math permutation you can know that means many more potential error cases. So you want to discard HW because networking config tooling has become too complex?

 

I forgot to power off the RPi3b+ before night and now in the morning the internet on the smartphone still works (via that AP). A simple reboot via serial console and short flip to 4G but then back to connected to the AP. BUT, the wlan0 again shows as 'failed'. So it seems a timing issue or so or just the status reporting is the issue. Also Android normally simply disconnects on PHY/MAC layer if no public routing ('internet'). That might happen easily after reboots or so or just without various timeouts. Note I have disabled systemd-networkd-wait-online.service else always 3 minutes waiting at reboot. You can also specify how and what to wait for, but needs reading docs. Also note that OS is not vanilla Debian aarch64, but from RPL, there is many changed packages, especially also in the network domain. And RPi3 has USB connected networking, not on the SoC like most other SBC's, this is also an issue I discovered.

 

I see for another RPi3:

@/raspi4/latest/etc/NetworkManager/system-connections
-rw------- 1 root root 259 Jan 21 16:16 br0.nmconnection
-rw------- 1 root root 217 Jan 21 16:16 eth0-br0_slave.nmconnection
-rw------- 1 root root 312 Jan 22 10:44 wlan0-br0_slave.nmconnection

Is still RPiOS arm64 bookworm, but with some hacks to prevent netplan and cloud-init disturbing things and wasting time, it also works with RPiOS Trixie. Certainly without tricks on standard Debian Trixie as I simply copy those 3 files to and from old AMD fanless computer etc that also has WiFi onboard. You need to make sure you stop and start NM at the proper moments and also make sure no UUID doubles or orphans. Should be fine when new, not yet booted image.

[eselarm]

# cat /etc/NetworkManager/system-connections/br0.nmconnection
[connection]
id=br0
uuid=75d54cd2-cdfe-4621-ab45-0bddf3ab4e6c
type=bridge
interface-name=br0
zone=trusted

[ethernet]
cloned-mac-address=my eth0 mac address

[ipv4]
method=auto

[ipv6]
addr-gen-mode=default
method=ignore

# cat /etc/NetworkManager/system-connections/eth0-br0_slave.nmconnection
[connection]
id=eth0-br0_slave
uuid=31645756-5c39-4184-a0c2-337ae09422ec
type=ethernet
interface-name=eth0
master=75d54cd2-cdfe-4621-ab45-0bddf3ab4e6c
slave-type=bridge

# cat /etc/NetworkManager/system-connections/wlan0-br0_slave.nmconnection
[connection]
id=wlan0-br0_slave
uuid=4ff7f9f2-056e-4836-9bc7-0e77d98a989c
type=wifi
interface-name=wlan0
master=75d54cd2-cdfe-4621-ab45-0bddf3ab4e6c
slave-type=bridge

[wifi]
band=bg
channel=1
mode=ap
ssid=mywifissid

[wifi-security]
key-mgmt=wpa-psk
proto=rsn;
psk=mypassword

template, stripped, optimized, cleaned, untested