Form
This commit is contained in:
Vater
parent
6c1f21add2
commit
e0ee628c81
178
ChaosPrNet.mw
178
ChaosPrNet.mw
|
|
@ -1,113 +1,105 @@
|
|||
[[Kategorie:Projekt]]
|
||||
=Chaos Pr Net=
|
||||
Geekend Termin:
|
||||
= Chaos Pr Net =
|
||||
; Geekend Termin:
|
||||
https://dudle.inf.tu-dresden.de/chaos-pr-geekend/
|
||||
|
||||
Chatraum :
|
||||
pr@muc.hq.c3d2.de
|
||||
|
||||
== Technik ==
|
||||
|
||||
|
||||
|
||||
==Technik==
|
||||
|
||||
===Funkstrecke===
|
||||
=== Funkstrecke ===
|
||||
CB-Funk
|
||||
*Geräte billig
|
||||
*als altlasten verfügbar
|
||||
*einstiegshürden gering (ohne afu Lizens zu betreiben)
|
||||
*Band ist nahezu verwaist
|
||||
* Geräte billig
|
||||
* als Altlasten verfügbar
|
||||
* Einstiegshürden gering (ohne auf Lizenz zu betreiben)
|
||||
* Band ist nahezu verwaist
|
||||
|
||||
=== Modems ===
|
||||
* Soundmodem
|
||||
** Tests waren sehr vielversprechend
|
||||
** billig, flexibel
|
||||
** CB mit 2.4kbit stabil
|
||||
** externe Schaltung nötig, welche aber billig und einfach zu bauen ist
|
||||
* TNC
|
||||
** stabilste Verbindung
|
||||
** wenig Konfigurationsaufwand
|
||||
** teuer (je nach Typ zwischen 30€ und 200€)
|
||||
** keine Bastelei nötig
|
||||
** nicht alle TNC können alle Geschwindigkeiten (bei CB meist nur 1.2kbit sinnvoll)
|
||||
* baycom
|
||||
** relativ billig (ca. 20€)
|
||||
** Verbindung nicht so stabil wie bei Soundmodem oder TNC (liegt an der Stromversorgung über RS232)
|
||||
** Umbau auf 2.4kbit relativ leicht möglich (Austausch Quarz)
|
||||
** keine Bastelei nötig
|
||||
|
||||
===Modems===
|
||||
*Soundmodem
|
||||
==== Modem entwicklung ====
|
||||
* gnuradio
|
||||
* stm32f4 board
|
||||
|
||||
**Tests waren sehr vielversprechend
|
||||
**billig, flexibel
|
||||
**CB mit 2.4kbit stabil
|
||||
**externe Schaltung nötig, welche aber billig und einfach zu bauen ist
|
||||
== Client Boxen ==
|
||||
Usart-Bridge für PTT + USB Audio für Soundmodem
|
||||
|
||||
*tnc
|
||||
|
||||
**stabilste Verbindung
|
||||
**wenig Konfigurationsaufwand
|
||||
**teuer (je nach Typ zwischen 30€ und 200€)
|
||||
**keine Bastelei nötig
|
||||
**nicht alle TNC können alle Geschwindigkeiten (bei CB meist nur 1.2kbit sinnvoll)
|
||||
|
||||
*baycom
|
||||
|
||||
**relativ billig (ca. 20€)
|
||||
**Verbindung nicht so stabil wie bei Soundmodem oder TNC (liegt an der Stromversorgung über RS232)
|
||||
**Umbau auf 2.4kbit relativ leicht möglich (Austausch Quarz)
|
||||
**keine Bastelei nötig
|
||||
|
||||
====Modem entwicklung====
|
||||
*gnuradio
|
||||
*stm32f4 board
|
||||
|
||||
|
||||
==Client Boxen==
|
||||
Usart-Bridge für PTT + USB Audio für soundmodem
|
||||
===Motivation===
|
||||
=== Motivation ===
|
||||
Unabhängige Verbindungsknoten schaffen, die
|
||||
* ein dezentrales Netz aufbauen können (serverlose Adressvergabe, dynamisches Routing)
|
||||
* von Noobs bedienbar sind
|
||||
* verschlüsselt übertragen
|
||||
* Textmessages senden
|
||||
* Emails (bevorzugt mit Inet-tauglicher Adressierung)
|
||||
* verteiltes Diskussionsforum
|
||||
* kleinskalierte Grafiken übertragen können
|
||||
* klein, robust, günstig und energiesparend sind
|
||||
* autonom über Akku oder Solar betreibbar
|
||||
* ein dezentrales Netz aufbauen können (serverlose Adressvergabe, dynamisches Routing),
|
||||
* von Noobs bedienbar sind,
|
||||
* verschlüsselt übertragen,
|
||||
* Textmessages senden,
|
||||
* Emails (bevorzugt mit Inet-tauglicher Adressierung),
|
||||
* verteiltes Diskussionsforum,
|
||||
* kleinskalierte Grafiken übertragen können,
|
||||
* klein, robust, günstig und energiesparend sind und
|
||||
* autonom über Akku oder Solar betreibbar.
|
||||
|
||||
Anwendungsfälle:
|
||||
* allgemein Fernkommunikation ohne externe Netzanbieter
|
||||
* in ökonomischen, ökologischen Krisenfällen
|
||||
* in Gegenden in denen andere Netze nicht existieren
|
||||
* im Falle von der Manipulation/Abschaltung der etablierten Kommunikationswege durch staatliche Stellen
|
||||
Anwendungsfälle sind:
|
||||
* allgemein Fernkommunikation ohne externe Netzanbieter;
|
||||
* in ökonomischen, ökologischen Krisenfällen;
|
||||
* in Gegenden in denen andere Netze nicht existieren;
|
||||
* im Falle von der Manipulation/Abschaltung der etablierten Kommunikationswege durch staatliche Stellen.
|
||||
|
||||
===Hardware===
|
||||
=== Hardware ===
|
||||
* robuste, schicke Box :)
|
||||
* rasberry pi
|
||||
* Speicherkarte für Betriebssystem
|
||||
* günstige gebrauchte cb-Funke
|
||||
* Adapterkabel funkgerätanschluss(gibt fünf verschiedene) auf Klinke und rs232(o.ä.)
|
||||
* Außenanschlüsse für
|
||||
** bnc,
|
||||
** vga,
|
||||
** 2 x usb,
|
||||
** an-schalter,
|
||||
** channelschalter und
|
||||
** geläufiger 12V-Anschluss.
|
||||
|
||||
*robuste, schicke Box :)
|
||||
*rasberry pi
|
||||
*Speicherkarte für Betriebssystem
|
||||
*günstige gebrauchte cb-Funke
|
||||
*Adapterkabel funkgerätanschluss(gibt fünf verschiedene) auf Klinke und rs232(o.ä.)
|
||||
*Außenanschlüsse für bnc,vga,2xusb,an-schalter,channelschalter,geläufiger 12V-Anschluss
|
||||
→ alles möglichst unter 100€ mit Zusammenbau realisierbar
|
||||
|
||||
→ alles möglichst unter 100€ mit zusammenbau realisierbar
|
||||
=== Software ===
|
||||
* Debian Server ohne X und sinnlose Dienste wie Samba und Pulseaudio, die einem in Konfiguration und sockets eingreifen
|
||||
* dm-crypt vollverschlüsselt
|
||||
* selbstgeschriebenes (Python) Curses/Urwid-Frontend, dass als Oberfläche startet, wenn der Node hochgefahren wird und folgendes kann:
|
||||
** die Einrichtung der Node durchführen
|
||||
** die Verbindung herstellen (Adressvergabe)
|
||||
** verfügbare Stationen listen
|
||||
** verschlüsselten chat zwischen den Stationen
|
||||
** Übertragung von Dateien zwischen den Stationen (wegen Netzauslastung nur kleinskalierte, komprimierte Grafiken)
|
||||
** dezentrales offline messaging?
|
||||
* ax25, netrom, Soundmodem
|
||||
|
||||
===Software===
|
||||
|
||||
*Debian Server ohne X und sinnlose Dienste wie Samba und Pulseaudio, die einem in Konfiguration und sockets eingreifen
|
||||
*dm-crypt vollverschlüsselt
|
||||
*selbstgeschriebenes (Python) Curses/Urwid-Frontend, dass als Oberfläche startet, wenn der Node hochgefahren wird und folgendes kann:
|
||||
**die Einrichtung der Node durchführen
|
||||
**die Verbindung herstellen (Adressvergabe)
|
||||
**verfügbare stationen listen
|
||||
**verschlüsselten chat zwischen den stationen
|
||||
**übertragung von dateien zwischen den stationen (wegen netzauslastung nur kleinskalierte,komprimierte grafiken)
|
||||
**dezentrales offline messaging?
|
||||
*ax25,netrom,soundmodem
|
||||
|
||||
===Funktionsweise===
|
||||
|
||||
*osi-protokollebenen: afsk→ax25→netrom→ip→udp→in python selbst geschriebene anwendung
|
||||
**ax25 → ist im kernel läuft einfach mit soundmodem (afsk-bell203etc.) und wir wollen nicht den amateurfunk neu erfinden. Auch ist das Protokoll gut an die unwegsamkeit der funkverbindung angepasst (empfangsbestätigung, resend etc.)
|
||||
**netrom → ax25 unterstützt kein dynamisches routing und eignet sich so nur für starre netze, wir planen ja aber gerade was hochdynamisches, bei benutzung von netrom muss kein routing neu erfunden werden
|
||||
** ip → ist eigentlich überflüssig und ich habe lange geschaut es zu vermeiden, aber leider unterstützt keine höhere programmiersprache (und ich kann auch nur, was ich kann) die amateurfunk sockets. zudem sind alle vorhandenen sinnvollen dienste auf ip-zugeschnitten. die handhabung der ip-protokollspezifikationen ist auch wesentlich besser dokumentiert
|
||||
** udp→ ist schlicht und einfach und nicht fehlertolerant, besitzt lediglich eine prüfsumme im packetheader. im gegensatz zu tcp stellt es keine dauerhafte verbindung her und frisst so weniger bandbreite (siehe dein vorschlag mit uucp). die wichtige fehlertoleranz wollen wir hier garnicht, weil sie schon auf der ax25 schicht gewährleistet wird
|
||||
|
||||
* Begründung des Frontends: ich habe mich gegen eine grafische umgebung entschieden, weil sie das system ausbremst und instabil macht. es laufen dienste die in den socket eingreifen oder die soundkarte beeinflussen, als zusatzhardware ist eine eigentlich überflüssige maus notwendig. Aber einen normalen user kann man nicht auf einen terminal loslassen. daher: eine ncurses oberfläche, die einfach zu bedienen ist und zugriff auf dokumentation beinhaltet
|
||||
=== Funktionsweise ===
|
||||
|
||||
* OSI-Protokollebenen: afsk→ax25→netrom→ip→udp→in python selbst geschriebene Anwendung
|
||||
** ax25 → ist im Kernel läuft einfach mit Soundmodem (afsk-bell203etc.) und wir wollen nicht den Amateurfunk neu erfinden. Auch ist das Protokoll gut an die Unwegsamkeit der Funkverbindung angepasst (Empfangsbestätigung, resend etc.)
|
||||
** netrom → ax25 unterstützt kein dynamisches routing und eignet sich so nur für starre Netze, wir planen ja aber gerade was hochdynamisches, bei Benutzung von netrom muss kein routing neu erfunden werden
|
||||
** ip → ist eigentlich überflüssig und ich habe lange geschaut es zu vermeiden, aber leider unterstützt keine höhere Programmiersprache (und ich kann auch nur, was ich kann) die amateurfunk sockets. zudem sind alle vorhandenen sinnvollen Dienste auf ip zugeschnitten. die Handhabung der ip-Protokollspezifikationen ist auch wesentlich besser dokumentiert
|
||||
** udp→ ist schlicht und einfach und nicht fehlertolerant, besitzt lediglich eine Prüfsumme im packetheader. Im Gegensatz zu tcp stellt es keine dauerhafte Verbindung her und frisst so weniger Bandbreite (siehe dein Vorschlag mit uucp). die wichtige Fehlertoleranz wollen wir hier gar nicht, weil sie schon auf der ax25 Schicht gewährleistet wird
|
||||
* Begründung des Frontends: ich habe mich gegen eine grafische umgebung entschieden, weil sie das System ausbremst und instabil macht. es laufen dienste die in den socket eingreifen oder die soundkarte beeinflussen, als zusatzhardware ist eine eigentlich überflüssige Maus notwendig. Aber einen normalen user kann man nicht auf einen terminal loslassen. daher: eine ncurses oberfläche, die einfach zu bedienen ist und zugriff auf dokumentation beinhaltet
|
||||
* Verbindungsprozess:
|
||||
**Beim ersten Start der node muss der user einen ax25 callsign angeben, der aus sechs zahlen oder buchstaben besteht. dieser wird auch als adresse zum anlegen eines pgp schlüssels benutzt. Hier besteht die gefahr eines konfliktes, der aber bei der zu erwartenden netzgröße eher gering ausfällt
|
||||
** als nächstes braucht der knoten eine ipadresse, die bei jedem connect neu zugewiesen wird, denn es besteht nur ein adressraum bei ipv4 von 255-x adressen im zu erstellenden intranet (10.0.0.x). dafür snifft der knoten 5min lang den traffic im netz und sammelt ipadressen der anderen nodes (die nodes haben einen dienst laufen der alle 5min eine broadcastmessage mit ihrer ip und funkrufnamen bekanntgibt) und wählt dannach eine nicht vergebene ip
|
||||
** nach diesem verbindungsprozess macht sich der knoten mit einer ersten broadcastmessage ebenfalls bekannt
|
||||
**Anmerkung: Broadcast über netrom ist noch nicht erprobt
|
||||
|
||||
*Verschlüsselung:
|
||||
**PGP
|
||||
**Beim erstmaligen einrichten der Node wird ein Schlüsselpaar erzeugt
|
||||
**Der öff. Schlüssel wird beim Beginn einer neuen Konversation übertragen und lokal gespeichert
|
||||
** Beim ersten Start der node muss der user einen ax25 callsign angeben, der aus sechs zahlen oder buchstaben besteht. dieser wird auch als adresse zum anlegen eines pgp schlüssels benutzt. Hier besteht die gefahr eines konfliktes, der aber bei der zu erwartenden netzgröße eher gering ausfällt
|
||||
** Als nächstes braucht der knoten eine ipadresse, die bei jedem connect neu zugewiesen wird, denn es besteht nur ein adressraum bei ipv4 von 255-x Adressen im zu erstellenden intranet (10.0.0.x). dafür snifft der knoten 5min lang den traffic im netz und sammelt ipadressen der anderen nodes (die nodes haben einen dienst laufen der alle 5min eine broadcastmessage mit ihrer ip und funkrufnamen bekanntgibt) und wählt dannach eine nicht vergebene ip
|
||||
** Nach diesem Verbindungsprozess macht sich der Knoten mit einer ersten broadcastmessage ebenfalls bekannt.
|
||||
** Anmerkung: Broadcast über netrom ist noch nicht erprobt.
|
||||
* Verschlüsselung:
|
||||
** PGP
|
||||
** Beim erstmaligen Einrichten der Node wird ein Schlüsselpaar erzeugt.
|
||||
** Der öffentliche Schlüssel wird beim Beginn einer neuen Konversation übertragen und lokal gespeichert.
|
||||
|
|
|
|||
Loading…
Reference in New Issue