Hi,
ich bin nur gerade darüber gestolpert und es ist vielleicht eine blöde Anfängerfrage, aber da es bei Freifunk ja auch um Wissensaufbau geht… äh… Was ist denn das für ein Gateway?
Das Ding hat irgendwie permanent nur einen Client und hängt trotzdem per VPN an
den „üblichen“ Gateways.
Kann mir das jemand erklären, was der technische Hintergrund ist? Oder ist das einfach ein Anzeigefehler?
Gruß
Andreas
Vielleicht irgendein Router im Keller, der als Offloader benutzt wird, da er mesht, wird er wohl physikalisch in der Nähe sein
Also ne spezielle Kiste, die für die „anderen Kisten“ das VPN macht?
Schon der Name legt die Idee nahe… 
Ja, doch. Einleuchtend… also jetzt… so nachträglich. Ich denke, es ist zu spät die dumme Frage zurückzuziehen, richtig? 
Gibt es nicht. Sonst wüsstest du es ja jetzt nicht
Trotzdem wäre interessant zu erfahren was das für eine Kiste ist und wie die Installation aussieht 
Da hat jemand das Gateway Flag auf einem Knoten gesetzt obwohl das eigentlich unsinnig ist. Denn er announced das Gateway nicht nur für seine lokale Wolke sondern für die ganze Domäne. An der Funktionalität das er für die Wolke der einzigste Uplink ist ändert sich eigentlich nix, wenn er ohne Gateway Flag seinen Dienst tut, denn die eigentlichen Gateways werden ja durch ihn in seine Wolke weitergeleitet.
Weiterhin müsste auf diesem Gateway auch essentielle Dienste laufen wie ein lokaler DHCP für IPv4, denn BATMAN_adv leitet DHCP Requests nur an das beste zu erreichende Gateway weiter.
Das Setup selber würde mich aber auch sehr interessieren, zumal da ja auch ein ordentlicher Link zu sehen ist.
Könnte Thomas’ lokale Supernode sein…die ist aber weder für „normale“ Nodes VPN announced in der site.conf und hat durch niedrigeren Bandbreitenwert eine radikal schlechtere Metrik, um nicht versehentlich das Netz an sich zu reißen…darüber hinaus ist das Mesh Interface stark priorisiert…wenn es das Gateway beim Thomas ist, dann ist das alles schon absolut richtig so…
Müsste @thomasDOTwtf mal Licht ins Dunkel bringen, ob es sein lokales Gateway ist oder nicht
Da wundert mich dann allerdings, warum es im ffmap-backend als Gateway erkannt wird.
Meines Wissens nach, ist das „vpn: true“-Flag nur per Alias-Configuration-File erlaubt.
Ich würde der Möhne-Map eh nicht vertrauen was das angeht. Schaltet mal die VPN-Verbindungen ein und ihr seht, dass „normale“ Knoten ziemlich viele davon haben. Da sind wohl einige Supernodes nicht als solche gekennzeichnet.
Bei unserer Map ist das auch. Stock Map direkt aus dem ffnord GIT. Schalte ich bei einem meiner Knoten beim BATMAN das Gateway ein, erscheint er auch als Gateway in der Map. Clients bekommen dann aber keine IPv4 Adressen mehr, weil die DHCP Anfragen auf dem Knoten terminieren und da läuft kein DHCP Server.
root@201:~# batctl gwl
Gateway (#/255) Nexthop [outgoingIF]: gw_class … [B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: bbmoehne/04:af:fe:00:02:01 (bat0)]
1e:6d:17:b4:43:55 (255) 1a:59:9e:84:f7:da [ bbmoehne]: 215 - 96MBit/96MBit
04:af:fe:00:00:01 (235) 56:c5:69:af:7d:07 [ bbmoehne]: 215 - 96MBit/96MBit
c6:45:11:d9:26:c1 (225) ce:bc:f6:bb:29:00 [ bbmoehne]: 215 - 96MBit/96MBit
ea:c6:ea:e2:f5:1f ( 37) 1a:59:9e:84:f7:da [ bbmoehne]: 86 - 64MBit/56MBit
@thomasDOTwtf alle Welt surft über deinen Anschluss!!! 
Wie kommst Du darauf, die Prio ist doch massiv niedriger als bei den ersten 3 „VPN Supernodes“?
Dann habe ich mit absoluter mal wieder unwissenheit geglänzt. Ich dachte eine niedrige zahl heisst hohe Prio.
(37) = Reliabilität, also die Qualität der Verbindung zu diesem Gateway von 1 wie kaum vorhanden bis 255 wie nahezu Ethernet
86 = forward Metric, also die Priorität dieses Gateways, je höher desto bevorzugter, dort fliessen Bandwidth Wert und Reliabilität mit ein
Vielen Dank beitragzukurz