Gluon v2022.1.x: build conditionally broken

Moin,

hmm, ich schaffe es irgendwie, auf zwei getrennten Build-Hosts, Gluon v2022.1.3, v2022.1.x als auch Master so zu bauen, daß sowohl ein DAP-X1860 als auch ein Archer C6 v2 fröhlich mit älteren Geräten meshen — aber auf ihre APs können meine Androiden nicht mehr zugreifen.

Wed Apr 26 18:31:52 2023 daemon.info hostapd: client0: STA 36:f4:d8:fa:53:0e IEEE 802.11: authenticated
Wed Apr 26 18:31:52 2023 daemon.notice hostapd: client0: STA-OPMODE-N_SS-CHANGED 36:f4:d8:fa:53:0e 2
Wed Apr 26 18:31:52 2023 daemon.info hostapd: client0: STA 36:f4:d8:fa:53:0e IEEE 802.11: associated (aid 1)
Wed Apr 26 18:31:52 2023 daemon.notice hostapd: client0: AP-STA-CONNECTED 36:f4:d8:fa:53:0e
Wed Apr 26 18:31:52 2023 daemon.info hostapd: client0: STA 36:f4:d8:fa:53:0e RADIUS: starting accounting session C862CFABFF4B8837
Wed Apr 26 18:32:11 2023 daemon.notice hostapd: client0: AP-STA-DISCONNECTED 36:f4:d8:fa:53:0e
Wed Apr 26 18:32:11 2023 daemon.info hostapd: client0: STA 36:f4:d8:fa:53:0e IEEE 802.11: disassociated
Wed Apr 26 18:32:12 2023 daemon.info hostapd: client0: STA 36:f4:d8:fa:53:0e IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

Buildhosts laufen unter Ubuntu 20.04.3 bzw. Debian 11, beides AMD Ryzen 5 3600; v2021-Images tun, v2022 haben besagtes Problem. Bei rund 6 Stunden für einen Build from Scratch (alle Architekturen) ist das mit Try&Error etwas lästig, daher die Frage: kennt das Phänomen jemand und weiß Abhilfe?

Da v2022.1.3- und Master-Builds von z. B. FFRN das Problem nicht zeigen, liegt ziemlich sicher ein Layer-8-Problem vor, nur: welches? JFTR: Site inkl. Makefile liegt auf github.

Any hints appreciated.

so direkt sehe ich erst einmal keine Ursache abseits von unrelated Dingen die ich anders machen würde.
Wo liegt die v2021.1.x Site, damit man funktionierend mit angepasst vergleichen kann?

und wieso eigentlich full rebuild und alle targets beim debugging?

Das wird schwieriger :wink: Pre-v2022 gibt’s eigene, gepatchte und ggf. hochgepatchte Gluon-Versionen: site, source. (Nein, ich hab’s nicht so mit gits branches; neumodischer Tüddelkram aus Sicht eines alten cvs-Nutzers … Hier allerdings steht git checkout remotes/origin/v2021.1.2-ffgt im (nicht versionierten) Buildscript.)

Weil … steht halt im Makefile und das wäre wieder ein commit+pull … oder Multi-Line-sed im Buildscript. Nee, eigentlich, weil ich noch 'ne andere Architektur ausprobieren wollte (4040 fliegen hier noch rum), aber das noch nicht getan habe, weil ich mir eigentlich nicht erklären kann, warum das Problem bei MIPS liegen sollte …

Hatte jetzt mal nur die „interessanten vier“ gebaut:

 1: ath79-generic        built with RC [0] at Wed 26 Apr 2023 11:55:36 PM CEST, took 30 minutes
 2: ipq40xx-generic      built with RC [0] at Thu 27 Apr 2023 12:17:10 AM CEST, took 21 minutes
 3: ramips-mt7621        built with RC [0] at Thu 27 Apr 2023 12:39:01 AM CEST, took 21 minutes
 4: x86-64               built with RC [0] at Thu 27 Apr 2023 01:02:28 AM CEST, took 23 minutes

(Hmmja, x86 war über — ist traditionell halt die sonst erste & einzige Arch, da schnell in VM testbar.) Mit XGLUON_SITE_PACKAGES in site.mk, sprich ohne externe Pakete: der C6 mag noch immer keine STAs.

Ich laß’ heute Nacht die alte Xeon-Möhre das mal mit -j48 durchkauen, mal sehen, was dann dabei rauskommt.

Die hatte zuwenig inodes … Aber ja, auch auf Intel (Pentium Gold) kompiliert, verweigert sich der hostapd auf dem C6 in meinem Image den Androiden :frowning:

Zwei WDR3600 v1, einer mit unserer FW 1.4 (v2021.1/19.07-SNAPSHOT-based), der andere mit 1.5 (v2022.1/22.03-SNAPSHOT-based).

$ diff -u /tmp/hostapd-phy0.conf-1*
--- /tmp/hostapd-phy0.conf-14	2023-04-27 13:31:06.000000000 +0200
+++ /tmp/hostapd-phy0.conf-15	2023-04-27 13:32:44.000000000 +0200
@@ -17,12 +17,14 @@
 ht_coex=0
 ht_capab=[LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40]
 
+radio_config_id=a0448303632019cd8ee1755f482a59b9
 interface=client0
 ctrl_interface=/var/run/hostapd
 ap_isolate=1
 bss_load_update_period=60
 chan_util_avg_period=600
 disassoc_low_ack=1
+skip_inactivity_poll=0
 preamble=1
 wmm_enabled=1
 ignore_broadcast_ssid=0
@@ -31,9 +33,13 @@
 multi_ap=0
 auth_algs=1
 wpa=0
-ssid=KreisGT.freifunk.net.2G.14
+ssid=KreisGT.freifunk.net.2G.15
 bridge=br-client
-bssid=0a:bf:54:cb:78:88
+wds_bridge=
+snoop_iface=br-client
+qos_map_set=0,0,2,16,1,1,255,255,18,22,24,38,40,40,44,46,48,56
+config_id=54639b11dcc0d8699d5557df4ab7a13e
+bssid=22:c5:e3:28:9b:a0
 
 
 bss=owe0
@@ -42,6 +48,7 @@
 bss_load_update_period=60
 chan_util_avg_period=600
 disassoc_low_ack=1
+skip_inactivity_poll=0
 preamble=1
 wmm_enabled=1
 ignore_broadcast_ssid=0
@@ -49,16 +56,21 @@
 utf8_ssid=1
 multi_ap=0
 sae_require_mfp=1
+sae_pwe=2
 auth_algs=1
 wpa=2
 wpa_pairwise=CCMP
 ssid=WPA3.KreisGT.freifunk.net
 bridge=br-client
+wds_bridge=
+snoop_iface=br-client
 wpa_disable_eapol_key_retries=0
 wpa_key_mgmt=OWE
 okc=1
 ieee80211w=2
 group_mgmt_cipher=AES-128-CMAC
-bssid=0a:bf:54:cb:78:8a
+qos_map_set=0,0,2,16,1,1,255,255,18,22,24,38,40,40,44,46,48,56
+config_id=20fcd3c8a21f98db07f326eb6aba6776
+bssid=22:c5:e3:28:9b:a2

logread:

Verbindung zu .2G.14

Thu Apr 27 14:44:31 2023 daemon.info hostapd: client0: STA 02:24:f3:10:0a:13 IEEE 802.11: authenticated
Thu Apr 27 14:44:31 2023 daemon.info hostapd: client0: STA 02:24:f3:10:0a:13 IEEE 802.11: associated (aid 1)
Thu Apr 27 14:44:31 2023 daemon.notice hostapd: client0: AP-STA-CONNECTED 02:24:f3:10:0a:13
Thu Apr 27 14:44:31 2023 daemon.info hostapd: client0: STA 02:24:f3:10:0a:13 RADIUS: starting accounting session A5CECA58939BC9B3

Verbindung zu .2G.15

Thu Apr 27 14:51:00 2023 daemon.info hostapd: client0: STA 56:24:b1:45:9b:eb IEEE 802.11: authenticated
Thu Apr 27 14:51:06 2023 daemon.info hostapd: client0: STA 56:24:b1:45:9b:eb IEEE 802.11: authenticated
Thu Apr 27 14:51:06 2023 daemon.info hostapd: client0: STA 56:24:b1:45:9b:eb IEEE 802.11: associated (aid 1)
Thu Apr 27 14:51:06 2023 daemon.notice hostapd: client0: AP-STA-CONNECTED 56:24:b1:45:9b:eb
Thu Apr 27 14:51:06 2023 daemon.info hostapd: client0: STA 56:24:b1:45:9b:eb RADIUS: starting accounting session 868C3C856B1D12AB
Thu Apr 27 14:51:24 2023 daemon.notice hostapd: client0: AP-STA-DISCONNECTED 56:24:b1:45:9b:eb
Thu Apr 27 14:51:24 2023 daemon.info hostapd: client0: STA 56:24:b1:45:9b:eb IEEE 802.11: disassociated
Thu Apr 27 14:51:25 2023 daemon.info hostapd: client0: STA 56:24:b1:45:9b:eb IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

Irgendwas mit Firetruck …

Hmm.

Ich habe die Münchner WireGuard-FW gebaut: mein Handy kann sich verbinden.

Ich habe dann die Münchner FW auf unsere Meshes und Tunneldigger statt WG umkompiliert — und selbst mit ohne OWE (MUC macht kein OWE) kann sich der Client nicht verbinden. What the heck‽

1 „Gefällt mir“

was heißt denn das? irgendwo dabei entsteht ja offensichtlich das Problem, also bitte genauer beschreiben was du da tust.

Wireguard-Package entsorgen und dafür Tunneldigger mit rein, domains durch unsere ersetzen, gluon-ssid-changer + ffgt-banner mit rein, um eine Basis-FW mit Paketen von uns zu haben. Doch schon da ziehe ich das Problem augenscheinlich mit rein:

ffgt@kaos:~/build/gluon-ffm-v2022.1/site-ffm$ mv domains domains_wg ; rsync -av ../../gluon-ffgt-v2022.1/site-ffgt/domains .
sending incremental file list
domains/
domains/bfe.conf
domains/boy.conf
domains/fsl.conf
domains/gt8.conf
domains/gto.conf
domains/gut.conf
domains/lbg.conf
domains/mid.conf
domains/neb.conf
domains/rhw.conf
domains/wrz.conf
domains/xx1.conf
domains/xx2.conf
domains/xx3.conf
domains/xzx.conf
domains/zzz.conf

sent 39,823 bytes  received 324 bytes  80,294.00 bytes/sec
total size is 38,736  speedup is 0.96
ffgt@kaos:~/build/gluon-ffm-v2022.1/site-ffm$ for i in $(cd /tmp/github/site-ffm; find . -type f | grep -v \.git | sed -e 's%^\./%%g') ; do diff -u /tmp/github/site-ffm/$i ~/build/gluon-ffm-v2022.1/site-ffm/$i 2>&1 ; done >/tmp/diff.txt
ffgt@kaos:~/build/gluon-ffm-v2022.1/site-ffm$ JOBS=36 make gluon-clean && JOBS=36 make

diff.txt lautet wie folgt:

--- /tmp/github/site-ffm/targets	2023-04-30 00:39:11.115704403 +0200
+++ /home/ffgt/build/gluon-ffm-v2022.1/site-ffm/targets	2023-04-28 01:44:57.120982260 +0200
@@ -1,25 +1 @@
 ath79-generic
-ath79-mikrotik
-ath79-nand
-bcm27xx-bcm2708
-bcm27xx-bcm2709
-bcm27xx-bcm2710
-bcm27xx-bcm2711
-ipq40xx-generic
-ipq40xx-mikrotik
-ipq806x-generic
-lantiq-xrx200
-lantiq-xway
-mediatek-mt7622
-mpc85xx-p1010
-mpc85xx-p1020
-mvebu-cortexa9
-ramips-mt7620
-ramips-mt7621
-ramips-mt76x8
-rockchip-armv8
-sunxi-cortexa7
-x86-64
-x86-generic
-x86-geode
-x86-legacy
--- /tmp/github/site-ffm/site.mk	2023-04-30 00:39:11.115704403 +0200
+++ /home/ffgt/build/gluon-ffm-v2022.1/site-ffm/site.mk	2023-04-30 00:45:43.038771287 +0200
@@ -14,19 +14,22 @@
 	status-page \
 	web-advanced \
 	web-private-wifi \
-	web-wizard
+	web-wizard \
+	mesh-vpn-tunneldigger
+
 
 GLUON_SITE_PACKAGES := \
 	ffho-ap-timer \
 	ffho-autoupdater-wifi-fallback \
-	ffho-web-ap-timer \
 	ffmuc-autoupdater-next2stable \
-	ffmuc-mesh-vpn-wireguard-vxlan \
 	ffmuc-simple-radv-filter \
 	iwinfo \
-	respondd-module-airtime
+	respondd-module-airtime \
+	ffgt-banner \
+	gluon-ssid-changer
+
 
-DEFAULT_GLUON_RELEASE := v2022.10.1~exp$(shell date '+%Y%m%d%H')
+DEFAULT_GLUON_RELEASE := 1.5.1
 
 # Allow overriding the release number from the command line
 GLUON_RELEASE ?= $(DEFAULT_GLUON_RELEASE)
@@ -36,7 +39,7 @@
 GLUON_REGION ?= eu
 
 # Languages to include
-GLUON_LANGS ?= en de
+GLUON_LANGS ?= de en
 
 # Additional package list generated by contrib/genpkglist.py
 
--- /tmp/github/site-ffm/modules	2023-04-30 00:39:11.115704403 +0200
+++ /home/ffgt/build/gluon-ffm-v2022.1/site-ffm/modules	2023-04-27 16:59:17.582943739 +0200
@@ -6,7 +6,7 @@
 ##	GLUON_SITE_FEEDS
 #		for each feed name given, add the corresponding PACKAGES_* lines
 #		documented below
-GLUON_SITE_FEEDS='ffmuc wireguard'
+GLUON_SITE_FEEDS='ffmuc wireguard ffgt'
 
 ##	PACKAGES_FFMUC_REPO
 #		the  git repository from where to clone the package feed
@@ -31,3 +31,8 @@
 ##  PACKAGES_WIREGUARD_BRANCH
 #   the branch to check out
 PACKAGES_WIREGUARD_BRANCH=main
+
+PACKAGES_FFGT_REPO=https://github.com/wusel42/ffgt_packages-v2020.1.git
+PACKAGES_FFGT_COMMIT=83d621e23a0b5e36296da1d3ad22e33907c222ee
+PACKAGES_FFGT_BRANCH=master
+
--- /tmp/github/site-ffm/site.conf	2023-04-30 00:39:11.115704403 +0200
+++ /home/ffgt/build/gluon-ffm-v2022.1/site-ffm/site.conf	2023-04-28 02:44:14.236870280 +0200
@@ -1,8 +1,8 @@
 {
-  hostname_prefix = 'ffmuc-',
-  site_name = 'Freifunk München',
-  site_code = 'ffmuc',
-  default_domain = 'ffmuc_welt',
+  hostname_prefix = 'unconfigured-node-',
+  site_name = 'Freifunk by 4830.org e. V.',
+  site_code = '4830',
+  default_domain = 'zzz',
 
   opkg = {
     extra = {
@@ -140,6 +140,28 @@
           '50bafd8216cab2ee1c11c215b528dd7c6396f3edfdab689c70ca04a9f284b931', -- grische
         },
       },
+      rawhide = {
+        name = 'rawhide',
+        mirrors = {'http://firmware.ipv6.4830.org/rawhide/sysupgrade'},
+        good_signatures = 1,
+        pubkeys = {
+          'fbc997a8fd3b7372b3044cf855c660f70b0f713f8ab1dca4b9a1ae297c8f5588', -- FFGT builder
+          'a7ac1e48f4459a995cf6bcd8d3668ca26cf36a1fe5981ddfca93d4c04632deeb', -- wusel
+          '3c09bcf54e9c2d244d7888c9d2bdea08b2f2dc249deda23ef8194a114be85390', -- QA1
+          'f3a88717ce7ec8250b40191edf088d6f30b9179ad7ec80a8e14abfd270ff8770', -- QA2
+        },
+      },
+      tng = {
+        name = 'tng',
+        mirrors = {'http://firmware.ipv6.4830.org/tng/sysupgrade'},
+        good_signatures = 1,
+        pubkeys = {
+          'fbc997a8fd3b7372b3044cf855c660f70b0f713f8ab1dca4b9a1ae297c8f5588', -- FFGT builder
+          'a7ac1e48f4459a995cf6bcd8d3668ca26cf36a1fe5981ddfca93d4c04632deeb', -- wusel
+          '3c09bcf54e9c2d244d7888c9d2bdea08b2f2dc249deda23ef8194a114be85390', -- QA1
+          'f3a88717ce7ec8250b40191edf088d6f30b9179ad7ec80a8e14abfd270ff8770', -- QA2
+        },
+      },
     },
   },
 
--- /tmp/github/site-ffm/Makefile	2023-04-30 00:39:11.111704373 +0200
+++ /home/ffgt/build/gluon-ffm-v2022.1/site-ffm/Makefile	2023-04-27 19:54:10.191167527 +0200
@@ -3,27 +3,31 @@
 GLUON_GIT_REF := v2022.1.3
 
 PATCH_DIR := ./patches
-SECRET_KEY_FILE ?= ${HOME}/.gluon-secret-key
+SECRET_KEY_FILE ?= ${HOME}/build/secret-build
 
 GLUON_TARGETS ?= $(shell cat targets | tr '\n' ' ')
 GLUON_AUTOUPDATER_BRANCH := stable
+GLUON_AUTOUPDATER_ENABLED := 1
 
-ifneq (,$(shell git describe --exact-match --tags 2>/dev/null))
-	GLUON_AUTOUPDATER_ENABLED := 1
-	GLUON_RELEASE := $(shell git describe --tags 2>/dev/null)
-else
-	GLUON_AUTOUPDATER_ENABLED := 0
-	EXP_FALLBACK = $(shell date '+%Y%m%d')
-	BUILD_NUMBER ?= $(EXP_FALLBACK)
-	GLUON_RELEASE := $(shell git describe --tags)~exp$(BUILD_NUMBER)
-endif
+#ifneq (,$(shell git describe --exact-match --tags 2>/dev/null))
+#	GLUON_AUTOUPDATER_ENABLED := 1
+#	GLUON_RELEASE := $(shell git describe --tags 2>/dev/null)
+#else
+#	GLUON_AUTOUPDATER_ENABLED := 0
+#	EXP_FALLBACK = $(shell date '+%Y%m%d')
+#	BUILD_NUMBER ?= $(EXP_FALLBACK)
+#	GLUON_RELEASE := $(shell git describe --tags)~exp$(BUILD_NUMBER)
+#endif
+
+GLUON_RELEASE := 1.5.1~$(shell cat buildnumber.txt)
 
 JOBS ?= $(shell cat /proc/cpuinfo | grep processor | wc -l)
 
 GLUON_MAKE := ${MAKE} -j ${JOBS} -C ${GLUON_BUILD_DIR} \
 	GLUON_RELEASE=${GLUON_RELEASE} \
 	GLUON_AUTOUPDATER_BRANCH=${GLUON_AUTOUPDATER_BRANCH} \
-	GLUON_AUTOUPDATER_ENABLED=${GLUON_AUTOUPDATER_ENABLED}
+	GLUON_AUTOUPDATER_ENABLED=${GLUON_AUTOUPDATER_ENABLED} \
+	--output-sync=target BUILD_LOG=1 V=s
 
 all: info
 	${MAKE} manifest
@@ -34,11 +38,14 @@
 	@echo '# FFMUC Firmware build'
 	@echo '# Building release ${GLUON_RELEASE} for branch ${GLUON_AUTOUPDATER_BRANCH}'
 	@echo
+	$(shell test -e buildnumber.txt || echo 1 > buildnumber.txt)
+	$(shell echo $$(expr $$(cat buildnumber.txt) + 1) > buildnumber.txt)
+
 
 build: gluon-prepare output-clean
 	for target in ${GLUON_TARGETS}; do \
 		echo ""Building target $$target""; \
-		${GLUON_MAKE} download all GLUON_TARGET="$$target"; \
+		${GLUON_MAKE} download all GLUON_TARGET="$$target" 2>&1 | tee build_$${target}.log ; \
 	done
 
 manifest: build
diff: /home/ffgt/build/gluon-ffm-v2022.1/site-ffm/domains/ffmuc_freising.conf: No such file or directory
diff: /home/ffgt/build/gluon-ffm-v2022.1/site-ffm/domains/ffmuc_uml_sued.conf: No such file or directory
diff: /home/ffgt/build/gluon-ffm-v2022.1/site-ffm/domains/ffmuc_uml_west.conf: No such file or directory
diff: /home/ffgt/build/gluon-ffm-v2022.1/site-ffm/domains/ffmuc_augsburg.conf: No such file or directory
diff: /home/ffgt/build/gluon-ffm-v2022.1/site-ffm/domains/ffmuc_uml_ost.conf: No such file or directory
diff: /home/ffgt/build/gluon-ffm-v2022.1/site-ffm/domains/ffmuc_muc_cty.conf: No such file or directory
diff: /home/ffgt/build/gluon-ffm-v2022.1/site-ffm/domains/ffmuc_gauting.conf: No such file or directory
diff: /home/ffgt/build/gluon-ffm-v2022.1/site-ffm/domains/ffmuc_muc_west.conf: No such file or directory
diff: /home/ffgt/build/gluon-ffm-v2022.1/site-ffm/domains/ffmuc_muc_ost.conf: No such file or directory
diff: /home/ffgt/build/gluon-ffm-v2022.1/site-ffm/domains/ffmuc_uml_nord.conf: No such file or directory
diff: /home/ffgt/build/gluon-ffm-v2022.1/site-ffm/domains/ffmuc_muc_nord.conf: No such file or directory
diff: /home/ffgt/build/gluon-ffm-v2022.1/site-ffm/domains/ffmuc_muc_sued.conf: No such file or directory
diff: /home/ffgt/build/gluon-ffm-v2022.1/site-ffm/domains/ffmuc_welt.conf: No such file or directory

(Ich hätte auch gerne statt ffm eine andere Community mit L2TP & Multidomain genommen, habe aber auf die Schnelle keine gefunden, die schon v2022-ready wäre. Daher der „Umweg“ über einen angepaßten ffm-Build. Ich tappe leider absolut im dunkeln, wie sich die Verhaltensänderung in (vermutlich) hostapd durch Drittpakete erzeugen lassen soll.)

hm, also von den angesprochenen Anpassungen im Vergleich zu FFM kommt ja eigentlich nur die domain config in Frage.

Eine andere mögliche Ursache ist, dass es Fehler im Buildprozess geben könnte die nicht zum Abbruch des builds führen, hast du denn komplette Verbose-build-Logs?

Man könnte sich dem Problem auch noch nähern, indem du mal
a) auf deinem buildhost die ffm firmware baust und prüfst ob das Ergebnis funktioniert
b) deinen build woanders machst, statt auf dem buildhost. es reicht ja immer nur ein target zu bauen für debug-zwecke.

Danke, sehe ich ähnlich, daher hätte ich ja gerne einen andere LTP2-Multidomain-FW genommen und nur meine domain/*.conf reingeklatscht. Aber Lippe und Münsterland bauen die irgendwie erst zusammen, Nordwest hat auch irgendein Skriptwerk drumrum, und viele andere machen noch immer mit fastd rum … Aber ich werd’s wohl mal mit FFNW probieren.

Ja, ich habe Buildlogs, …

… und häufiger Mal ein ‚Error 1 (ignored)‘. Aber ja, da kann ich noch mal nachsehen, wo das ist. Aber hostapd wird ja gebaut, nur wird die Verbindung gefühlt »nicht durchgeschaltet … (sofern das überhaupt an hostapd liegt)

Mon May  1 23:40:47 2023 daemon.info hostapd: client0: STA 56:24:b1:45:9b:eb IEEE 802.11: authenticated
Mon May  1 23:40:47 2023 daemon.info hostapd: client0: STA 56:24:b1:45:9b:eb IEEE 802.11: associated (aid 1)
Mon May  1 23:40:47 2023 daemon.notice hostapd: client0: AP-STA-CONNECTED 56:24:b1:45:9b:eb
Mon May  1 23:40:47 2023 daemon.info hostapd: client0: STA 56:24:b1:45:9b:eb RADIUS: starting accounting session 6A5E08E8B1B67A17
Mon May  1 23:41:05 2023 daemon.notice hostapd: client0: AP-STA-DISCONNECTED 56:24:b1:45:9b:eb
Mon May  1 23:41:05 2023 daemon.info hostapd: client0: STA 56:24:b1:45:9b:eb IEEE 802.11: disassociated
Mon May  1 23:41:06 2023 daemon.info hostapd: client0: STA 56:24:b1:45:9b:eb IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

Ansonsten:

ok, also liegts tendentiell nicht am build…

könntest du das android gerät mal per USB an einen Rechner anschließen und android debug logs betrachten, was die während des connect/disconnect so sagen? vielleicht hilft das weiter…

Mit iOS/Windows/Linux clients geht alles?

Oh, gute Frage, gar nicht probiert …

Hoppala, das X250 (iwlwifi) verbindet sich, bekommt aber nur die ULA-v6- und keine v4-Adresse. WTF‽ Gegen den AP mit der v2021-basierten FW tut’s, wie es soll (ULA-v6 von Knoten, IPv4 per DHCP vom Gateway, Public-v6 per RA vom Gateway).

Ohne ffmuc-simple-radv-filter bekommt das X250 nun immerhin ULA-v6 von Knoten und Public-v6 per RA vom Gateway. Die IPv6-Gateways sind anpingbar (link-local), aber nicht die Nameserver (Public v6). Öh?

naja, dann bist du nun ja fast am Ziel, das Paket oder seine Konfiguration passt so nicht zur Firmware und deinen Domains und vielleicht ist irgendwo das falsche IPv6-Subnetz hinterlegt in Paket oder site/domain und daher wird die Firewall aktiv?

Welche Firewall? Ich habe nun – AFAICS – alle FFMUC-Spezialitäten aus meinem Build enternt. Dennoch funkt noch immer etwas dazwischen, verhindert IPv4- und IPv6-Datenverkehr: IPv4-Kram sehe ich im tcpdump auf den Client, aber jener bekommt dennoch keine v4-IP. SSH vom Client auf die NextNode-IP (ULA) als auch Ping auf die IPv6-Default-GWs (link-local) geht — aber Ping auf die NS (Public-IPs der GWs) geht nicht. Testknoten wurde per „firstboot“ von Altlasten befreit, dennoch obige Probleme — die aus v2020 und v2021 gänzlich unbekannt sind. Und das Verhalten von Androiden ist auch gänzlich anders als bisher bekannt (kein „kein Internetzugang“, sondern Disconnect nach wenigen Sekunden).

FTR: domains/*.conf hat als „prefix6“ nur den ULA-Prefix — Public-v6 kommt von den GWs und die FW hat explizit keinen Schimmer davon, welcher Prefix genutzt wird.

auf dem Knoten natürlich.
zu deinem DHCP Problem habe ich noch keine Idee…
das IPv6 Problem könnte vielleicht daran liegen, dass du das Paket ebtables-source-filter nutzt aber dein public IPv6 Prefix jeder Domain nicht in den Domain configs drin hast als extra_prefixes6 ? ist aber auch nur geraten, weil es bei uns eben drin ist.

Nach der Feststellung, daß ich das Problem fälschlich bei hostapd suchte, habe ich mal alle ebtables*-Pakete rausgeworfen — bingo!

Genau das war’s; das Package hatten wir bislang nicht drin, war aber im übernommenen site.mk dabei — mit Gluon v2022 haben wir den FW-Bau umgestellt und nur unsere Pakete hinzugefügt: Schade Schokolade.

Hintergrund: prefix4 haben wir schon länger nicht mehr drin, da next_node.ip4 bei (unseren) Builds irgendwie unsinnig ist: die IP ist je Mesh („Domain“) unterschiedlich, kann sich somit eh’ keiner merken. prefix6 ist bei uns ein ULA-/64 – und die next_node.ip6 war auch von Client ansprechbar, Public-IPv6 – der Prefix (/64 aus verschiedenen 2001:bf7-/44 je Mesh) samt Gateway kommt per RA von den GWs – halt nicht.

Ich entsinne mich dunkel, die Doku zum Paket mal gelesen und es für uns als untauglich angesehen zu haben; aber mit der Änderung haben wir es uns nun eingetreten: shit happens.

Wünschenswert wäre, daß – wie bei vielen anderen Paketen – eine Überprüfung stattfindet; hier: ob prefix4 gesetzt ist und mehr als ULA-Adressen in prefix6 bzw. extra_prefixes6 definiert sind, wenn ebtables-source-filter eingebunden wird. Weil, für Sie getestet, so ist’s kacke. Hrmpft.