https://docs.opennet-initiative.de/index.php?action=history&feed=atom&title=Benutzer%3ALeo%2FBlog%3A2020_February_09_16%3A43%3A30_CET 2026-10-07T12:07:19Z Versionsgeschichte dieser Seite in Opennet MediaWiki 1.43.9 https://docs.opennet-initiative.de/index.php?title=Benutzer:Leo/Blog:2020_February_09_16:43:30_CET&diff=35143&oldid=prev 2020-02-09T15:45:34Z

<p>Techniktreffen (09.02.2020)</p> <p><b>Neue Seite</b></p><div>=== Techniktreffen (09.02.2020) ===<br /> <br /> === Allgemeines ===<br /> * eventuell neuer UGW Server in Hamburg. Es besteht wahrscheinlich auch die Möglichkeit dann BGP zu nutzen.<br /> * neuer Schlüsselzugang für Rene<br /> * Aufräumen: Wir hatten bisher noch ein WebDAV Ordner für den Vorstand. Die Daten sind bereits im letzten Jahr ins git übergegangen. Somit wurde jetzt der WebDAV Ordner entsorgt.<br /> * CA: die aktuellen Sub-CA-Zertifikate sind nur noch bis 2023 gültig - wir sollten beginnen uns darauf vorzubereiten<br /> <br /> === Routing-Protokoll ===<br /> * die Intensität der olsr-Entwicklung (olsr1 und olsr2) ist aktuell eher gering<br /> * olsr1 ist aktuell end-of-life (der aktuelle Maintainer hat angekündigt, keine weitere Pflege zu betreiben)<br /> * olsr2 wird nur mit wenig Intensität weiterentwickelt (drei Commits im letzten Halbjahr; davor gab es deutlich mehr Aktivität)<br /> * babel könnte vielleicht eine langfristige Alternative sein - vorerst hoffen wir aber auf neuen Schwung im olsr-Ökosystem<br /> <br /> === Firmware ===<br /> * alle aktuellen Geräte sollten mittlerweile durch unsere unstable Firmware unterstützt werden. Lediglich bei 32MB Geräte gibt es Probleme. Hier muss eine alte Firmware genutzt werden.<br /> * es gibt keine &quot;größeren&quot; bekannten Bugs<br /> * die Firmware basiert dann auf OpenWrt 19.07.1 (erschienen am 31. Januar 2020)<br /> <br /> === IPv6 ===<br /> * wir haben das Problem der Adressverteilung für APs mit Internetzugang diskutiert<br /> * bisher war unser Verständnisproblem, dass die DHCPv6-PD lediglich Subnetze verteilt, jedoch anschließend nicht weiß, welcher AP welches Subnetz erhalten hat<br /> * somit konnten wir uns nicht vorstellen, wie Antwortpakete von gai aus ihren Weg zu einem Internet-Nutzer hinter einem AP finden sollten<br /> * Lösung: NDP-Proxy<br /> ** der AP würde dann auch auf Neighbour Solicitation Anfragen positiv antworten, für die er nicht direkt, sondern für die ein Client in seinem LAN verantwortlich ist<br /> ** dies löst unser DHCPv6-PD-Problem<br /> ** Voraussetzungen:<br /> **** Layer3-Netzwerk zwischen AP und gai (z.B. ein tap-Netzwerk mit OpenVPN, oder tinc oder wireguard mit einem tap-Tunnel (GRETAP))<br /> **** Martin wird dies ausprobieren (wahrscheinlich mit einem weiteren OpenVPN-Interface via tap basierend auf den Nutzer-Schlüsseln)<br /> <br /> Ein beispielhafter Netzaufbau ist folgender:<br /> <br /> [[Datei:Ipv6-ndp-problem.png]]</div>

Leo