Protokolle/Techniktreffen 2013-12-12: Unterschied zwischen den Versionen

Aus Freifunk MWU Wiki
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: „ == Gedankenfesthaltungsprotokoll vom Techniktreffen am 12.12.2013 zur Grundinfrastruktur == - Gates vereinen Entry(Tinc)- und Exit(Schweden)-Level in einer …“)
 
K (Spky verschob die Seite Projekte/Technik/Treffen 2013-12-12 nach Protokolle/Techniktreffen 2013-12-12, ohne dabei eine Weiterleitung anzulegen)
 
(5 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 vereinen Entry(Tinc)* und Exit(Schweden)-Level in einer Maschine (keine geteilte Entry-/Exit-Node Strategie)
  
- Gates verbinden nach Schweden per VPN
+
* Gates verbinden nach Schweden per VPN
  
- Gates routen+NATen zwischen Freifunk-Wolke und Schweden/Internetz
+
* Gates routen+NATen zwischen Freifunk-Wolke und Schweden/Internetz
  
- Gates sind DHCP (dhcpd)
+
* Gates sind DHCP (dhcpd)
+
** DHCP verteilt neue Leases bis zum Erreichen eines Threshold (empirisch ermitteln)
  - DHCP verteilt Leases bis Threshold
+
** DHCP ermittelt/berechnet seine Last anhand der Anzahl der verteilten Leases und Bandbreitenauslastung
  - DHCP ermittelt Last anhand von 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 wenn Last zu hoch keine neuen Leases aber beantwortet/bestätigt die vorhandenen Leases weiterhin
+
** DHCP verteilt Leases mit TTL 5 Min.
  - DHCP verteilt Leases mit TTL 5min
+
** Jedes Gate hat seine eigene Adressrange, disjunkt von denen anderer Gates.
  - Jedes Gate hat eigene Adressrange
 
  
- Nodes verbinden sich per Tinc zu Gates
+
* Nodes verbinden sich per Tinc zu Gates
  
- Nodes bekommen Pool von 20 tinc-server hinterlegt
+
* Nodes bekommen einen Pool von 20 Tinc-Servern hinterlegt (im Voraus angelegte Schlüsselpaare) als Wachstumspfad
  
- Nodes bekommen DNS Namen der Gates eingetragen
+
* Nodes bekommen DNS-Namen der Gates eingetragen
  
- Nodes entscheiden bei Boot:
+
* Nodes entscheiden bei Boot:
  - welche Tinc-Server erreichbar sind (Ping check)
+
** welche Tinc-Server erreichbar sind (Ping check)
  - Nodes kopieren aus den ermittelten lebendigen Servern 2-3 Tinc-Keys in ihren Tinc-Hosts-Ordner
+
** Nodes kopieren aus den ermittelten lebendigen Servern 2-3 Tinc-Keys in ihren Tinc-Hosts-Ordner
  - jedes Gate hat eigenen Priv/Pub-Key
+
** jedes Gate hat eigenes Priv/Pub-Schlüsselpärchen
  
- tinc verschlüsseln ja/nein?
+
* 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 compression aus (gescheite Protokolle sind sowieso kompressiert, der Rest ist nicht komprimierbar)
+
* tinc namensschema:
  - tinc verschlüsselung an
+
** soll einheitlich vorgegeben werden
  - node publickeys werden per GIT verteilt
+
** (evtl. hash aus vorgegebener datei)
  - node publickeys werden von der technikgruppe eingetragen
+
*** besser gut menschenlesbar
  - es werden 20 tinc schlüssel für die Gates vorab generiert und im node-image hinterlegt
+
** evtl. prefix gleich und zweiter teil private und selbst bestimmbar
  - verschlüsselungs-algo wird von sebastian getestet und der für MIPS schnellste ausgewählt (weil starke crypto nicht gebraucht)
+
** brauchen wir tincnamen?
  
- tinc namensschema:
+
* batman
  - soll einheitlich vorgegeben werden
+
** originator Interval auf 10 Sek.
  - evtl. hash aus vorgegebener datei
+
** network mode und andere Optionen anschauen/testen
  - evtl. prefix gleich und zweiter teil private und selbst bestimmbar
 
  - brauchen wir tincnamen?
 
  
- batman
+
* wenn tinc-uplink weg dann freifunk SSID aus/verstecken?
  - originator interval auf 10 sec
 
  - network mode und andere optionen anschauen/testen
 
  
 +
* mesh verstecken?
  
- wenn tinc-uplink weg dann freifunk SSID aus/verstecken?
+
==Anmerkungen==
  
- mesh verstecken?
+
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.