ARP Lookup Probleme auf Supernode (BatmanAdv legacy / 2013)

Hi,

ich wollte mal fragen ob hier wer schonmal „ARP lookup“ probleme auf Supernodes bzw. innerhalb des Freifunk Netzes gesehen hat?

Gruß
Thomas

Einzelne Nodes, die nicht über das Gateway „hinauskommen“ nach draußen, also die WorldIP des Gateways nicht erreichen können aber alles innerhalb des Netzes?
Ja!

Degradendes Netz auf Grund von Nmap-Subnet-Scans (simpler ping auf /16) mit entsprechenden Arp-Stürmen in der Domain: Ja!

Arpstürme durch nicht als IPv6 eingetragene Timeserver und Updatedate-Server, die aber offline sind: Ja!

Oder anders gesagt: Was schwebt Dir denn als Arp-Problem vor?

(Von Arpspoofing durch Spielkinder spreche ich schon gar nimmer.)

Ja ich versuche das gerade einzugrenzen. Was ich sehen konnte ist folgendes.

Ein supernode bekommt meinen Testrechner die aufgelösst.
Der Client an sich erreicht aber den supernode nur die Replys gehen halt nicht zurück
Die anderen Supernodes sind auch erreichbar.

Ich suche halt offenbar gerade einen Fehler auf diesem expliziten Supernode.

Prinzipiell sehe ich aber auch keine Probleme im Batman. Alle Gateway sind sichtbar im Batman. Werde ich wohl mal tiefer wühlen müssen

Nicht zufällig Batman2014, oder?

B.A.T.M.A.N. adv 2013.4.0-27-ga570bc6-dirty.

scheint aber tatsächlich nur ein supernode betroffen zu sein. bestimmt irgendwelcher Konfigurations foo.
prinzipiell geht aber batman aber.
Interessant ist das ich Fehlermeldungen bekomme sobalt ich einen anderen sn anpinge

Error - can’t write to batman adv kernel file ‚/sys/kernel/debug//batman_adv/bat0-niers/socket‘

Ich werde das Batman glaube ich mal neu Kompilieren. Mal sehen ob das was hilft.

Im „alten“ Ruhrgebiet hatte ich das von Dir beschriebene Verhalten mehrmals. Seit Umstellung auf den aktuelleren Batman ist es nicht wieder aufgetreten.

was heißt aktuellen batman? 2016?

2015er reicht vollkommen. Es hat sich hartnäckig meinen Debugging-Versuchen entzogen, da waren Nodes, die schlicht „Pech“ hatten und über den einen Supernode nicht herauskamen, alle anderen schon.
Man konnte vom Knoten den Supernode noch nichtmal per V4 pingen (wäre ja default-gateway gewesen.)
Knoten rebooten oder Supernode rebooten…

Ach ne du lass mal. Noch eine Baustelle will ich jetzt nicht aufmachen :smiley:

Ja. Jüngst aufgefallen, Symptom z. B. daß ein Client von einem zum anderen Knoten nicht roamen kann. Lustigerweise sehe ich dhcp-Anfragen durchgereicht (wir nutzen dhcrelay auf den GWs auf einen zentralen dhcpd), aber dennoch haben die GWs die MAC zu der IP z. T. nicht und ping schlägt fehl.

In batman ist alles schnieke, tr/ping tut. Aber das Linux obendrüber hat Probleme mit der Erreichbarkeit.

batman 2013.4.0-10

Haste mal ein Batman Ping probiert. Bei mir geht der schon nicht. Weil das ja ein arp Problem ist auf Layer 2.

Mein Problem sollte ersteinmal nichts mit dem Linux an sich zu tun haben.

Ich sehe auch noch andere Problem wo Batman rumjammert. Ich werde mal eine ältere Version von Batman die Tage probieren. Solange das Problem nicht gefixed ist habe ich meinen supernodes erstmal aus dem Verkehr gezogen :slight_smile: bringt ja so nichts

Wir konnten das bislang nicht auf einen (der 3) Gateways reduzieren, es scheint sporadisch generell aufzutreten. batctl tr tat zuletzt, ping nicht. Aktuell, Zeit ist der limitierende Faktor, wird versucht, eine »Labor-Umbegung« aufzubauen, mit räumlich getrennten APs (um Roaming/Handover zu forcieren), die an gleichen bzw. unterschiedlichen GWs hängen, und dann ein Testszenario zu spezifizieren. Verstehen tue ich es nicht, und es ist (leider) auch kein Dauerzustand, zeitweise geht’s, zeitweise nicht :frowning:

Wir haben mit dem legacy-BatmanAdv (2013/2014?) in „ffrg“-Zeiten gefühlt Tage und Wochen damit verbracht, die Fehler nachzustellen. Und wenn sie da waren, dann konnten wir sagen:
„Ja, auf dem Supernode läuft irgendwas schief, der hat wohl defekte Tabellen. Er forwarded zwar den Batman-Traffic „transit“, aber über sei Gateway lässt er nix raus. Für diesen einen einzigen Node. So als ob der Node für’s Gateway auf einer Blacklist stünde.“

Mit dieser Erkenntnis haben wir jedoch nichts tun können ausser zu sagen: Muss man den Supernode wohl mal neu starten…
Oder den Node. Eines von beiden half schon. Vermutlich ein beschädigter Tabelleneintrag… in einer vielen Batman-Tabellen…
Und wie erläutert: Nach Wechsel auf den 2015er-Batman war’s dann verschwunden und wurde nie wieder beobachtet. (Dafür gab es da dann neue, nicht minder blöde Fehler.)

Eben. Irgendwie ist batman_adv gefühlt am Ende der Nützlichkeit angelangt (ein Strauß nie gefixter Bugs). Zeit, sich nach LibreMesh.org-Konzepten umzusehen, um batman_adv auf das notwendige Maß zu reduzieren.

Bei mir hat in der Tat nur eine ältere Batman Version geholfen.