Protokolle/Techniktreffen 2013-12-12: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Spky (Diskussion | Beiträge) K (Spky verschob die Seite Projekte/Technik/Treffen 12 12 2013 nach Projekte/Technik/Treffen 2013-12-12: Falsches Datumsformat) |
Spky (Diskussion | Beiträge) K (Spky verschob die Seite Projekte/Technik/Treffen 2013-12-12 nach Protokolle/Techniktreffen 2013-12-12, ohne dabei eine Weiterleitung anzulegen) |
||
| (4 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
| + | {{Protokoll| | ||
| + | |Protokollant= | ||
| + | |Datum=12.12.2013 | ||
| + | |Ort= | ||
| + | |Teilnehmer= | ||
| + | }} | ||
== Gedankenfesthaltungsprotokoll vom Techniktreffen am 12.12.2013 zur Grundinfrastruktur == | == Gedankenfesthaltungsprotokoll vom Techniktreffen am 12.12.2013 zur Grundinfrastruktur == | ||
| − | + | * Gates vereinen Entry(Tinc)* und Exit(Schweden)-Level in einer Maschine (keine geteilte Entry-/Exit-Node Strategie) | |
| − | + | * Gates verbinden nach Schweden per VPN | |
| − | + | * Gates routen+NATen zwischen Freifunk-Wolke und Schweden/Internetz | |
| − | + | * Gates sind DHCP (dhcpd) | |
| − | + | ** DHCP verteilt neue Leases bis zum Erreichen eines Threshold (empirisch ermitteln) | |
| − | + | ** DHCP ermittelt/berechnet seine Last anhand der Anzahl der verteilten Leases und Bandbreitenauslastung | |
| − | + | ** DHCP verteilt, wenn Last zu hoch, also über dem Threshold, keine neuen Leases mehr, wohl aber beantwortet/bestätigt er die vorhandenen Leases weiterhin | |
| − | + | ** DHCP verteilt Leases mit TTL 5 Min. | |
| − | + | ** Jedes Gate hat seine eigene Adressrange, disjunkt von denen anderer Gates. | |
| − | |||
| − | + | * Nodes verbinden sich per Tinc zu Gates | |
| − | + | * Nodes bekommen einen Pool von 20 Tinc-Servern hinterlegt (im Voraus angelegte Schlüsselpaare) als Wachstumspfad | |
| − | + | * Nodes bekommen DNS-Namen der Gates eingetragen | |
| − | + | * Nodes entscheiden bei Boot: | |
| − | + | ** welche Tinc-Server erreichbar sind (Ping check) | |
| − | + | ** Nodes kopieren aus den ermittelten lebendigen Servern 2-3 Tinc-Keys in ihren Tinc-Hosts-Ordner | |
| − | + | ** jedes Gate hat eigenes Priv/Pub-Schlüsselpärchen | |
| − | + | * tinc verschlüsseln ja/nein? | |
| + | ** tinc-Compression aus, da gescheite Protokolle sowieso komprimiert sind und der Rest ist nicht komprimierbar ist (JPGs, MPGs) | ||
| + | ** tinc-Verschlüsselung an | ||
| + | ** node publickeys werden per GIT verteilt | ||
| + | ** node publickeys werden von der Technikgruppe eingetragen | ||
| + | ** es werden 20 tinc schlüssel für die Gates vorab generiert und im node-image hinterlegt | ||
| + | ** verschlüsselungs-algo wird von sebastian getestet und der für MIPS schnellste ausgewählt (weil starke crypto nicht gebraucht) | ||
| − | + | * tinc namensschema: | |
| − | + | ** soll einheitlich vorgegeben werden | |
| − | + | ** (evtl. hash aus vorgegebener datei) | |
| − | + | *** besser gut menschenlesbar | |
| − | + | ** evtl. prefix gleich und zweiter teil private und selbst bestimmbar | |
| − | + | ** brauchen wir tincnamen? | |
| − | + | * batman | |
| − | + | ** originator Interval auf 10 Sek. | |
| − | + | ** network mode und andere Optionen anschauen/testen | |
| − | |||
| − | |||
| − | - | + | * wenn tinc-uplink weg dann freifunk SSID aus/verstecken? |
| − | |||
| − | |||
| + | * mesh verstecken? | ||
| − | + | ==Anmerkungen== | |
| − | - mesh | + | Auf dem 30c3 wurden die Hamburger zur Gateway-Infrastruktur befragt: |
| + | * Sie verwenden fastd, und Tunneln dort batman durch | ||
| + | ** Es gibt seit kurzem eine neue Version von fastd ('''fastd-f'''), welches angeblich mehr Performance als Tinc liefert. | ||
| + | * Die Gateway-Server laufen im batman im [http://www.open-mesh.org/projects/batman-adv/wiki/Gateways Gateway-Modus] | ||
| + | ** Ist der Gatewayserver nicht mehr verwendbar (IPredator-Uplink nicht bezahlt, Traffic voll, etc) wird der Gateway-Modus in Batman abgeschaltet, Batman auf den Nodes macht dann ein Failover auf die anderen Gateways. | ||
Aktuelle Version vom 31. August 2014, 00:34 Uhr
| Protokoll Info | |
|---|---|
| Protokollant | |
| Datum | 12.12.2013 |
| Ort | |
| Teilnehmer | |
Gedankenfesthaltungsprotokoll vom Techniktreffen am 12.12.2013 zur Grundinfrastruktur
- Gates vereinen Entry(Tinc)* und Exit(Schweden)-Level in einer Maschine (keine geteilte Entry-/Exit-Node Strategie)
- Gates verbinden nach Schweden per VPN
- Gates routen+NATen zwischen Freifunk-Wolke und Schweden/Internetz
- Gates sind DHCP (dhcpd)
- DHCP verteilt neue Leases bis zum Erreichen eines Threshold (empirisch ermitteln)
- DHCP ermittelt/berechnet seine Last anhand der Anzahl der verteilten Leases und Bandbreitenauslastung
- DHCP verteilt, wenn Last zu hoch, also über dem Threshold, keine neuen Leases mehr, wohl aber beantwortet/bestätigt er die vorhandenen Leases weiterhin
- DHCP verteilt Leases mit TTL 5 Min.
- Jedes Gate hat seine eigene Adressrange, disjunkt von denen anderer Gates.
- Nodes verbinden sich per Tinc zu Gates
- Nodes bekommen einen Pool von 20 Tinc-Servern hinterlegt (im Voraus angelegte Schlüsselpaare) als Wachstumspfad
- Nodes bekommen DNS-Namen der Gates eingetragen
- Nodes entscheiden bei Boot:
- welche Tinc-Server erreichbar sind (Ping check)
- Nodes kopieren aus den ermittelten lebendigen Servern 2-3 Tinc-Keys in ihren Tinc-Hosts-Ordner
- jedes Gate hat eigenes Priv/Pub-Schlüsselpärchen
- tinc verschlüsseln ja/nein?
- tinc-Compression aus, da gescheite Protokolle sowieso komprimiert sind und der Rest ist nicht komprimierbar ist (JPGs, MPGs)
- tinc-Verschlüsselung an
- node publickeys werden per GIT verteilt
- node publickeys werden von der Technikgruppe eingetragen
- es werden 20 tinc schlüssel für die Gates vorab generiert und im node-image hinterlegt
- verschlüsselungs-algo wird von sebastian getestet und der für MIPS schnellste ausgewählt (weil starke crypto nicht gebraucht)
- tinc namensschema:
- soll einheitlich vorgegeben werden
- (evtl. hash aus vorgegebener datei)
- besser gut menschenlesbar
- evtl. prefix gleich und zweiter teil private und selbst bestimmbar
- brauchen wir tincnamen?
- batman
- originator Interval auf 10 Sek.
- network mode und andere Optionen anschauen/testen
- wenn tinc-uplink weg dann freifunk SSID aus/verstecken?
- mesh verstecken?
Anmerkungen
Auf dem 30c3 wurden die Hamburger zur Gateway-Infrastruktur befragt:
- Sie verwenden fastd, und Tunneln dort batman durch
- Es gibt seit kurzem eine neue Version von fastd (fastd-f), welches angeblich mehr Performance als Tinc liefert.
- Die Gateway-Server laufen im batman im Gateway-Modus
- Ist der Gatewayserver nicht mehr verwendbar (IPredator-Uplink nicht bezahlt, Traffic voll, etc) wird der Gateway-Modus in Batman abgeschaltet, Batman auf den Nodes macht dann ein Failover auf die anderen Gateways.