[Problem] Nach Update auf FOS 7.50 startet der AVM-DSLD nicht und ein root-login per telnet ist nicht möglich

WileC

Mitglied
Mitglied seit
28 Nov 2007
Beiträge
395
Punkte für Reaktionen
13
Punkte
18
Hallo liebes Forum,

ich habe nun meine FritzBox 7590ax von FOS 07.31 rev94867 mit Freetz ng-21399-c60751263 auf das nagelneue FOS 07.50 rev104313 mit Freetz ng-21444-c555c980a per Freetz-WebIf geupdatet.

Nach dem Update und dem automatischen Neustart der Box startet der AVM-DSLD nicht. Es findet zwar ein Sync mit der DSL-Leitung statt, die Power-LED leuchtet dauerhaft, aber eine Internetverbindung wird nicht aufgebaut.

Des Weiteren ist ein Login als "root" über Telnet nicht möglich, mit Dropbear allerdings schon.

Nach einem weiteren, manuellen reboot der FritzBox startet auch der AVM-DSLD automatisch und die Fritzbox verbindet sich wie gewohnt per IPv4 und IPv4 per DSL.

Ein Login als root ist per Telnet aber immer noch nicht möglich, per Dropbear schon.

Hat jemand ein ähnliches Phänomen und evtl. einen Lösungsgedanken?

Nachdem ich kein hochsensibles Datennetzwerk habe und nur aus dem lokalen Netz auf die FritzBox zugreife, wäre ein reiner Telnet-Zugang vollkommen ausreichend.

Vielen Dank schon mal.
 
Aber was spricht denn gegen den Zgriff per Dropbear aus den lokalen Netz?
Oder geht es Dir um die Klärung der Zusammenhänge, warum der telnet-Zgriff nicht funktioniert?
 
@Micha0815
Danke, aber damit aktiviere ich dich den Telnetdienst oder?! Der läuft ja schon…

@FischersFreetz
gegen dropbear spricht eigentlich nichts. Er braucht nur mehr Speicher als der telnetd. Und ist meiner Meinung nach „Zuviel“ für den lokalen Zugriff.

Aber die Zusammenhänge würden mich auch interessieren.

Zumal der telnetd bei mir über den inetd gestartet wird und „replace ar7login“ ausgewählt ist.

Sowohl in der /etc/passwd als auch in der /etc/shadow ist der Benutzer „root“ vorhanden. Allerdings lediglich in der /etc/shadow ist ein Passwort hinterlegt.

Edit:
Hinsichtlich des AVM-DSLD ist mir noch aufgefallen, dass wenn ich neue VPN-Verbindungen, egal ob IPSec oder WireGuard, erstelle, der AVM-DSLD gestoppt, aber nicht wieder gestartet wird. Könnte das vielleicht irgendwo an der rc.dsld liegen? Oder habe ich hier den ganz falschen Denkansatz?
 
Zuletzt bearbeitet:
Also heißt es das man die Box nach dem Update noch mal Starten sollte, somit das er wieder ein Connect aufbauen kann wegen AVM-DSLD.

Hatte noch nie Telnet aktiv in der 7530AX und da habe ich es mal getestet. Da läuft es ohne probs

Edit
Mit 21428-12b53406d ging es noch.
Code:
FritzOS 07.50 rev104313 (23.03.2023 13:15:26)
Freetz ng-21428-12b53406d (31.03.2023 01:13:35)
Edit 2
also kann doch nur wo ein fehler drin sein zwischen
und

Edit3
So ich habe was an mein Freetz geändert und nun läuft es gleich nach dem Reboot
Freetz ng-21547-2e5218d5b (21.04.2023 17:31:29)
 
Zuletzt bearbeitet:
  • Like
Reaktionen: WileC
@Master SaMMy … und was hast du an Deinem Freetz geändert?
 
  • Like
Reaktionen: heimi666
@Master SaMMy : ja das wäre mal interessant: Läuf nun 2e5218d oder hast Du da noch was dran geändert?

Ich hab fast exakt den gleichen Fehler aufeiner 6660 wie WileC: dlsd läuft nicht nach update, geht aber nach reboot, bis irgenwas an betimmten Einstzellungen geändert wird (VPN hinzufügen, IPv6 Einstellungen) -- Ip neu Verbinden zb geht aber.
Irgendwas stoppt den und startet den nicht wieder neu. Wenn ich den in der CLI zu fuss starte ("dsld -i -n"), ist Internet sofort wieder da.
Das Verhalten hab ich in a0a7c1a und 3d5598f, aber
git show 12b5340..c555c98 liefert nichts wesentliches.
12b53406 war ja noch gegen 7.3x oder Labor .50...
7.50 release wurde erst am 04.04 in NG committed.

Ich hab ähnliche Probleme auch mit dem chronyd
 
Ja nur was hast Du geändert? Läuf git 2e5218d ? oder hast Du noch manuell gepatcht?
 
Das Problem mit „chronyd“ könnte sich aus der mangelnden IP-Konnektivität ergeben. Ohne Internet, keine Zeitsynchronisation. Logisch betrachtet bringt’s ja nix, wenn der ntp-Dienst versucht, sich ohne Internet-Verbindung die aktuelle Zwit zu holen :)

Ich habe aber im Log gesehen… die Kernel-Meldungen haben einen Zeitversatz von genau +2 Stunden zur Systemzeit.

Ich denke, es hängt alles in allem irgendwie mit dem „multid“ zusammen.
 
Ich hab jetzt 2e5218d5b gebaut:
socat compiled nicht wegen Ecurve (das ist aber in neueren version gefixt)

nach flash: dnsmasq ok, kein dsl, kein chrony
nach reboot: dnsmasq ok, dsl ok, chrony ok
nach stromaus: dnsmasq ok, dsl ok, chrony ok
"neu verbinden": dnsmasq ok, dsl ok, chrony ok

Ich kann gut damit leben, wenn nur neu configurationen (zb vpn) den dsld schreddern.
 
Ich hatte erst den Assistenten in Verdacht, aber der kommt ja nicht wenn schon auf 7.50 bist. Ich werd das mal weiter beobachten, wichtig ist die Version ist reboot und Stromausfall- fest . Ich muss ohnehin noch mal updaten weil das socat nicht lief. curl hat noch das reloc 0x2a issue, aber wget funkt mit gnutls statt openssl. socat ist auch ein openssl reloc 0x2a Kandidat leider.
 
Es könnte allerdings auch irgendwo ein kleines Problem beim DSLD oder den diesbezüglichen Services bzw. Skripten geben…

Der DSLD startet bei mir auch nicht neu, wenn ich an der VPN-Konfiguration etwas ändere. Egal ob es IPSec-VPN oder WireGuard ist…

Und das tritt bei mir erst ab FOS 7.50 auf.

Allerdings habe ich das aktuellste freetz-ng noch nicht mit FOS 7.29 bzw. 7.31 getestet. Ob’s da auch Probleme mit dem DSLD gibt.
 
7530ax ebenfalls bestätigt. Nach kaltstart startet der dsld einmalig, sobald Änderungen in den Einstellungen gemacht werden, die einen reload des dsld betreffen, bleibt dieser Down in der aktuellen Labor. Da wird im "Freetz-Insert" bei "svctl" bzw. beim supervisor noch irgend eine Kollision wahrscheinlich sein, bzw. ist der Umfang der
Dienste im Vergleich zu den 7.29/7.31-Versionen evtl. gestiegen und freetz benötigt hier noch eine weitere Anpassung.
 
Also entgegen der Antwort von fda77 in den Diskussionen ums Thema auf Github, mögen bestimmt Fehler durch externe Addons oder externer Skripte ursächlich sein...

Aber: ich nutze keine externen Quellen. Einen "originalen" freetz-ng checkout mit blanker neu eigenstellter config ... und hier tritt eben o.g. Fehler auf...
 
Ich tippe mal auf die neuen zusätzlichen Daemons und auf svctl/supervisor, das es da jetzt etwas mit der Reihenfolge bei den restarts/reloads zu tun...

ggfs. müsste der dsld nach config-Änderungen jetzt entweder früher oder später jetzt restartet werden da wohl die neueren Dienste auch noch initialisiert werden müssen:

Da heisst es serielle soncole/syslog und dann im WebIF von AVM mal config Optionen ändern, Portforwardings machen, am Zugang ipv6 was ändern. Also irgend was umconfen wo der dsld daemon zumindest einen neustart braucht. Da sollte das consolen-log ggfs. einen Hinweis liefern wieso das restarten fehlt schlägt und ob der daemon ueberhaupt noch mal restaret wird.

Kann auch gut eine systemd-dependanciy sein, die noch nicht aufgelöst wurde und das ebenso den restart verhindern kann ?
 
  • Like
Reaktionen: WileC
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.