schoen waere, wenn Du eine Idee haettest, wer die Meldung auswirft. das sind nicht vielleicht noch mehr Meldungen, die einen Prozessnamen mit auswerfen ? Aber das wuerde auch Leuten, die von OLSR Ahnung haben vllt weiterhelfen.
Davon habe Ich keine Ahnung, aber der klassische Einsatz des bind ist die Bekanntgabe ans Kernel, dass ein Prozess an einem NW-Socket horchen moechte und dazu einen Parametersatz wie
AFINET, IPv4, Port 22, INADDRANY
uebergibt, sodass das Kernel entscheiden kann, welche Libraries, Sockets und Netzwerkinterfaces in Frage kommen. Hierbei bedeutet INADDRANY mir ist egal wo der v4 Request an port 22 reinkommt, ich horche ueberall. Das kann man aber genauer spezifizieren, in dem man explizit Adressvorgaben macht. Die kritische Anwendung soll moeglicherweise nicht am Internetport horchen.
Wenn die Adressvorgaben nicht mit der aktuellen NW Config in Einklang zu bringen sind, dann steht das Kernel dumm da und gibt eine Errorcondition an den Aufrufer von bind(2), der dann diese Meldung auswirft.
Es kann sein, dass irgendwo Adressen drin stehen, die es nicht gibt. zB /etc/hosts wenn ein Name verwendet wird und der auf eine grottige Adresse abgebildet wird.
Ich wuerde aber auch alle kritischen Files auf moegliche (unsichtbare) Schmierzeichen untersuchen, das defacto einen Syntaxfehler bedeutet und resultierend der Prozess dann auch Muell an den bind uebergibt.
Das ist glaube ich das einzige, was man so vom gruenen Tisch ohne Kenntnis der Firmware empfehlen kann. Und natuerlich im Netz suchen… aber evtl ergeben sich aus meinem Hinweis weitere Suchmoeglichkeiten. Du kannst mein Geschreibsel auch gerne den Berlinern(?) weitergeben. Manches kommt ja halt auch bei Praktikern nie vor. Aber die wissen dann besser, wo sie suchen koennen.
Huhu, vielen Dank für Deine Erläuterungen. Ich könnte mir
vorstellen, beim allgemeinen Stochern im Nebel, dass IPv6 das
Problem war. Mittlerweile ist die Meldung nämlich wegegangen,
nachdem ich etwas an der config geschraubt habe.