[fakeroot/pseudo] DECT "funktioniert nicht mehr" (dect_manager läuft nicht)

[pfichtner]

Auf meiner 7390 (auf weiterer 7390 nachgestellt) habe ich reproduzierbar das Problem, dass DECT nicht mehr funktioniert. Die Mobilteile finden die Basis nicht mehr, laut Oberfläche ist die DECT-Basisstation nicht aktiviert, beim Versuch zu aktivieren erhalte ich die Fehlermeldung "Es ist ein Fehler aufgetreten. Fehlercode: 1".

Auf der Suche nach dem Fehler habe ich festgestellt, dass der Prozess "dect_manager" nicht läuft, d.h. dieser wird wohl nicht gestartet oder wurde aus irgedwelchen Gründen wieder beendet. Sobald ich "dect_manager" manuell starte verbinden sich die Mobiteile wieder.

Letzte Version von der ich weiß, dass sie geht ist 2135e69b3 (2022-12-11)
Erste Version von der ich weiß, dass sie nicht geht ist 5856cd8e6 (2023-01-08)

Hat jemand eine Idee, welchen Änderung das verursacht haben könnte bzw. wie ich das Problem weiter eingrenzen kann?

[pfichtner]

Ein erster Versuch mit bisect weitereinzuschränken schlug fehlt, denn am Ende war selbst die erneut gebaute Version 2135e69b3 nicht ok, auch dort lief dect_manager nicht. Nach dem erneuten Einspielen des vor Wochen gebauten Images (basierend auf dem gleichen Tag), welches ich als "ok" bezeichnete, lief der dect_manager wieder.

Werde es nochmals versuchen, diesmal aber mit distclean vor jedem Build, bei meinem Versuch gestern hatte ich die jewiligen Build-Ergebnisse stehen lassen und nur mit make olddefconfig && make gebaut.
Eine andere/bessere Idee habe ich zur Zeit nicht.

[fda77]

Das kann alles mögliche sein. Vielleicht ein remove-patch der eine Lib zuviel entfernt. Oder eine Variable die im environmetn fehlt - wobei freetz mit diesem dienst nichts macht.
Es könnte aber auch ein config-problem sein, dafür ist avm bekannt. Der Telefonteil vom Fos ist der älteste und wird teilweise noch binär gespeichert, war halt schon immer so. Da kommt es ab und an mal vor dass was durcheinander kommt und avm's schlecht programmierte closedsouce-blobs crashen. Das ist besonders häuftg nach einem fos-downgrade ohne werksresett
Du könntest die Box mal zurücksetzen und als neu zusammenklicken...

[pfichtner]

Ja, das letzt genannte Problem hatte ich auch schon ein paar Mal, gerade in der Ecke von WLAN. Probiere ich heute Abend mal aus. Da sich die AVM Firmware im genannten Zeitraum nicht geändert hat (die 7390 kriegt ja eigentlich keine Updates mehr) halte ich das aber für eher unwahrscheinlich.

[fda77]

Ich hab auch noch eine 7390, die hat aber kein Dect an.
Bei einer 7490 hatte ich mal das Problem dass Wlan immer auf Auto-Kanal stand und eine Änderung nicht gespeichert wurde. Nach Nullen von ein paar avm-wlan-configs gings dann wieder. Ich vermute mit "echo > var/flash/...". Also nicht ganz leer, das kann Problem beim Speichern machen.
Oder halt ein paar Stündchen hinsetzen und die avm-config komplett neu zusammenklicken :)

[pfichtner]

So, und es ist noch viel seltsamer als vermutlich befürchtet.

Da ich auch den als "ok" genannten Commit nachträglich nur noch mit dem gleichen Resultat gebaut bekomme habe (ganz normales Image, aber dect_manager läuft nach Neustart nicht), habe ich das Problem/den Fehler in der Buildumgebung vermutet und mir angeschaut, was sich dort im genannten Zeitraum verändert hat: Und die größte Änderung war dort ein Update von Ubuntu20 auf Ubuntu22.

Also habe ich einen Commit gewählt, den ich nachweislich nun nicht mehr zu einem 100% funkionierenden Image habe bauen können und habe diesen mit meinem Buildsystem Stand Dezember 2022 (als das Image noch ok war) gebaut. Übrigens auch noch so ein Vorteil von Docker: "Reproducible Builds", ich kann auch die Buildumgebung zum Zeitpunkt X nutzen.
Und siehe da: Das mit dem Alt-Buildsystem gebaute Image war ok! (Gleicher Commit sogar gleicher Checkout, also ausgechecktes Verzeichnis 1x mit "neu" und 1x mit "alt" gebaut).

Ich habe dann noch etliche weitere Tests gefahren, um möglichst dumme Zufälle weiter auschließen zu können, z.B. nach dem erfolgreichen Bau eines commits mit dem Alt-Buildsystem das Alt-Buildsystem auf Ubuntu22 upgedatet und dann war das Image nach Bau mit dem upgedateten Alt-Buildsystem tatsächlich auch defekt.

Ich habe zahlreiche Builds auf unterschiedlichsten Commits jedesmal mit Dem Buildsystem Stand Dezember (=Ubuntu20) und dann erneut mit de aktuellen Buildsystem (=Ubuntu22) durchgeführt, immer wieder mit dem gleichen Ergebnis: Build mit Ubuntu20 ok, Build mit Ubuntu22 sieht eigentlich auch ok/normal aus, aber der dect_manager wird nicht gestartet oder non orgendwas/durch irgendwas beendet bevor ich per ssh drauf komme.

Klingt für mich erstmal unerklärlich/unplausibel. Würde mir das jemand schildern würde ich auch erstmal sagen: Entweder da kommt ein Image raus und das läuft dann entweder richtig oder gar nicht oder es kommt eben erst gar ein Image raus. Dass da ein Image raus kommt in dem ein kleiner Teil, aus welchen Gründen auch immer, nur wegen der Änderung des Buildsystems (Kompiler? Kompiler bei dem ein/das binary welches dect_manager starten soll anders aussieht?) nicht funktioniert, klingt mehr als seltsam. Ich habe aber wie gesagt, genügend Konstellationen ausprobiert um mir hier ziemlich sicher zu sein, dass die Ursache hier am Ubuntu20 vs. Ubuntu22 zu liegen scheint.

Zur Sicherheit habe ich auch noch die Prüfsumme des dect_manager binaries in allen (ok und nicht-ok) Images überprüft: Diese sind alle identisch, was daraus schließen lässt, dass weder unter ubuntu20 noch ubuntu22 Änderungen am binary vorgenommen werden/wurden.

[fda77]

Da bleibt nur 1 Ursache: Dein Hardware ist hinüber. Versuch doch mal ein anderes Netzteil

[pfichtner]

Ich habe ungefähr 12- 15 unterschiedliche Commits auf zwei unterschiedlichen Fritzboxen je 1x unter Ubuntu20 und je 1x unter Ubuntu22 verprobt, jeweils mit dem gleichen Ergebnis: Jedes unter Ubuntu20 gebaute Image funktioerte auf Fritzbox A und Fritzbox B, der identische Commit mit Ubuntu22 gebaute funktionierte, bis darauf, dass der dect_manager nicht lief.
Ich kann mir beim besten Willen nicht vorstellen, wie da die zwei Netzteile (oder andere HW-Probleme) mit reinspielen sollten, Wobei ich ja auch völlig ratlos bin.

Aber Bau mit u20, bespielen: ok
u20 auf u22 updaten, bauen, bespielen: nicht ok
wieder mit u20 bauen, bespielen: wieder ok
und das ca. 12-15 mal zwei unterschiedlichen Geräten mit unterschiedlichen Netzteilen lässt ein Hardwareproblem eher unwahrscheinlich sein.

[fda77]

Der dect_manager nutzt keine libs von freetz, höchstens wurde eine entfernt die dieser braucht. Sonst kann ich mit nicht vorstellen was das mit Ubuntu zu tun haben könnte. Es kann sein dass pseudo oder fakeroot nicht will, das merk man aber.
Such halt die stelle an der der Daemon gestartet wird und aktiviert loggen wenn er es kann. Und/oder strace (in eine date loggen) davor um zu sehen warum er nicht weiterläuft. Ansonsten die üblichen logs + syslog durchlesen

[pfichtner]

Mit fakeroot hatte ich beim Bau für W920V auch vor Wochen Probleme (also nicht hier für die 7390), das brach mit permission Problemen ab und ich hatte es durch pseudo ausgetauscht.
In den logs hatte ich gesucht und nichts gefunden, ich hänge mich heute Abend nochmal auf die serielle Konsole, vielleicht sehe ich da was.
Das fiese ist ja: Wenn ich den Daemon anschließend manuell starte läuft er, d.h. ich muss im init sichen, ein manuelles strace bringt mich auch nicht weiter.
Ich schaue heute Abend mal, ob ich raus kriege, ob jemand den dect_manager versucht zu starten und wenn ja, warum er sich dann offensichtlich beendet/beendet wird.

[pfichtner]

Erste Analyse:

• dect_manager wird/sollte von telefon gestartet (werden), passier aber im nok Fall nicht
• telefon wird in beiden Fällen aufgerufen (/etc/init.d/rc.voip)
• diff der straces von telefon sieht für mich so aus, als ob die erster relevate Unterschied hier liegt:

ok Image gebaut mit ubuntu20:

open("/dev/capi20", O_RDWR)             = 7
ioctl(7, CAPI_INSTALLED, 0)             = 0
ioctl(7, CAPI_GET_PROFILE, 0x2ac56250)  = 0
ioctl(7, CAPI_GET_PROFILE, 0x2ac56250)  = 0
ioctl(7, CAPI_GET_PROFILE, 0x2ac56250)  = 0

nok Image gebaut mit ubuntu22:

open("/dev/capi20", O_RDWR)             = 7
ioctl(7, CAPI_INSTALLED, 0)             = -1 ENOTTY (Inappropriate ioctl for device)
time([644 /* 1970-01-01T01:10:44+0100 */]) = 644 (1970-01-01T01:10:44+0100)
send(6, "<11>Jan  1 01:10:44 telefon[3382"..., 46, MSG_NOSIGNAL) = 46
shmdt(0x2aab8000)                       = 0
shmdt(0x2b052000)                       = 0

Es liegt also nicht an dect_manager oder telefon sondern an /dev/capi20, der ioctl Aufruf liefert auf dem unter ubuntu22 gebauten Image einen Fehler

[pfichtner]

Was auffällig ist und möglicherweise das Problem darstellt:
crw-rw-rw- 1 root root 68, 0 Nov 30 2021 /dev/capi20 (u20 ok)
crw-r--r-- 1 root root 68, 0 Oct 11 2022 /dev/capi20 (u22 nok)

@fda77 kann das mit der makedevs Änderung zusammenhängen? Wenn dann jedoch die Frage, warum es unter u20 geht und unter u22 nicht.

[fda77]

https://github.com/Freetz-NG/freetz-ng/blob/master/tools/device.table#L93
Das könnte ein fakeroot/pseudo Problem sein

[pfichtner]

Besteht die Chance das Image während des Build-Prozess darauf zu checken und den Build als nicht erfolgreich abbrechen zu lassen?

[pfichtner]

Mit Fakeroot gehts auf Xubuntu 22.10
Pseudo hat nur 644, der Fehler tritt schon beim entpacken auf

Ich nutze fakeroot unter u22.04 (Docker), damit geht's nicht, fakeroot unter u20.04 tut.

[pfichtner]

Mit Fakeroot gehts auf Xubuntu 22.10
[...]
Pseudo hat nur 644, der Fehler tritt schon beim entpacken auf

Das eine scheint keinen Rückschluss auf das andere zuzulassen

clean build unter u22 mit fakeroot, aktuelles freetz-ng 63838a2, alsi auch mit akutalisiertem fakeroot host-rool, Host:

-rw-rw-rw- 1 builduser builduser 0 Nov 30  2021 build/modified/filesystem/dev/capi20
-rw-rw-rw- 1 builduser builduser 0 Nov 30  2021 build/original/filesystem/dev/capi20

FritzBox: allerdings
-rw-rw-rw- 1 root root 0 Nov 30 2021 /dev/capi20
(dem Device fehlt das "c" (character special file), damit starten telefon und dect_manager dann auch nicht.

Mit pseudo sieht es zwar auf dem Host "nicht gut aus" (gleicher commit, gleiches ubuntu für den build)

-rw-r--r-- 1 builduser builduser 0 Nov 30  2021 build/modified/filesystem/dev/capi20
-rw-r--r-- 1 builduser builduser 0 Nov 30  2021 build/original/filesystem/dev/capi20

Dafür aber auf der FritzBox:
crw-rw-rw- 1 root root 68, 0 Nov 30 2021 /dev/capi20

Device sieht also mit pseudo, obwohl es auf dem Host nicht so aussieht, auf der FritzBox selbst gut aus (ist korrekt) und telefon/dect_manager laufen dort dann auch

[fda77]

Ein char-device ist es nur unter dem Fakeroot context, vielleicht sollte man einfach ein "ls" in fwmod einbauen um zu sehen wie es wirklich aussieht

[pfichtner]

Nachtrag, auf u20 sieht es auf dem Host unter fakeroot 1:1 so aus wie unter u22 auch

-rw-rw-rw- 1 builduser builduser 0 Nov 30  2021 build/modified/filesystem/dev/capi20
-rw-rw-rw- 1 builduser builduser 0 Nov 30  2021 build/original/filesystem/dev/capi20

Auch mit pseudo sieht es auf dem Host unter fakeroot 1:1 so aus wie unter u22 auch
-rw-r--r-- 1 builduser builduser 0 Nov 30 2021 build/modified/filesystem/dev/capi20
-rw-r--r-- 1 builduser builduser 0 Nov 30 2021 build/original/filesystem/dev/capi20

Auf der FritzBox sieht es dann mit u20 (im Gegensatz zu u22) bei fakeroot und pseudo Fällen korrekt aus:
crw-rw-rw- 1 root root 68, 0 Nov 30 2021 /dev/capi20

Zusammengefasst:

fakeroot

	host	FritzBox
ubuntu20.04	-rw-rw-rw-	crw-rw-rw- (ok)
ubuntu22.04	-rw-rw-rw-	-rw-rw-rw- (nok)

pseudo

	host	FritzBox
ubuntu20.04	-rw-r--r--	crw-rw-rw- (ok)
ubuntu22.04	-rw-r--r--	crw-rw-rw- (ok)

Bedeutet: pseudo funktioniert sowohl unter u20 als auch u22. fakeroot entpackt zwar auf beiden Systemen identisch, packt aber seltsamerweise unter u22 im Gegensatz zu u20 nicht korrekt, was ja schon verwundert, da es sich beim binary immer um das gleiche binary (host-tool) handelt.

[fda77]

fakeroot entpackt zwar auf beiden Systemen identisch, packt aber seltsamerweise unter u22 im Gegensatz zu u20 nicht korrekt, was ja schon verwundert,

Wenn beide das gleiche wären bräuchten sie nicht verschieden namen...

Eigentlich sollte das auch andere dev-ices betreffen. Es könnte ein Bug in Fakeroot sein, oder ein Patch
zb https://github.com/Freetz-NG/freetz-ng/blob/master/make/host-tools/fakeroot-host/patches/002-also-wrap-stat-library-call.debian.patch

Seems changes in glibc 2.33 caused the stat() function to be mapped into a stat() library call instead of __xstat() as it used to be.

In der 1.31 ist der patch nicht mehr drin: http://ftp.debian.org/debian/pool/main/f/fakeroot/fakeroot_1.31-1.debian.tar.xz
Daher, versuch es doch mal ohne... wie erkennt man denn die Berechtigungen ohne zu flashen?

--

Hast du ./.fakeroot-cache schon entdeckt? Das heisst immer so, egal ob pesudo oder fakeroot. Der Inhalt ist nur leider schlecht lesbar

[pfichtner]

fakeroot entpackt zwar auf beiden Systemen identisch, packt aber seltsamerweise unter u22 im Gegensatz zu u20 nicht korrekt, was ja schon verwundert,

Wenn beide das gleiche wären bräuchten sie nicht verschieden namen...

Ok,dann ist es also logisch, dass sich fakeroot unter u20 und u22 unterschiedlich verhält, denn wenn es sich unter u20 und u22 gleich verhalten würden, bräuchte man ja keine unterschiedlichen Namen? Das Argument ist schon sehr verquer.
Meine Grundanahme ist erstmal, dass sich ein binary auf unterschiedlichen Systemen identisch verhält (und es eben Ausnahmen davon gibt bei denen das nicht so ist).
Wenn ich sage, dass ich erstmal annehme, dass sich ein binary auf A und B gleich verhält, behaupte ich damit dass A und B gleich sind? Ganz sicher nicht!

Eigentlich sollte das auch andere dev-ices betreffen. Es könnte ein Bug in Fakeroot sein, oder ein Patch zb https://github.com/Freetz-NG/freetz-ng/blob/master/make/host-tools/fakeroot-host/patches/002-also-wrap-stat-library-call.debian.patch

Daher, versuch es doch mal ohne...

Schau ich mir mal an

wie erkennt man denn die Berechtigungen ohne zu flashen?

Hast du ./.fakeroot-cache schon entdeckt? Das heisst immer so, egal ob pesudo oder fakeroot. Der Inhalt ist nur leider schlecht lesbar

Ja hatte ich entdeckt. Vor jedem build wurde distclean durchgeführt, das räumt auch den cache ab. Liese sich mit dem cache nicht die Frage nach der "echten" Berechtigung klären? In dem man die cache Dateien anschaut (wäre nicht meine Empfehlung da damit abhängig von internas und damit Verstoß gegen Parnas) oder (meine bevozugte Variante wenn möglich) sowas wie "ls -l" unter fakeroot/pseduo aufrufen, was dann ja auf Basis der Caches die Berechtigung so anzeigen sollte, wie sie auch später im Image landen werden. Dritte Möglichkeit die mir einfällt aber vermutlich die aufwändigste: Abgleich aller/bestimmter Dateien wie sie im Ursprungsimage liegen gegenüber dem Freetz-Image wobei da die Frage wäre: Welche Dateien man abgleichen darf/soll/muss und/oder dabei ignorieren soll/muss weil sie Berechtigungen gegenüber dem Original beabsichtigt ändern sollen.

[fda77]

Ok [..] nicht!

Ist mir zu langatmig, glaub was du willst

Find halt die Ursache des Problems und beheb sie