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