Br-client_br-client-Kurzschluss? Und wenn ja, wie lokalisieren?

[adorfer]

Auf meinen Knoten bekomme ich neben diversen Pings mit "DUP!" auch noch im Log haufenweise, selbst an "Meshvpn-Hotspots", also nicht nur auf den Gateways.

@RubenKelevra meinte, man könnte evtl dazu wiresharken, um die Schuldigen zu finden.
Ich brauche da etwas Hilfe, gibt vermutlich ein Tutorial, das ich nur nicht erfolgreich ergoogle...

Wed May 11 02:50:07 2016 kern.warn kernel: [ 1134.400000] br-client: received packet on bat0 with own address as source address
Wed May 11 02:50:07 2016 kern.warn kernel: [ 1134.400000] br-client: received packet on bat0 with own address as source address
Wed May 11 02:50:07 2016 kern.warn kernel: [ 1134.410000] br-client: received packet on bat0 with own address as source address
Wed May 11 02:50:07 2016 kern.warn kernel: [ 1134.420000] br-client: received packet on bat0 with own address as source address
Wed May 11 02:50:07 2016 kern.warn kernel: [ 1134.430000] br-client: received packet on bat0 with own address as source address
Wed May 11 02:50:07 2016 kern.warn kernel: [ 1134.430000] br-client: received packet on bat0 with own address as source address
Wed May 11 02:50:07 2016 kern.warn kernel: [ 1134.440000] br-client: received packet on bat0 with own address as source address
Wed May 11 02:50:07 2016 kern.warn kernel: [ 1134.450000] br-client: received packet on bat0 with own address as source address
Wed May 11 02:50:07 2016 kern.warn kernel: [ 1134.460000] br-client: received packet on bat0 with own address as source address
Wed May 11 02:50:07 2016 kern.warn kernel: [ 1134.470000] br-client: received packet on bat0 with own address as source address


Wed May 11 02:53:46 2016 kern.warn kernel: [  118.840000] br-client: received packet on bat0 with own address as source address
Wed May 11 02:53:56 2016 kern.warn kernel: [  128.860000] br-client: received packet on bat0 with own address as source address
Wed May 11 02:54:06 2016 kern.warn kernel: [  138.880000] br-client: received packet on bat0 with own address as source address
Wed May 11 02:54:16 2016 kern.warn kernel: [  148.900000] br-client: received packet on bat0 with own address as source address
Wed May 11 02:58:12 2016 kern.warn kernel: [  158.920000] br-client: received packet on bat0 with own address as source address
Wed May 11 02:58:22 2016 kern.warn kernel: [  168.940000] br-client: received packet on bat0 with own address as source address

[RubenKelevra]

Jap ich schreib was dafür

[fuzzle]

ist dafür nicht die "bla" funktion gedacht ? .. wenn also auf br-client kein batman-adv selbst gesprochen würde, diese aber koppelt.
also an beiden enden "bridge loop avoidance" einschalten.
oder ich habs nicht begriffen, dachte aber spontan daran.

[RubenKelevra]

Hierfür ist BLA gedacht:

Sprich die Gateways sollen einen Client "CLAIMEN" wenn mehrere Routen zum Client hat... was genau damit bezweckt wird erschließt sich mir nicht. Jedenfalls ist BLA von den Bildern her ausschließlich fürs Mesh-Netzwerk gedacht und nicht für das Client-Netz.

Auf dem Client-Netz könnte man Spanning-Tree oder ähnlich sprechen ... aber das würde natürlich Overhead erzeugen - wie BLA vermutlich auch.

Im Normalfall sollte es ja genügen sich über Loops informieren zu lassen, ich schreib grad n Daemon der einmal die Stunde in den Batman-Adv-Traffic schaut ob es einen Loop gibt und dann ne Mail mit den Nachbar-Nodes formatiert hinter denen der Loop auftritt.

Denke das ist die sauberste Lösung, da kein Overhead im Mesh erzeugt wird, sondern nur nach Broadcasts des Gateways im ankommenden Traffic gesucht wird.

LG Ruben

[fuzzle]

batman ist loop frei - wenn man nicht hinter batman (wie oben indem bild, oberer Teil) man Geräte miteinander verbindet die nicht batman sprechen ...
wenn alles batman spricht - ist es eben loopfrei, clients selber sprechen normalerweise kein batman

[Tarnatos]

Ich greife diesen Thread mal wieder auf, denn ich beobachte im Netz ab und zu einen Anstieg der Router/Client Zahl und würde gern verstehen warum.

Siehe: https://statistik.hamburg.freifunk.net/dashboard/db/freifunk-ubersicht?var-region=ffnord

Von @ohrensessel habe ich einen guten batctl Befehl bekommen, der anzeigt welche next-hops wie häufig vorkommen.

batctl -m bat-ffhh o | tr -s ' ' | cut -d" " -f4 | sort | uniq -c | sort

Das ist schon mal sehr praktisch. Danke! Auch wird im syslog/dmesg wohl ein Entrag ähnlich wie "packet with own address as source" abgelegt.. Diesen habe ich leider nicht auf unseren GWs finden können.

Wie lokalisiert ihr "Kurzschlüsse" eurer Netze?

[fuzzle]

du müsstest genauer wissen was da an neuem krempel kommt, sprich ob da jemand client an client (auch bekannt unter gelb an gelb) angeschlossen hat (ohne entsprechende Einstellungen in der Config MoL oder entspr. MoW)
es kann auch sein das hier ein oder zwei anderer communities zugeschaltet werden über fremde router.
du kannst dir mit batadv-vis auch eine logische darstellung des netzes bekommen.
du kannst dann also forschen wo kommen die vielen mehr clients her (batctl tg) oder wo kommen die vielen neuen router/knoten her (batctl o)
ein kurzer blick in den tracedump batctl td lohnt auch oft

[adorfer]

Ich fände es wirklich toll, wenn es dafür eine halbwegs automatisierte Lösung gäbe, um -mit welchem Debugging-Script auch immer- solche "Kurzschluss-Nodes" automatisch aufgelistet zu bekommen.

[MrMM]

Kurzschlüsse mit anderen Communitys lassen sich anhand fremder gw im netzt in der Regel schnell entdecken.

Das ist von der Funktionalität her dann sehr nah am Aachener Segmenter:
https://github.com/ffac/segmenter

Damit lassen sich auch automatisiert fastd keys verschieben.

Freifunk Stuttgart macht etwas ganz ähnliches.

[fuzzle]

@MrMM , clever mit den GW ..und anhand der Route dahin ( batctl tr <GWMAC> ) finde ich dann auch die beiden Brückenden Router.
Das wäre ja dann ein GW das sich in der Regel schlecht erreichen lässt, da die meisten ja dafür sorgen das ihre GW untereinander gut zu erreichen sind.