loeriver

As a little postscript to the topic "bridged AP": meanwhile I managed to get it to work, procedure is a bit non-standard, though (but much shorter / easier than the routed / NAT setup): -fresh install using NM (self-compiled Trixie "stable", v26.08 / 6.18.41-current-sunxi) -set wlan0 to "unmanaged" for NM -stop / disable / mask wpa_supplicant (I do not intend to use the system as WiFi station, besides wpa_supplicant looked like a big troublemaker in my earlier "bridged AP" attempts) -with nmcli: set up bridge br0, add end0 to the bridge, remove the wired connection from the setup and configure bridge as manual connection -install / enable hostapd, have option "bridge=br0" in its conf -(re)start hostapd and NM Restart messages for hostapd: 2026-08-03T22:05:19.028468+02:00 bananapipro systemd[1]: Starting hostapd.service - Access point and authentication server for Wi-Fi and Ethernet... 2026-08-03T22:05:19.135126+02:00 bananapipro kernel: br0: port 1(wlan0) entered blocking state 2026-08-03T22:05:19.135245+02:00 bananapipro kernel: br0: port 1(wlan0) entered disabled state 2026-08-03T22:05:19.135294+02:00 bananapipro kernel: brcmfmac mmc1:0001:1 wlan0: entered allmulticast mode 2026-08-03T22:05:19.135308+02:00 bananapipro kernel: brcmfmac mmc1:0001:1 wlan0: entered promiscuous mode 2026-08-03T22:05:19.256967+02:00 bananapipro kernel: br0: port 1(wlan0) entered blocking state 2026-08-03T22:05:19.257265+02:00 bananapipro kernel: br0: port 1(wlan0) entered listening state 2026-08-03T22:05:19.272609+02:00 bananapipro hostapd[2155]: wlan0: interface state UNINITIALIZED->ENABLED 2026-08-03T22:05:19.273397+02:00 bananapipro hostapd[2155]: wlan0: AP-ENABLED 2026-08-03T22:05:19.280786+02:00 bananapipro systemd[1]: Started hostapd.service - Access point and authentication server for Wi-Fi and Ethernet. 2026-08-03T22:05:34.318649+02:00 bananapipro kernel: br0: port 1(wlan0) entered learning state 2026-08-03T22:05:49.418545+02:00 bananapipro kernel: br0: port 1(wlan0) entered forwarding state 2026-08-03T22:05:49.418654+02:00 bananapipro kernel: br0: topology change detected, propagating Connect / disconnect from WiFi client: 2026-08-03T21:47:36.228133+02:00 bananapipro hostapd: wlan0: STA ac:81:12:3d:84:20 IEEE 802.11: associated 2026-08-03T21:47:36.251629+02:00 bananapipro hostapd: wlan0: STA ac:81:12:3d:84:20 RADIUS: starting accounting session 15580AA6A8314F9F 2026-08-03T21:47:36.252781+02:00 bananapipro hostapd: wlan0: STA ac:81:12:3d:84:20 WPA: pairwise key handshake completed (RSN) 2026-08-03T21:49:41.211810+02:00 bananapipro hostapd: wlan0: STA ac:81:12:3d:84:20 IEEE 802.11: disassociated

Thank you for the hint. -/etc/exports on the nfs server is: /volume1/documents *(rw,async,no_wdelay,no_root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100) -the server's /etc/idmapd.conf has: [Mapping] Nobody-User = nfsnobody Nobody-Group = nfsnobody The uid/gid on nfs server and client do not match (server: 1026 / 100, client: 1000 / 1000). I think I have to educate myself about the nfs setup (or work on the non-nfs disk) as this becomes not quite OT in this forum.

I moved the whole build directory from my nfs drive to an internal drive, changed all file ownerships as root to me:mygroup and voila: the build process ran through. I do not know what caused the above problems: but it seems to be somehow related to having the tree on an nfs drive.

Yes I have and I call compile.sh (and from it docker) as plain user. But inside docker I am root. There are options to run Docker rootless or to change uid/gid. But as I did not read anything about this in the Armbian docs I have not tried such changes yet.

To follow up myself: somehow the Docker build does not work: If I clone the repo as root, I cannot call "./compile.sh docker-shell", as the script cannot create directories in "build" then. I also cannot run the compile.sh as root, as the script is complaining then that I run docker as root / sudo. So I have to clone the repo as plain user. Later I am running compile.sh in Docker, where I will be root. Many downloaded files will be owned by root then. As soon as tar is run (by root) this tries to keep the old user and fails (workaround: add the option --no-same-owner, e.g. in kernel-git-oras.sh:217), I also have to remove the "-p" option from cp (e.g. kernel-config.sh:69). But I am hit by a similar issue in the build process and are flooded with many error messages like these: GEN kernel/kheaders_data.tar.xz tar: include/clocksource/samsung_pwm.h: Cannot change ownership to uid 0, gid 0: Invalid argument tar: include/clocksource/arm_arch_timer.h: Cannot change ownership to uid 0, gid 0: Invalid argument tar: include/clocksource/timer-davinci.h: Cannot change ownership to uid 0, gid 0: Invalid argument tar: include/clocksource/pxa.h: Cannot change ownership to uid 0, gid 0: Invalid argument tar: include/clocksource/timer-ti-dm.h: Cannot change ownership to uid 0, gid 0: Invalid argument tar: include/clocksource/hyperv_timer.h: Cannot change ownership to uid 0, gid 0: Invalid argument tar: include/clocksource/timer-xilinx.h: Cannot change ownership to uid 0, gid 0: Invalid argument tar: include/clocksource/timer-riscv.h: Cannot change ownership to uid 0, gid 0: Invalid argument tar: include/clocksource/timer-goldfish.h: Cannot change ownership to uid 0, gid 0: Invalid argument tar: include/trace/stages/stage6_event_callback.h: Cannot change ownership to uid 0, gid 0: Invalid argument Docker seems to be recent (Docker version 29.6.2, build 1.fc44) - and I ran it according to the "Building with Docker" page: me@localhost:~/BananaPro/repo/build$ ./compile.sh docker-shell BOARD=bananapipro BRANCH=current BUILD_DESKTOP=no BUILD_MINIMAL=no EXPERT=yes KERNEL_CONFIGURE=no RELEASE=trixie KERNEL_BTF=no KERNEL_GIT=shallow root@dbd99257d5cb:/armbian# ./compile.sh The build directory is on a NFS share. And something seems to be very much screwed up ...

It is KERNEL_GIT=shallow, and this really helped (at least in the evening, when the 3MB/s were possible). What I am now stumbling across are errors in tar and cp due to file ownership issues: I cloned the Armbian repo as plain user and am now running in Docker as root: I probably should have cloned the repo as root already ...

I tried to run the image build process using Docker. At one point it tries to download the Linux tree and due to my slow Internet connection (max 3MB/s) there seems to be a connection reset from Github due to a too long download time (after 9 minutes, simillar times in 2 attempts). ✗ [ ...........](2.57 MB/s) Downloading linux-complete.git.tar 1.68/3.55 GB 47.34% 9m27s └─ sha256:dd18f1227c9bcf8d3a1c1ecd55721323639550c2845750f59168e17a0d0483bd Error: failed to copy content to /armbian/cache/git-bundles/kernel/linux-complete.git.tar.oras.pull.tmp/linux-complete.git.tar: copy failed: stream error: stream ID 1; PROTOCOL_ERROR; received from peer Is there any workaround besides switching to a faster Internet connection?

You hit the nail on its head! Immediately before reading your post I saw that the net.ipv4.ip_forward option is set to 0 on Trixie, although I set it in /etc/sysctl.conf to 1. Explanation: systemd-sysctl does not read this file on startup, but (among others) the files in /etc/sysctl.d. In Bookworm there is a symlink 99-sysctl.conf in /etc/sysctl.d, that points to /etc/sysctl.conf. After adding this same link in Trixie my setting net.ipv4.ip_forward=1 now survives a reboot. I think I mark this thread as "solved", although it is a NAT AP and not a bridged one.

I looked into the packet flow again with tcpdump and saw that on Trixie apparently no packets from wlan0 are forwarded to end0. A comparison of the iptables packets seems to confirm this: Bookworm / working: root@bananapipro2:/etc# iptables -nvL Chain INPUT (policy ACCEPT 2123K packets, 374M bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 328K 195M ACCEPT 0 -- end0 wlan0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 290K 48M ACCEPT 0 -- wlan0 end0 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 1637K packets, 309M bytes) pkts bytes target prot opt in out source destination root@bananapipro2:/etc# iptables -nvL -t nat Chain PREROUTING (policy ACCEPT 167K packets, 21M bytes) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 137K packets, 19M bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 58122 packets, 3604K bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 99 packets, 28970 bytes) pkts bytes target prot opt in out source destination 86604 5532K MASQUERADE 0 -- * end0 0.0.0.0/0 0.0.0.0/0 Trixie (not working): root@bananapipro:/etc/iptables# iptables -nvL Chain INPUT (policy ACCEPT 70695 packets, 7896K bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- end0 wlan0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- wlan0 end0 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 65128 packets, 7037K bytes) pkts bytes target prot opt in out source destination root@bananapipro:/etc/iptables# iptables -nvL -t nat Chain PREROUTING (policy ACCEPT 6782 packets, 1065K bytes) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 3033 packets, 803K bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 440 packets, 35473 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 9 packets, 2672 bytes) pkts bytes target prot opt in out source destination 431 32801 MASQUERADE all -- * end0 0.0.0.0/0 0.0.0.0/0 --> the FORWARD chain in the filter table has no packets at all in Trixie. The rules look very similar, iptables only uses some indices in the INPUT and OUTPUT chains of the filter tables: Bookworm: root@bananapipro2:/etc# cat iptables.ipv4.nat # Generated by iptables-save v1.8.9 (nf_tables) on Wed May 21 11:58:00 2025 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A FORWARD -i end0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i wlan0 -o end0 -j ACCEPT COMMIT # Completed on Wed May 21 11:58:00 2025 # Generated by iptables-save v1.8.9 (nf_tables) on Wed May 21 11:58:00 2025 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] -A POSTROUTING -o end0 -j MASQUERADE COMMIT # Completed on Wed May 21 11:58:00 2025 Trixie: root@bananapipro:/etc/iptables# cat rules.v4 # Generated by iptables-save v1.8.11 (nf_tables) on Sun Jul 19 19:08:36 2026 *filter :INPUT ACCEPT [3:156] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [3:984] -A FORWARD -i end0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i wlan0 -o end0 -j ACCEPT COMMIT # Completed on Sun Jul 19 19:08:36 2026 # Generated by iptables-save v1.8.11 (nf_tables) on Sun Jul 19 19:08:36 2026 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] -A POSTROUTING -o end0 -j MASQUERADE COMMIT # Completed on Sun Jul 19 19:08:36 2026 Any pointer where to look further would be very much appreciated 😉

Meanwhile I did replace systemd-resolved on Trixie with resolvconf. Unfortunately, although the configuration now is (to my knowledge) mostly identical to the working Bookworm AP, it still does not work. When I connect a Debian system to both APs, the output of "ip r" is identical. Also the output of "dig <some server>". But "ping" works only partially for the Trixie AP: I get only a ping answer for the AP address. Same for traceroute. What I did observe using tcpdump: ssh communication with the Bookworm system gives "ack/seq pairs": 23:56:26.276869 IP 172.24.1.77.54840 > 192.168.178.29.22: Flags [.], ack 18029, win 537, options [nop,nop,TS val 1656092742 ecr 742514735], length 0 23:56:26.278437 IP 192.168.178.29.22 > 172.24.1.77.54840: Flags [P.], seq 18029:18105, ack 8352, win 344, options [nop,nop,TS val 742514737 ecr 1656092742], length 76 Whereas the same with the Trixie system gives (apparently much longer) sequences of only "seq" entries: 23:56:26.962828 IP 172.24.1.77.54840 > 192.168.178.29.22: Flags [P.], seq 9612:9648, ack 19365, win 537, options [nop,nop,TS val 1656093428 ecr 742515405], length 36 23:56:26.964613 IP 192.168.178.29.22 > 172.24.1.77.54840: Flags [P.], seq 19365:19401, ack 9648, win 344, options [nop,nop,TS val 742515423 ecr 1656093428], length 36 23:56:26.982677 IP 172.24.1.77.54840 > 192.168.178.29.22: Flags [P.], seq 9648:9684, ack 19401, win 537, options [nop,nop,TS val 1656093447 ecr 742515423], length 36 23:56:26.984461 IP 192.168.178.29.22 > 172.24.1.77.54840: Flags [P.], seq 19401:19437, ack 9684, win 344, options [nop,nop,TS val 742515443 ecr 1656093447], length 36 23:56:27.001390 IP 172.24.1.77.54840 > 192.168.178.29.22: Flags [P.], seq 9684:9720, ack 19437, win 537, options [nop,nop,TS val 1656093466 ecr 742515443], length 36 I guess I get some SD cards now and install different clean images to start from ...

Now I attacked the issue from the clients side and tried to connect from a "real" (Debian) system. Client Syslog output on connect looks quite comparable, but on the "failing" AP I seem to have a DNS issue: ping and traceroute do not work from the client in that case (and work when I connect to the "Bookworm AP"). From the AP computers I can alway resolve hostnames. So I will investigate this further (on Bookworm the resolveconf service is used, on Trixie systemd-resolved: so I assume an issue in the DNS setup of dnsmasq). I will not follow the "RADIUS" path anymore (for now), the brcmf_psm_watchdog_notify issue will also remain untouched (it is with me for a long time on the BPiPro now).

Now I have tried to bring my non-working Trixie setup as near as possible to my working Bookworm setup (both BananaPi Pro boards) (and: no bridging stuff here!): -I replaced systemd-networkd with NetworkManager on Trixie -I restricted NM to handling of end0 (wlan0 as "unmanaged"), set up everything "the old way" as it is working on Bookworm (manual hostapd, dnsmasq, iptables) And now I try to connect from my mobile phone to both APs: Bookworm is okay as always, Trixie says "connect w/o internet" (although the very first time before rebooting it connected w/ Internet). In the extended dnsmasq log I see in both cases lots of connection names, but anyway the Trixie AP claims to have "no internet". The only visible difference is the log output for hostapd (both v2.10): in the failing case the following lines are printed for every connection, whereas in the working case these are not there: 2026-07-14T19:15:41.505822+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e IEEE 802.11: associated 2026-07-14T19:15:41.541156+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e RADIUS: starting accounting session 0F32AA180BFF0C2C 2026-07-14T19:15:41.542161+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e WPA: pairwise key handshake completed (RSN) ....(many lines of log output from dnsmasq) 2026-07-14T19:15:58.724493+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e IEEE 802.11: disassociated I have no clue what activates this RADIUS stuff and why there is this associated / disassociated pair (or why it is not there in the Bookworm case).

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.)

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

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.