[Berlin-wireless] nochmal: OLSR-Verbindung über Kabel steht aber DNS, ping und Co. gehen nicht drüber

Fr Jun 5 13:09:00 CEST 2015

> Gesendet: Freitag, 05. Juni 2015 um 02:09 Uhr
> Von: anha4 at web.de
> An: berlin at berlin.freifunk.net
> Betreff: Re: [Berlin-wireless] nochmal: OLSR-Verbindung über Kabel steht aber DNS, ping und Co. gehen nicht drüber
>
> Hallo, ja, von mir aus gesehen sah das heut genauso aus. Ich komme auf TSB1,
> aber nicht auf TSB2. Die Kabelkopplung geht nicht.

genau, zumindest nicht so wie sie sollte. Der TSB2, wenn er funk-mesht geht ja tadellos, nur
wenn er mit dem TSB1 kabelmesht kann er zwar Daten rausschicken (z.B. ans Monitoring) bekommt
aber keine zurück. Also stellt ihm der TSB1 die entweder nicht durch oder er erkennt sie 
nicht als für ihn gedacht (oder beides). 

> Der Grund dafuer ist vermutlich, dass du die IP 10.230.44.105, die fuer die Kabelkopplung 
> vorgesehen ist, fuer die Funkverbindung zum Zoofenster nutzt. Dafuer ist sie nicht vorgesehen, 
> sondern ausschliesslich fuer die Kabelkopplung. Fuer die Verbindung zum Zoofenster kannst du 
> eine beliebige (registrierte) IP aus dem 10.31.x.x - Bereich nehmen. Die IP 10.230.44.105 
> und die IP 10.230.44.106 bleiben ausschliesslich der Kabelkopplung vorbehalten. Dann nach 
> dem Strickmuster, das ich schon beschrieben hatte, dann klappt das auch. Jetzt trifft 
> IP 10.230.44.106 (LAN NSM5) auf IP 10.31.14.17 (WAN WDR 4200), sollte aber auf 
> 10.230.44.105 treffen. Wuerde mich mal interessieren, welche Netzwerkmaske hast du denn 
> da jetzt auf LAN NSM5 und WAN WDR4200 eingetragen?

Sorry, das verstehe ich nicht:

Ich habe für den TSB1 die mesh-IPs  * 10.230.44.104/30 erhalten. Nach meinem Verständnis
sind das zwei mesh-Adressen (105 und 106), die beide auf den TSB1 gehören und nicht an die beiden
Enden einer mesh-Verbindung, also je eine für je eine der beiden Mesh-Schnittstellen des TSB1.
Die ...105 mesht ja auch völlig korrekt mit dem Zoofenster 
(obwohl sie nicht in den 10.31.-Raum gehört) und pings vom TSB1 gehen durch.

Warum sollte die 10.230.44.106 erwarten, *an der Gegenstelle* auf 10.230.44.105 zu treffen?
Sie muss doch mit der IP meschen können, die die Gegenstelle eben hat, ohne diese vorher 
zu kennen oder eine bestimmte IP zu erwarten, sonst könnte das Gerät ja nicht mit "jedermann"
 meshen, sonderrn nur mit einem fest eingesellten Partner, den die IP-Vegabe vorgesehen hat?

Für den TSB2 habe ich drei mesh-IPs erhalten,  * 10.31.14.15  * 10.31.14.16  und  
* 10.31.14.17  (optional - für LAN Meshing), die zu den drei mesh-Schnittstellen des TSB2 
gehören und so auch zugeordnet sind.

In den Zuordnungen der mesh-IPs zu den Schnittstellen steht auf sämtlichen Mesh-Schnitt-
stellen aller Geräte immer genau die IP der Schnittstelle und die Netzmaske 255.255.255.255,
so wie es das Konfigurationsinterface für die Funk-mesh-Schnittstellen auch eingerichtet hat.
Gateway, Broadcast, DNS usw. sind bei sämtlichen mesh-Schnittstellen nicht eingetragen. Der
OLSR-Statusbeicht erkennt auf beiden Geräten die Kabel.mesh des Paertner auch korrekt als
Nachbarn. Nur dass eben keine TCP, UDP oder ICMP-Päckchen über die Verbindung gehen.

> Secondary LAN NSM5 brauchst du nicht. 
Ob brauchen oder nicht: Genau auf die habe ich aber im Switch-Menu das vlan eth0.2 gelegt,
an das die Kabelmesh-Schnittstelle gekoppelt ist und die Signale, mit denen OLSR seine 
Nachbarn erkennt töpfeln da jetzt auch durch.

Gruesse Andreas
> 
> > Gesendet: Donnerstag, 04. Juni 2015 um 19:24 Uhr
> 
> >
> > Hallo,
> > 
> > immer noch das selbe Problem mit dem Kabelmesh: OLSR geht übers Kabel im Prinzip, erkennbar daran, dass beide Router sich gegenseitig als Nachbarn anzeigen und und der Router, der nur am Kabel hängt auch andere OLSR-Knoten anzeigt.
> > Daten kriege ich leider immer noch nicht überr die Verbindung.
> > 
> > Nochmal der Aufbau:
> > 
> > Zoofenster
> > |
> > | Funk-mesh, funktioniert tadellos
> > |
> > Host TSB 1
> > mesht mit IP 10.230.44.105 über Schnittstelle wwan (=Luft) mit Zoofenster (ch108)
> > mesht mit IP 10.230.44.106 über Schnittstelle WAN (=etho.2="secondary"-Buchse, Kabel) mit TSB2
> > |
> > | Kabel-Mesh
> > |
> > Host TSB2
> > mesht mit IP 10.31.14.17 über Schnittstelle KABELMESH (=physikalisch eth0.3=4.gelbe Buchse, Kabel) mit TSB1
> > hält über die IS 10.31.13.15 und 16 meshing an wireless0 vor, mesht aber mit niemandem (konnte das gestern in der c-base aber)
> > bietet an br-dhcp DHCP für die drei übrigen gelben Buchsen und die beiden Funkschnittstellen das Netz 10.230.83.224/27 an (Clients kommen auch rein)
> > 
> > So weit so gut.
> > 
> > 
> > 
> > Das Problem:
> > 
> > Auf TSB1 funktioniert ein ping aus dem Managementinterface (Netzwerk | Diagnosen)
> > Auf TSB2 kommt funktioniert das nicht. Gestern aben, als er außer dem Kabel zu TSB1 auch über Funk mit den Routern in der c-base meshen konnte, ging es tadellos, der Fehler muss also irgendwo im Kabelmeshing stecken. Nur finde ich ich ihn nicht.
> > 
> > Jemand noch eine Idee, wo ich suchen könnte oder was ich da zerkonfiguriert habe?
> > 
> > 
> > 
> > 
> > Mehr Input:
> > 
> > Firewall ist auf beiden deaktiviert.
> > OLSR-Dämon ist auch an die richtigen Schnittstellen gebunden. Den Schnittstellen ist ihre IP und die Maske 255.255.255.255 zugewiesen aber weder ein gateway noch ein broadcast noch ein DNS.
> > Beide Router tauchen im Monitoring auf, schaffen es also offensichtlich, Daten dort hinzusenden, der TSB bekommt aber bei ping und co. offenbar keine zurück.
> > 
> > Auf TSB1 zeigt Status | Routen unter ARP korrekt aufgelöst die IPs der beiden mesh-Nachbarn an, außerdem einen Riesenhaufen IPv4- Routen zwischen wwan und dem Gateway 10.31.0.166 (das ist das Zoofenster) an, außerdem korrekt die Route von wan zum DHCP-Netz des TSB2 samt dessen Kabelmesh-IP als Gateway. Bei der OLSRD-Konfiguration (Dienste | OLSR IPv4) ist unter HNA nichts eingetragen.
> > 
> > Der TSB2 zeigt unter Status | Routen unter ARP wieder korrekt aufgelöst die Mesh-IP des TSB1 und außerdem die Route zu sich selber für sein DHCP-Netz an. Unter "aktive IPv4-Routen" sieht es aber mau aus: Da zeigt er mit der Gatewayangabe 0.0.0.0 die Route zu seinem eigenen DHCP-Netz an, aber sonst nichts. Bei der OSLRD-Konfiguration ist unter HNA das DHCP-Netz eingetragen, das er anbinden soll.
> > 
> > Und noch etwas möglicherweise seltsames:
> > Wenn ich mir auf dem TSB1, der am Zoofenster hängt, die Einträge unter Status | OLSR | HNA ansehe und nach dem DHCP-Netz suche, das der TSB2 anbieten soll, dann wird als Gateway zu 10.230.83.224/27 die mesh-IP angezeigt, die am TSB2 auf der wireless0 liegt (...105), nicht aber die beiden anderen (...106 und ...107). Ob das seine Richtigkeit hat, kann ich nicht beurteilen. Der TSB2 zeigt im selben Menupunkt sein eigenes DHCP-Netz nicht an, das mag aber auch seine Richtigkeit haben, weil er da hin ja kein Gateway braucht.
> > 
> > 
> > Danke
> > 
> > Christian
> > 
> > _______________________________________________
> > Berlin mailing list
> > Berlin at berlin.freifunk.net
> > http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> >
> 
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
>