search

Freetz / freetz

Freetz firmware extension/modification for the ​AVM FRITZ!Box series and devices with identical hardware
https://freetz.org
GNU General Public License v2.0
299 stars 159 forks source link

Kernel Panic nach aktivieren von dnsmasq #261

Open wschleifer opened 4 years ago

wschleifer commented 4 years ago

Hallo,

ich erhalte sporadische kernel panics mit reboot, nachdem ich das DNSmasq paket aktiviert habe.

Weitere user haben ähnliche Probleme: https://github.com/Freetz/freetz/pull/181#discussion_r356280004 https://github.com/Freetz/freetz/pull/181#discussion_r368869487

Was mache ich falsch? Oder ist dies ein bug der behoben werden sollte?

Vielen Dank, Werner.

PeterPawn commented 4 years ago

Du kennst doch offensichtlich die andere Diskussion und Dein Einwurf dort, steht ja nun unmittelbar nach dem Hinweis von @hermann72pb (so heißt er im IPPF) auf den passenden Thread (oder zumindest einen passenden) im IPPF, wo das Problem eingehender untersucht wurde.

Man kann ja in der Historie der Änderungen problemlos nachvollziehen, daß sich seitdem (also seit dem 10.12.2019) an dieser Stelle im "master"-Branch nichts getan hat ... also ja, das ist ein Bug, der behoben werden sollte. Aber das wird er (vermutlich) auch nicht nur deshalb, weil es jetzt eine zweite Fehlermeldung dazu gibt.

Der Workaround (das "Nichtbenutzen" der (reservierten) IPv4-Adressen 192.168.180.1 und 192.168.180.2 für die Upstream-Server im DNS in der Konfiguration des "dnsmasq") ist da ebenfalls angeführt ... und sogar ein Patch von @hermann72pb, mit dem man stattdessen automatisch die vom Provider übermittelten Server (denn nichts anderes verbirgt sich hinter den 192.168.180.{1,2}-Adressen) in die Konfiguration des "dnsmasq" übernehmen kann.

Ich verstehe es ja noch, wenn jemand die Vorarbeiten von anderen gar nicht finden kann (ne, ist auch eher gelogen, paßt aber besser in den Kontext) ... aber hier hätte es ja nur das Lesen der bereits vorhandenen Beiträge in #181 (und erst recht des letzten, der vor dem eigenen steht) gebraucht, damit die Leute sich die Arbeit nicht umsonst gemacht haben.

Das "Tracking" der offenen Probleme funktioniert sicherlich auch ohne Duplikate bei den "Fehlermeldungen" - es hat sich halt noch niemand der Mühe unterzogen, das (abseits des Patches von @hermann72pb im IPPF) in Angriff zu nehmen.

Zumal die Alternativen beim Verwenden anderer Upstream-Server (von DoT- bis DoH-Servern) ja auch immer mehr in den Fokus rücken und die Benutzung der Provider-Angebote an dieser Stelle bei Nutzung von "dnsmasq" eher selten geworden ist (daher sicherlich auch die relativ kleine Schar derer, die das Problem überhaupt haben). Steht ein funktionierender Workaround zur Verfügung (weil man die Ursache des Problems erkannt hat), fehlt logischerweise auch der Druck, das unmittelbar zu korrigieren.

Wenn Du da Deinerseits eine Dringlichkeit sehen solltest, kannst Du ja den passenden PR hier anbieten ... die Diskussion darüber, ob das alles auch wie geplant funktionieren würde (gerade auch in Grenzfällen, denn da treten Fehler eben am häufigsten auf und auch dieser hier ist letztlich ein solcher, wenn man es genau nimmt - denn ohne die Verwendung von 192.168.180.x als Upstream funktioniert das Paket problemlos), kommt dann ganz von alleine und die muß man dann allerdings auch "aushalten" können.

asmcc commented 4 years ago

@PeterPawn hat im Prinzip alles geschildert, wie es momentan um diese Problematik steht. Da ich kein besonderer GitHub-Profi bin und letzte Zeit auch nur sehr wenig Zeit für FREETZ habe, habe ich eine Notlösung mit Peters Hilfe erarbeitet und als Live-Patch in IPPF gepostet. Wer will, kann es bei seiner gefreetzten Box anwenden, ohne in seiner Build-Umgebung wild rumzupatchen und ohne ein neues Image dafür zu bauen (wenn die entsprechenden Pakete natürlich am Board sind). Die Anleitung in IPPF ist eigentlich selbsterklärend und wurde bereits von einigen Nutzern angewendet. Soll heißen: Es ist machbar. Man könnte meine Änderung sicherlich in FREETZ fest integrieren, dies bedarf aber einer grundliegenden Überlegung und Untersuchung. Denn ich hatte die Lösung für meine Bedürfnisse angepasst und getestet. Sie unterstützt zunächst nur IPV4, weil ich IPV6 momentan nicht brauche. Will man beides unterstützen (was die Grundvoraussetzung für eine feste Integration wäre), muss man alle möglichen Kombinationen aus beiden berücksichtigen (z.B. in größeren Städten eine immer mehr verbreitete "Lite DSL" oder wie auch immer dieses Quatsch IPV4 getunnelt über IPV6 heißt), abfangen und dann auch noch testen. Auch das Auslesen der Server funktioniert in der Weise nur seit ein Paar Firmwareversionen, weil AVM da was geändert hat. Auch das muss man abfangen oder zumindest diese Veränderung nur optional für neuere Firmwareversionen erlauben. Und Peter hat Recht: Heutzutage nutzt kaum jemand noch dnsmasq, weil die 0815-Möglichkeiten eines mehr oder weniger vernünftigen DHCP-Servers / DNS von AVM mittlerweile mehr oder weniger gut beherrscht werden. Nur wenn jemand etwas Besonderes damit machen will, greift er zu dnsmasq. Obwohl auch das heutzutage eigentlich umstritten ist. Denn dnsmasq ist auch nur der kleine Bruder von bind, powerdns und wie sie alle in der "richtigen" Linux-Welt heißen mögen.

Hermann