[Berlin-wireless] SmartGateWay...?

Philipp Borgers borgers
So Jan 25 23:20:39 CET 2015


On Sun, Jan 25, 2015 at 11:01:54PM +0100, Bastian wrote:
> On 01/25/2015 10:58 PM, Philipp Borgers wrote:
> > On Sun, Jan 25, 2015 at 10:50:36PM +0100, Bastian wrote:
> >> Nochmal von vorne:
> >>
> >> Das JUP hat alles was SmartGateway betrifft deaktiviert. Kein Plan was
> >> samoa4-core für Einstellungen hat.
> >>
> >> Das JUP sucht ganz normal wie jeder andere OLSR-Knoten den nächsten Node
> >> der ein HNA nach 0.0.0.0/0 ausstrahlt. Nur eben ohne SmartGW. Wir nehmen
> >> in OLSR an, dass nur Knoten mit echtem eigenen Internet-Anschluss ein
> >> default-HNA verkünden oder wenigstens eine "bessere" Route über ein
> >> weiteres Interface ins Internet hat.
> >>
> >> Vom JUP aus ist der nächste Knoten mit HNA nach 0.0.0.0/0 samoa4-core.
> >> Für JUP-Core ist der Weg ins Internet laut traceroute:
> >> JUP->Beuth->Samoa->F2A
> >> da ich mir aber ziemlich sicher bin, dass es keine echte physikalische
> >> Verbindung Samoa<->F2A gibt, ist dieser Weg einfach falsch. Ich denke
> >> richtiger ist also momentan folgender Weg, der im Traceroute aber nicht
> >> auftaucht:
> >> JUP->Beuth->Samoa->Beuth-Segen->F2A
> >>
> >> Vom JUP aus zu F2A muss nicht 2x über Beuth und zwischendrin über samoa4.
> >> JUP->Beuth->Segen->F2A geht auch.
> >>
> >> Ich kenne nur eine Sache die gerne wild Tunnel im Mesh gräbt, und das
> >> ist dieses SmartGW-Plugin. Solange das keinen Einfluss auf das reguläre
> >> OLSR hat, ist mir das auch egal. Aber gerade führt das zu 2 unnötigen
> >> Hops. Und mit Verlaub, that's just wrong.
> >>
> >> tl;dr
> >> Ich vermute ein SmartGW-Client tut für das restliche OLSR-Mesh so als
> >> wäre es ein SmartGW-"Server" mit eigenem Internet-Anschluss aka
> >> 0.0.0.0/0-HNA. Das sorgt für Routing-Fuckups.
> >> Ist das eine Fehlkonfiguration, oder default in der kathleen-Firmware?
> > 
> > Warum vermutest du das?
> 
> Meine Vermutung basiert auf den Traceroutes zur ersten Mail dieses
> Threads und der oben-stehenden Analyse.

Ich vermute das Problem liegt nicht am SmartGW-Client.

Der Client announced seinen Tunnel zum Gateway nicht nochmals. Eine
Node announced ein Gateway nur, wenn das VPN über den WAN-Port läuft
und der VPN-Server pingbar ist.

Ich denke wir brauchen mehr Informationen.

> >> Gruß
> >> Bastian
> >>
> >> On 01/25/2015 10:18 PM, Faustus wrote:
> >>> Habt Ihr denn Smartgateway konfiguriert? Packt da doch mal ein
> >>> SmartGatewayThreshold '50' rein - samoa4-core sollte dann z.B.
> >>> bei tub-core landen. Auf dem Tberg klappt das recht prima.
> >>>
> >>> Grüße
> >>> Faustus
> >>>
> >>> On Sun, Jan 25, 2015 at 06:05:14PM +0100, Bastian wrote:
> >>>> Nein - das hat IMHO auch gar nix mit Client-Isolation zu tun, sondern
> >>>> mit HNA nach 0.0.0.0/0 von einem Knoten der selbst nicht online ist.
> >>>>
> >>>> Mich interessiert gerade nur, ob der SmartGW dieses Verhalten im Routing
> >>>> erzeugt und ob das so gewünscht ist. Weil meiner Meinung nach  schon
> >>>> eine konkrete Verschlechterung im Routing darstellt.
> >>>>
> >>>> Gruß
> >>>> Bastian
> >>>>
> >>>> On 01/25/2015 06:01 PM, Faustus wrote:
> >>>>> Ja - Client-Isolation ist angeschaltet. 
> >>>>>
> >>>>> @Bastian: Haben wir hier das selbe Problem wie auch auf
> >>>>> mabb-rt1/l9-core/jupp-core? Auf tub-core entdecke ich noch keine
> >>>>> Fehler.
> >>>>>
> >>>>> Grüße
> >>>>> Faustus
> >>>>>
> >>>>>
> >>>>> On Sun, Jan 25, 2015 at 10:36:29AM +0100, Justus Beyer wrote:
> >>>>>>
> >>>>>>> Am 24.01.2015 um 23:54 schrieb Bastian <fly at d00m.org>:
> >>>>>>>
> >>>>>>> Schön und gut, aber samoa4-core hat meines Wissens keine
> >>>>>>> direkte Verbindung zu f2a
> >>>>>> Und da hast du Recht.
> >>>>>>
> >>>>>> Harald/Faustus: Habt ihr die Client-Isolation schon in den Griff bekommen - bzw kommt die als Ursache überhaupt infrage?
> >>>>>>
> >>>>>> Gruß
> >>>>>> Justus
> >>>>
> 
> 
> 



> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20150125/01c8b7d3/attachment.pgp>



Mehr Informationen über die Mailingliste Berlin