Projekte/v642/Arbeitspakete - Versionsgeschichte

Pocki am 24. Mai 2019 um 05:58 Uhr

2019-05-24T05:58:27Z

← Nächstältere Version		Version vom 24. Mai 2019, 05:58 Uhr
Zeile 39:		Zeile 39:
	\| 8+ MB Flash, 32+ MB RAM, OpenWRT CC-kompatibel, Treiber-Unterstützung für verbaute WLAN-Chips		\| 8+ MB Flash, 32+ MB RAM, OpenWRT CC-kompatibel, Treiber-Unterstützung für verbaute WLAN-Chips
	\| –		\| –
	\|-
	~~\| Anpassung 0xFF-Management-Tools~~
	~~\| Zusammenstellung der nötigen/gewünschten Änderungen, Implementierung derselben~~
	~~\| Pocki~~
	~~\| Management-Tools wie Redeemer, Map etc. müssen/wollen wir evtl. für v642 anpassen.~~
	~~\| ✓[https://ff.cybercomm.at/map2/ Map] ✓Redeemer ✓[http://smokeping.funkfeuer.at/smokeping/olsr2/ Smokeping] DNS:inArbeit~~
	\|-		\|-
	\| Deployment		\| Deployment
Zeile 103:		Zeile 97:
	\| Dokumentation: [[Medium:OLSRd_V2_Wizard.pdf\|OLSRd_V2_Wizard.pdf]]		\| Dokumentation: [[Medium:OLSRd_V2_Wizard.pdf\|OLSRd_V2_Wizard.pdf]]
	\| ✓		\| ✓
			\|-
			\| Anpassung 0xFF-Management-Tools
			\| Zusammenstellung der nötigen/gewünschten Änderungen, Implementierung derselben
			\| Pocki
			\| Management-Tools wie Redeemer, Map etc. müssen/wollen wir evtl. für v642 anpassen.
			\| ✓[https://ff.cybercomm.at/map2/ Map] ✓Redeemer ✓[http://smokeping.funkfeuer.at/smokeping/olsr2/ Smokeping] ✓DNS
	\|}		\|}

	== Weitere (weniger konkrete) Ideen ==		== Weitere (weniger konkrete) Ideen ==
	Da gibt's mittlerweile eine ganze Reihe. Wer mag, kann sie ja hier als Denkanstoß für die gemeinsamen Treffen auflisten.		Da gibt's mittlerweile eine ganze Reihe. Wer mag, kann sie ja hier als Denkanstoß für die gemeinsamen Treffen auflisten.

Pocki am 22. Mai 2019 um 16:28 Uhr

2019-05-22T16:28:57Z

← Nächstältere Version		Version vom 22. Mai 2019, 16:28 Uhr
Zeile 26:		Zeile 26:
	\| David		\| David
	\| Einfaches Config-Interface fuer das v642-Setup.		\| Einfaches Config-Interface fuer das v642-Setup.
	~~\| –~~
	\|-
	~~\| Test-Link v642~~
	~~\| Funktionierender Link zwischen Krypta und Metalab + Test-Router erreichbar~~
	~~\| Clemens~~
	~~\| Ein Link, auf dem IPv6 mit OLSRv2 funktioniert, sowie die v642-Router unten im Metalab via OLSRv2 angebunden werden können~~
	~~\| –~~
	\|-
	~~\| 4in6-Tunnelserver~~
	~~\| Tunnelserver-Produktivsystem ist aufgesetzt und betriebsbereit~~
	~~\| Raoul~~
	~~\| Tunnelserver-Setup für 4in6-Translation; Produktiv-System ist NICHT das Dev-System~~
	\| –		\| –
	\|-		\|-
Zeile 54:		Zeile 42:
	\| Anpassung 0xFF-Management-Tools		\| Anpassung 0xFF-Management-Tools
	\| Zusammenstellung der nötigen/gewünschten Änderungen, Implementierung derselben		\| Zusammenstellung der nötigen/gewünschten Änderungen, Implementierung derselben
	\| –		\| Pocki
	\| Management-Tools wie Redeemer, Map etc. müssen/wollen wir evtl. für v642 anpassen.		\| Management-Tools wie Redeemer, Map etc. müssen/wollen wir evtl. für v642 anpassen.
	\| –		\| ✓[https://ff.cybercomm.at/map2/ Map] ✓Redeemer ✓[http://smokeping.funkfeuer.at/smokeping/olsr2/ Smokeping] DNS:inArbeit
	\|-		\|-
	\| Deployment		\| Deployment
Zeile 96:		Zeile 84:
	\| Adi, Wolfgang		\| Adi, Wolfgang
	\| Bereitstellung eines LANs mit statischen, public IPv6- und IPv4-Adressen. Konzept steht, siehe Subnet-Plan, VLAN-Tagging.		\| Bereitstellung eines LANs mit statischen, public IPv6- und IPv4-Adressen. Konzept steht, siehe Subnet-Plan, VLAN-Tagging.
			\| ✓
			\|-
			\| Test-Link v642
			\| Funktionierender Link zwischen Krypta und Metalab + Test-Router erreichbar
			\| Clemens
			\| Ein Link, auf dem IPv6 mit OLSRv2 funktioniert, sowie die v642-Router unten im Metalab via OLSRv2 angebunden werden können
			\| ✓
			\|-
			\| 4in6-Tunnelserver
			\| Tunnelserver-Produktivsystem ist aufgesetzt und betriebsbereit
			\| Raoul
			\| Tunnelserver-Setup für 4in6-Translation; Produktiv-System ist NICHT das Dev-System
			\| ✓
			\|-
			\| EdgeRouter Wizard für OLSRv2 und Doku
			\| Installationspaket und User-Interface für EdgeOS
			\| Pocki
			\| Dokumentation: [[Medium:OLSRd_V2_Wizard.pdf\|OLSRd_V2_Wizard.pdf]]
	\| ✓		\| ✓
	\|}		\|}

Dhopfm: Update to current status

2016-12-29T19:21:06Z

Update to current status

← Nächstältere Version		Version vom 29. Dezember 2016, 19:21 Uhr
Zeile 1:		Zeile 1:
	Zu Beginn des Projekts haben wir folgende Arbeitspakete definiert (work in progress, keine bestimmte Reihenfolge). Jeder ist eingeladen, die Informationen zu präzisieren. :-)		Zu Beginn des Projekts haben wir folgende Arbeitspakete definiert (work in progress, keine bestimmte Reihenfolge). Jeder ist eingeladen, die Informationen zu präzisieren. :-)

	== ~~Geplante~~ Arbeitspakete ==		== Offene Arbeitspakete ==

	{\| class="wikitable"		{\| class="wikitable"
Zeile 9:		Zeile 9:
	! Beschreibung		! Beschreibung
	! Status		! Status
	\|-
	~~\| Management-Interface~~
	~~\| Entscheidung bzgl. Enduser-Wartungsinterface (LuCI, NuCI, SSH, …) vorbereitet getroffen~~
	~~\| Adi, David~~
	\| Die verschiedenen Interfaces haben ihre Vor- und Nachteile bzgl. Enduser-Eignung, Sicherheit, Aufwand für Erstellung, …). Wir wollen selbige sammeln, dokumentieren und auf Basis dessen eine Entscheidung treffen.
	~~\| Ausarbeitung für Entscheidung am 2016-07-11~~
	\|-		\|-
	\| Default-Config Node		\| Default-Config Node
Zeile 20:		Zeile 14:
	\| –		\| –
	\| Sämtliche Node-Config, z.B. VLAN, Firewall, 4in6, …		\| Sämtliche Node-Config, z.B. VLAN, Firewall, 4in6, …
			\| –
			\|-
			\| LuCI-App für OLSRv2
			\| App als ipk verfügbar und mit CC und Trunk kompatibel.
			\| David
			\| Analog zur bestehenden App für OLSRv1 (Config + Status).
			\| –
			\|-
			\| LuCI-App für 0xFF
			\| App als ipk verfügbar und mit CC und Trunk kompatibel.
			\| David
			\| Einfaches Config-Interface fuer das v642-Setup.
	\| –		\| –
	\|-		\|-
Zeile 30:		Zeile 36:
	\| 4in6-Tunnelserver		\| 4in6-Tunnelserver
	\| Tunnelserver-Produktivsystem ist aufgesetzt und betriebsbereit		\| Tunnelserver-Produktivsystem ist aufgesetzt und betriebsbereit
	\| ~~Wolfgang~~		\| Raoul
	\| Tunnelserver-Setup für 4in6-Translation; Produktiv-System ist NICHT das Dev-System		\| Tunnelserver-Setup für 4in6-Translation; Produktiv-System ist NICHT das Dev-System
	\| –		\| –
Zeile 38:		Zeile 44:
	\| –		\| –
	\| Inhalt: Knoten-Aufbau, Konfiguration		\| Inhalt: Knoten-Aufbau, Konfiguration
	\| –		\| on hold
	\|-		\|-
	\| Aktuelle HW-Liste für Nodes		\| Aktuelle HW-Liste für Nodes
Zeile 45:		Zeile 51:
	\| 8+ MB Flash, 32+ MB RAM, OpenWRT CC-kompatibel, Treiber-Unterstützung für verbaute WLAN-Chips		\| 8+ MB Flash, 32+ MB RAM, OpenWRT CC-kompatibel, Treiber-Unterstützung für verbaute WLAN-Chips
	\| –		\| –
	\|-
	~~\| 802.11?~~
	~~\| Entscheidung für einen Standard (.11s?), funktionierende Implementierung + Config~~
	~~\| Paul~~
	~~\| Siehe Zieldefinition~~
	~~\| Ausarbeitung bis 2016-07-25~~
	\|-		\|-
	\| Anpassung 0xFF-Management-Tools		\| Anpassung 0xFF-Management-Tools

Dhopfm: Cleanup

2016-07-02T20:43:36Z

Cleanup

← Nächstältere Version		Version vom 2. Juli 2016, 20:43 Uhr
Zeile 69:		Zeile 69:
	{\| class="wikitable"		{\| class="wikitable"
	! Arbeitspaket		! Arbeitspaket
	! ~~Task~~		! Ziel
	! Owner		! Owner
	! Beschreibung		! Beschreibung
	! ~~done~~		! Status
	\|-		\|-
	\| Subnetting-Konzept		\| Subnetting-Konzept
	\| ~~Erstellung~~ Konzept		\| Es existiert ein Konzept, das die Implementierung von IPv6 und IPv4 im Rahmen des v642-Projekts beschreibt. Konsultationen mit der restlichen Community wurden durchgeführt.
	\| Manfred		\| Manfred, David
	\| Es gibt bereits ein fertiges IPv6-Konzept, das die 0xFF-IPv6-Arbeitsgruppe erstellt hat. Dieses soll nun herangezogen und ggf. angepasst werden.		\| Es gibt bereits ein fertiges IPv6-Konzept, das die 0xFF-IPv6-Arbeitsgruppe erstellt hat. Dieses soll nun herangezogen und ggf. angepasst werden.
	\| –		\| ✓
	\|-		\|-
	\| [[Projekte/v642/IPv4_Support\|Übersetzungs-Server IPv4 <-> IPv6]]		\| [[Projekte/v642/IPv4_Support\|Übersetzungs-Server IPv4 <-> IPv6]]
	\| Konzept		\| Konzept: Es existiert ein ausgearbeitetes und akkordiertes Konzept für einen IPv4-Übergangsmechanismus.
	\| Wolfgang		\| Wolfgang
	\| Um weiterhin IPv4 anbieten zu können, wird voraussichtlich auf einen Übergangsmechanismus gesetzt werden (also kein Dual-Stack). Soweit dafür zentrale Gateways vonnöten sind, müssen diese bereit gestellt werden.		\| Um weiterhin IPv4 anbieten zu können, wird voraussichtlich auf einen Übergangsmechanismus gesetzt werden (also kein Dual-Stack). Soweit dafür zentrale Gateways vonnöten sind, müssen diese bereit gestellt werden.
	\| ✓		\| ✓
	\|-		\|-
	\|		\| Prototyp 4in6-Tunnel
	\| Prototyp		\| Der Prototyp eines 4in6-Tunnels wurde auf Basis von OpenWRT erfolgreich getestet.
	\| Wolfgang/Arbeitstreffen		\| Wolfgang/Arbeitstreffen
	\| Erfolgreicher Test des 4in6-Tunnels beim Arbeitstreffen am 2016-05-02.		\| Erfolgreicher Test des 4in6-Tunnels beim Arbeitstreffen am 2016-05-02.
Zeile 97:		Zeile 97:
	\| Bereitstellung eines LANs mit statischen, public IPv6- und IPv4-Adressen. Konzept steht, siehe Subnet-Plan, VLAN-Tagging.		\| Bereitstellung eines LANs mit statischen, public IPv6- und IPv4-Adressen. Konzept steht, siehe Subnet-Plan, VLAN-Tagging.
	\| ✓		\| ✓
	\|-
	~~\| Backbone: IPv6-Anbindung, Uplinks~~
	~~\| Konzept~~
	~~\| ?~~
	~~\| Im Backbone fehlt momentan noch eine native IPv6-Anbindung, daneben gibt's auch noch ein paar weitere Punkte, die das Backbone-Team angehen möchte.~~
	~~\| unassigned~~
	\|-
	~~\| Kommunikation/Community-Management~~
	~~\| Ausarbeitung~~
	~~\| David~~
	\| Uns ist bewusst, dass es bei dem Projekt nicht nur um technische Herausforderungen geht, sondern auch um die Kommunikation: schließlich wird letztendlich die Mitarbeit aller Node-Owner nötig sein und realistischer Weise wird das nicht in 100% der Fälle reibungslos laufen und nicht 100% der Betreiber Feuer und Flamme oder auch nur erreichbar sein.
	~~\| unassigned~~
	\|-
	~~\| Node Database~~
	~~\| Konzept~~
	~~\| ?~~
	\| Die bestehende Node Database benötigt ein Makeover für die Zuweisung der neuen Subnetze, etc. Es stellt sich auch die Frage ob ein dezentraleres Konezpt für diese Datenbank möglich wäre (Blockchain z.B.).
	~~\| unassigned~~
	\|-
	~~\| Standard Firmware~~
	~~\| Erstellung~~
	~~\| Adi~~
	~~\| Eine Firmware für eine breite Menge an viel eingesetzen Geräten die das neue Netz supported.~~
	~~\| ?~~
	\|}		\|}

	== Weitere (weniger konkrete) Ideen ==		== Weitere (weniger konkrete) Ideen ==
	Da gibt's mittlerweile eine ganze Reihe. Wer mag, kann sie ja hier als Denkanstoß für die gemeinsamen Treffen auflisten.		Da gibt's mittlerweile eine ganze Reihe. Wer mag, kann sie ja hier als Denkanstoß für die gemeinsamen Treffen auflisten.

Dhopfm: Überarbeitung Arbeitspakete

2016-06-27T20:12:18Z

Überarbeitung Arbeitspakete

← Nächstältere Version		Version vom 27. Juni 2016, 20:12 Uhr
Zeile 2:		Zeile 2:

	== Geplante Arbeitspakete ==		== Geplante Arbeitspakete ==

			{\| class="wikitable"
			! Arbeitspaket
			! Ziel
			! Owner
			! Beschreibung
			! Status
			\|-
			\| Management-Interface
			\| Entscheidung bzgl. Enduser-Wartungsinterface (LuCI, NuCI, SSH, …) vorbereitet getroffen
			\| Adi, David
			\| Die verschiedenen Interfaces haben ihre Vor- und Nachteile bzgl. Enduser-Eignung, Sicherheit, Aufwand für Erstellung, …). Wir wollen selbige sammeln, dokumentieren und auf Basis dessen eine Entscheidung treffen.
			\| Ausarbeitung für Entscheidung am 2016-07-11
			\|-
			\| Default-Config Node
			\| Default-Config erarbeitet, entschieden und festgeschrieben (dokumentiert)
			\| –
			\| Sämtliche Node-Config, z.B. VLAN, Firewall, 4in6, …
			\| –
			\|-
			\| Test-Link v642
			\| Funktionierender Link zwischen Krypta und Metalab + Test-Router erreichbar
			\| Clemens
			\| Ein Link, auf dem IPv6 mit OLSRv2 funktioniert, sowie die v642-Router unten im Metalab via OLSRv2 angebunden werden können
			\| –
			\|-
			\| 4in6-Tunnelserver
			\| Tunnelserver-Produktivsystem ist aufgesetzt und betriebsbereit
			\| Wolfgang
			\| Tunnelserver-Setup für 4in6-Translation; Produktiv-System ist NICHT das Dev-System
			\| –
			\|-
			\| Enduser-Doku
			\| Es gibt eine Online und in Printform verfügbare Doku, die argumentierbar von Endusern als brauchbar bezeichnet wird
			\| –
			\| Inhalt: Knoten-Aufbau, Konfiguration
			\| –
			\|-
			\| Aktuelle HW-Liste für Nodes
			\| Es ist eine aktuelle Einkaufsliste v642-kompatibler (empfohlener) Nodes verfügbar
			\| –
			\| 8+ MB Flash, 32+ MB RAM, OpenWRT CC-kompatibel, Treiber-Unterstützung für verbaute WLAN-Chips
			\| –
			\|-
			\| 802.11?
			\| Entscheidung für einen Standard (.11s?), funktionierende Implementierung + Config
			\| Paul
			\| Siehe Zieldefinition
			\| Ausarbeitung bis 2016-07-25
			\|-
			\| Anpassung 0xFF-Management-Tools
			\| Zusammenstellung der nötigen/gewünschten Änderungen, Implementierung derselben
			\| –
			\| Management-Tools wie Redeemer, Map etc. müssen/wollen wir evtl. für v642 anpassen.
			\| –
			\|-
			\| Deployment
			\| Es existiert eine Dokumentation, die Anspekte wie Reihenfolge, Kommunikation etc. einschließt
			\| –
			\| Siehe oben
			\| –
			\|}

			== Erledigte Arbeitspakete ==

	{\| class="wikitable"		{\| class="wikitable"

Wnagele am 30. Mai 2016 um 17:57 Uhr

2016-05-30T17:57:20Z

← Nächstältere Version		Version vom 30. Mai 2016, 17:57 Uhr
Zeile 42:		Zeile 42:
	\| Kommunikation/Community-Management		\| Kommunikation/Community-Management
	\| Ausarbeitung		\| Ausarbeitung
	\| ?		\| David
	\| Uns ist bewusst, dass es bei dem Projekt nicht nur um technische Herausforderungen geht, sondern auch um die Kommunikation: schließlich wird letztendlich die Mitarbeit aller Node-Owner nötig sein und realistischer Weise wird das nicht in 100% der Fälle reibungslos laufen und nicht 100% der Betreiber Feuer und Flamme oder auch nur erreichbar sein.		\| Uns ist bewusst, dass es bei dem Projekt nicht nur um technische Herausforderungen geht, sondern auch um die Kommunikation: schließlich wird letztendlich die Mitarbeit aller Node-Owner nötig sein und realistischer Weise wird das nicht in 100% der Fälle reibungslos laufen und nicht 100% der Betreiber Feuer und Flamme oder auch nur erreichbar sein.
	\| unassigned		\| unassigned

Wnagele am 12. Mai 2016 um 10:01 Uhr

2016-05-12T10:01:56Z

← Nächstältere Version		Version vom 12. Mai 2016, 10:01 Uhr
Zeile 51:		Zeile 51:
	\| Die bestehende Node Database benötigt ein Makeover für die Zuweisung der neuen Subnetze, etc. Es stellt sich auch die Frage ob ein dezentraleres Konezpt für diese Datenbank möglich wäre (Blockchain z.B.).		\| Die bestehende Node Database benötigt ein Makeover für die Zuweisung der neuen Subnetze, etc. Es stellt sich auch die Frage ob ein dezentraleres Konezpt für diese Datenbank möglich wäre (Blockchain z.B.).
	\| unassigned		\| unassigned
			\|-
			\| Standard Firmware
			\| Erstellung
			\| Adi
			\| Eine Firmware für eine breite Menge an viel eingesetzen Geräten die das neue Netz supported.
			\| ?
	\|}		\|}

	== Weitere (weniger konkrete) Ideen ==		== Weitere (weniger konkrete) Ideen ==
	Da gibt's mittlerweile eine ganze Reihe. Wer mag, kann sie ja hier als Denkanstoß für die gemeinsamen Treffen auflisten.		Da gibt's mittlerweile eine ganze Reihe. Wer mag, kann sie ja hier als Denkanstoß für die gemeinsamen Treffen auflisten.

Wnagele am 12. Mai 2016 um 09:57 Uhr

2016-05-12T09:57:53Z

← Nächstältere Version		Version vom 12. Mai 2016, 09:57 Uhr
Zeile 44:		Zeile 44:
	\| ?		\| ?
	\| Uns ist bewusst, dass es bei dem Projekt nicht nur um technische Herausforderungen geht, sondern auch um die Kommunikation: schließlich wird letztendlich die Mitarbeit aller Node-Owner nötig sein und realistischer Weise wird das nicht in 100% der Fälle reibungslos laufen und nicht 100% der Betreiber Feuer und Flamme oder auch nur erreichbar sein.		\| Uns ist bewusst, dass es bei dem Projekt nicht nur um technische Herausforderungen geht, sondern auch um die Kommunikation: schließlich wird letztendlich die Mitarbeit aller Node-Owner nötig sein und realistischer Weise wird das nicht in 100% der Fälle reibungslos laufen und nicht 100% der Betreiber Feuer und Flamme oder auch nur erreichbar sein.
			\| unassigned
			\|-
			\| Node Database
			\| Konzept
			\| ?
			\| Die bestehende Node Database benötigt ein Makeover für die Zuweisung der neuen Subnetze, etc. Es stellt sich auch die Frage ob ein dezentraleres Konezpt für diese Datenbank möglich wäre (Blockchain z.B.).
	\| unassigned		\| unassigned
	\|}		\|}

Wnagele am 12. Mai 2016 um 09:37 Uhr

2016-05-12T09:37:04Z

← Nächstältere Version		Version vom 12. Mai 2016, 09:37 Uhr
Zeile 16:		Zeile 16:
	\| –		\| –
	\|-		\|-
	\| Übersetzungs-Server IPv4 <-> IPv6		\| [[Projekte/v642/IPv4_Support\|Übersetzungs-Server IPv4 <-> IPv6]]
	\| Konzept		\| Konzept
	\| Wolfgang		\| Wolfgang

Wnagele: Removed Hotspot part as we are not working on that actively

2016-05-11T20:25:51Z

Removed Hotspot part as we are not working on that actively

← Nächstältere Version		Version vom 11. Mai 2016, 20:25 Uhr
Zeile 33:		Zeile 33:
	\| Bereitstellung eines LANs mit statischen, public IPv6- und IPv4-Adressen. Konzept steht, siehe Subnet-Plan, VLAN-Tagging.		\| Bereitstellung eines LANs mit statischen, public IPv6- und IPv4-Adressen. Konzept steht, siehe Subnet-Plan, VLAN-Tagging.
	\| ✓		\| ✓
	\|-
	~~\| Hotspot (Access public)~~
	~~\| Konzept~~
	~~\| ?~~
	~~\| Bereitstellung eines Internet-Zugangs für die Öffentlichkeit.~~
	~~\| unassigned~~
	\|-		\|-
	\| Backbone: IPv6-Anbindung, Uplinks		\| Backbone: IPv6-Anbindung, Uplinks