loeriver Posted July 6 Posted July 6 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. 0 Quote
eselarm Posted July 7 Posted July 7 (edited) 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 July 7 by eselarm 0 Quote
loeriver Posted July 7 Author Posted July 7 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 0 Quote
eselarm Posted July 7 Posted July 7 (edited) 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 July 7 by eselarm 0 Quote
eselarm Posted July 7 Posted July 7 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. 0 Quote
eselarm Posted July 7 Posted July 7 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. 0 Quote
loeriver Posted July 7 Author Posted July 7 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.) 0 Quote
eselarm Posted July 8 Posted July 8 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. 0 Quote
eselarm Posted July 8 Posted July 8 # 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 0 Quote
eselarm Posted July 10 Posted July 10 On 7/7/2026 at 10:33 PM, loeriver said: 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! Similar quick test here: N100 with PCIe ethernt and wifi HW, already a br0 with enslaved ethernet, I set up a working hostapd.conf, enabled hostapd.service and added /etc/systemd/network/22-wlp2s0.network [Match] Name=wlp2s0 [Network] Bridge=br0 ConfigureWithoutCarrier=yes Then reboot and properly working AP. Is Opensuse Tumbleweed. But it is rather 'static', not as flexible/dynamic as with NM. For example, if I do networkctl down wlp2s0 ; sleep 30 ; networkctl up wlp2s0 the AP still works, but network list shows failed for wlp2s0 I though maybe it has to do with the fact that Tumbleweed has no sysV compatibility anymore (folder /etc/init.d/ is not there), so no option that something goes wrong potentially due to some sync issues, but I think I cannot draw that conclusion. Quick check shows no relation between hostapd.service and systemd-networkd, but it is much more extensive than for debian13 for sure. 0 Quote
Torte Posted July 14 Posted July 14 Am 7.7.2026 um 22:33 schrieb loeriver: 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) These error messages don't look good. Have you tried setting up and working with that wifi device alone (i.e. without all that bridging stuff)? This seems to me like a problem with either firmware loading for this adapter, or an unusable configuration, like unusable tx/rx power or channel for the specified region (e.g. if there has been no region code set for that interface). 0 Quote
loeriver Posted July 14 Author Posted July 14 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). 0 Quote
eselarm Posted July 14 Posted July 14 (edited) 2 hours ago, loeriver said: ....(many lines of log output from dnsmasq) So you try routed AP instead of bridged. Trixie might handle 'iptables' in a different way, depends also what alternatives you have for that and/or if it is netfilter underneath. This kind of manual setup (routed, hostapd) I did before Bookworm only a few times, rest is always bridged and basically using only NM. It seems to me that something on IP layer is not accepted by your phone, so it disconnects. You need to dig more and deeper and also still take in to account what is said about that brcmf_psm_watchdog_notify issue. But it seems yest another issues. Edited July 14 by eselarm 0 Quote
loeriver Posted July 15 Author Posted July 15 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). 0 Quote
eselarm Posted July 15 Posted July 15 (edited) 3 hours ago, loeriver said: systemd-resolved Yes, I already forgot this and maybe more; Armbian uses this by default now AFAIK, so this is another issue like netplan; I normally do in-place dist-upgrades, so my older SBC's I bought when Buster was the current Debian version, so that is still somewhere in a tag in a image generation file or so, but os-release is 13 and kernel 6.18. But for 1 case, I did take a recent/new Armbian image (Trixie) and it did cost a lot of time as the default settings for that don't work properly in my home network, so after reading freedesktop.org docs and with extra setting in conf file, it worked. But openresolv and a fixed resolv.conf is a simpler base. Edited July 15 by eselarm 0 Quote
loeriver Posted July 16 Author Posted July 16 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 ... 0 Quote
eselarm Posted July 17 Posted July 17 8 hours ago, loeriver said: What I did observe using tcpdump: ssh communication with the Bookworm system gives "ack/seq pairs": I discovered via an only partly working ssh (I thought was WiFi signal strenght issue or so) that a new version of firewalld was installed and also new conf file that had default set to public instead of trusted (what should be fine for LAN only direct traffic). On a typical generic client-only laptop/computer you probably won't notice. Best is to keep that default and add a zone= statement to the NM profile for a specific connection. I have seen the same for systemd-networkd, but not done anything myself with it. Also should not happen on Debian Stable, but rolling distro is another story. 0 Quote
loeriver Posted July 27 Author Posted July 27 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 😉 0 Quote
Solution eselarm Posted July 27 Solution Posted July 27 2 hours ago, loeriver said: --> the FORWARD chain in the filter table has no packets at all in Trixie. Maybe on you Bookworm installation, you have something in /etc/sysctl.d/ or so (once added by yourself) which is not there by default on standard/new/fresh Debian. It is about a decade ago I did that as well when manual iptables actions for WiFi AP's etc. If using NM or systemd-networkd config files, it is done there. And I see in Debian Trixie some old files are not there anymore, maybe read /etc/sysctl.d/README.sysctl 0 Quote
loeriver Posted July 27 Author Posted July 27 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. 0 Quote
loeriver Posted August 3 Author Posted August 3 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 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.