Logread-Meldungen

logread wirft bei mir Mengen der folgenden Meldungen aus:

Oct 30 15:06:54 Spich-Pirat daemon.warn radvd[1444]: RDNSS address 2001:470:20::2 received on br-client from fe80::6be:efff:feca:fe01 is not advertised by us
Oct 30 15:06:54 Spich-Pirat daemon.warn radvd[1444]: DNSSL suffix freifunk-rheinland.net received on br-client from fe80::6be:efff:feca:fe01 is not advertised by us

Ich kann schon nix anderes mehr im Log lesen, weil das Log begrenzt ist.

Hat jemand ne Ahnung, was da los ist und wie man es abstellen kann?

neoraider sagt: ÔÇ×Die Meldungen sind leider normal, die radvd-Version von OpenWrt ist zu alt und warnt vor Dingen, die eigentlich ganz normal sindÔÇŽÔÇť
Ab Gluon 2014.4 (dann mit radvd 2.7) wird das nicht mehr geben.

1 Like

da es sehr viele Meldungen sind (sek├╝ndlich!), kann man den Debug/Errorlevel des radvd nicht herabsetzen?
zB von ÔÇ×warnÔÇť auf ÔÇ×errorÔÇť?
wenn ja, wie?

Daf├╝r musst du Radvd im Source f├╝r anpassen und neu Compilen. Das ist leider keine Config-Option :frowning:

k├Ânnt ihr das bitte f├╝r das n├Ąchste Release (2014.3.1) vorsehen? Danke :wink:

Wie adorfer schon sagte ist es erst ab Gluon 2014.4 gefixt da wir Radvd nicht von der neuen OpenWRT Version backporten. :smile:

@CyrusFox Ich glaube Rekas Frage ging eher in die Richtung, ob man im Build-Prozess f├╝r die n├Ąchsten Images den Loglevel f├╝r radvd nicht geringer einstellen k├Ânnte.

Nicht ohne es vorher ausgiebig zu testen, da gerade Gluon 2013.3.1 bei uns beim internen Testing ist wird es nicht mehr rein kommen.
Features & Bugfixes m├╝ssen mindestens 4~ Wochen vorher dazukommen es sei denn es ist etwas kritisches.

warum treten diese Meldungen nur in Rheinufer auf und nie (!) in Ruhrgebiet?

logread gibt gerade mal Logs von 2,5 Minuten aus, weil alles mit diesen sinnlosen Meldungen voll ist!

Weil ich dnssl im Ruhrgebiet ├╝berhaupt nicht ├╝bertrage.

Um dem rdnss auf den Grund zu gehen m├╝sste ich die radvd Config vom Rheinufer sehen.

zu dnssl: wozu wird es in Rheinufer ├╝bertragen?

zu rdnss: meinst du die Config /etc/config/radvd auf den Notes oder die auf den Supernodes?
/etc/config/radvd ist auf meinen Nodes in beiden Dom├Ąnen identisch.

dnssl nennt den Nodes eine Suchdomain/Basisdomain, wozu das genutzt werden soll kann ich Dir leider nicht beantwortenÔÇŽ

Alles zentral auf dem radvd der Supernodes, hat mit den lokalen Nodes nichts zu tun, die sind lediglich Empf├Ąnger der Rundsendungen!

Das ist daf├╝r gut, wenn du z.b. ping proxy eingibst.
Dein system versucht dann zuerst den Namen proxy ├╝ber die host und anschlie├čend ├╝ber den Nameserver aufzul├Âsen.
Funktioniert das nicht versucht er das nocheinmal mit der in der search list angegeben Domains.
z.B. proxy.freifunk.net (wenn freifunk.net so ├╝bergeben wurde)

P.S. sowas gibts sogar unter Windows :smiley:

Gru├č
Thomas

aber auf einem Node brauche ich das nicht!
In site.conf sind alle Hosts mit FQDN angegeben.
Und wenn man Mal einen Supernode anpingen will, kann man die Domain dazuschreiben.
Ich mache sowas eh immer auf dem Client und da habe ich die Searchdomains nach belieben konfiguriert.

Also lasst uns dnssl in Rheinufer abschalten und 50% des Logm├╝lls einsparen!

Wer konfiguriert denn den radvd auf den Supernodes? @nomaster?
Und bei der Gelegenheit kann man mal die Config mit der von @CHRlS vergleichen :wink:

Was es macht ist denke ich schon klar, aber wof├╝r das im Rheinufer gesetzt ist wei├č ich dennoch nicht.

Im Alltag eher eine Option die man im Intranet ├╝bertr├Ągt, statt in einem ├Âffentlichen Netz!?

Ne, haste schon recht.
Zumal ein normaler Anwender das sicherlich nicht nutzen (wissen) w├╝rde.
Wir haben ja auch keine Dienste im FF wo man es nutzen k├Ânnte, vielleicht bis auf dieses Forum :smiley:

Gru├č
Thomas

und dieses Forum liest du nicht auf dem Node, sondern auf nem Client dahinter. Aber bis dahin wird die Search-Domain nicht propagiert.

jetzt ist noch eine dritte radvd-Meldung hinzugekommen, die alle 3-4 sec das Log vollm├╝llt:

Dec  3 17:41:29 TDF-Spich-Pirat daemon.warn radvd[1449]: our AdvPreferredLifetime on br-client for fda0:747e:ab29:cafe:: doesn't agree with fe80::6be:efff:feca:fe00