Logread-Meldungen

Technik Rheinufer
1

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?

2

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 „Gefällt mir“
4

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?

5

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

6

könnt ihr das bitte für das nächste Release (2014.3.1) vorsehen? Danke :wink:

7

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

8

@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.

9

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.

10

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!

11

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.

12

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.

13

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!

14

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

15

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:

16

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!?

17

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

18

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

19

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