142 lines
7.4 KiB
Plaintext
142 lines
7.4 KiB
Plaintext
[[Kategorie:Projekt]]
|
|
= Chaos Pr Net =
|
|
; Geekend Termin:
|
|
https://dudle.inf.tu-dresden.de/chaos-pr-geekend/
|
|
|
|
Chatraum :
|
|
pr@muc.hq.c3d2.de
|
|
|
|
== Technik ==
|
|
|
|
=== Funkstrecke ===
|
|
CB-Funk
|
|
* Geräte billig
|
|
* als Altlasten verfügbar
|
|
* Einstiegshürden gering (ohne auf Lizenz zu betreiben)
|
|
* Band ist nahezu verwaist
|
|
* 2.4kbit sind genug Bandbreite für textbasierende Kommunikation
|
|
* PR ist sehr robust was die Übertragungssicherheit angeht
|
|
|
|
=== Modems ===
|
|
* Soundmodem
|
|
** Tests waren sehr vielversprechend
|
|
** billig, flexibel
|
|
** CB mit 2.4kbit stabil (Mr.Smith: scheinbar sehr abhängig von den Funkgeräten, bin inzwischen auf Probleme gestoßen, 1.2kbit ging immer)
|
|
** externe Schaltung nötig, welche aber billig und einfach zu bauen ist
|
|
** Aussagen beziehen sich auf Kernel-Soundmodem, seit Kernel 3.0 ist das im Userspace, muss getestet werden
|
|
* TNC
|
|
** stabilste Verbindung
|
|
** Digipeater auch ohne PC
|
|
** 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 (MR.Smith: liegt an der Stromversorgung über RS232, wird Spannung extern eingespeisst ist es ähnlich stabil wie bei TNC)
|
|
** Umbau auf 2.4kbit relativ leicht möglich (Mr. Smith: Austausch Quarz, zu finden in alten PAL-Decodern oder ca. 0.20€ bei Reichelt)
|
|
** keine Bastelei nötig
|
|
|
|
==== Modem entwicklung ====
|
|
* gnuradio
|
|
* stm32f4 board
|
|
|
|
== Client Boxen ==
|
|
Usart-Bridge für PTT + USB Audio für Soundmodem
|
|
|
|
=== 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 und
|
|
* autonom über Akku oder Solar betreibbar.
|
|
|
|
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.
|
|
* es gibt konkretes Interesse von Naturschutzgruppen das für Telemetrie zu nutzen, UMTS und andere Lösungen zu teuer
|
|
|
|
=== 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.
|
|
|
|
→ 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
|
|
|
|
=== 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 öffentliche Schlüssel wird beim Beginn einer neuen Konversation übertragen und lokal gespeichert.
|
|
|
|
=== Vorhandene Technik ===
|
|
|
|
* Mr. Smith
|
|
** 4x Alan 42 Multi Handfunkgerät
|
|
** 1x Alan 95 Handfunkgerät
|
|
** 1x Stabo 4012 Heimstation
|
|
** 1x Brenner 30W
|
|
** 1x Brenner 200W (realistisch eher 100W bei FM/AM)
|
|
** 4x Mobilantenne BNC (für Alan-Geräte)
|
|
** 1x Magnetfußantenne 1/4 mit PL-Anschluss
|
|
** 1x Basisantenne Noname 5/8 (wird demnächst ersetzt durch höheren Mast und Sirio Basisantenne)
|
|
** 1x TNC2
|
|
** 2x Baycom-kompatible Minimodems
|
|
** 2x USB-RS232-Adapter
|
|
*_john
|
|
** 1x Team TS 404 einfache Mobilfunke (Leihgabe von bigalex. TNX!)
|
|
** 1x Handscanner mit Diskriminatorausgang
|
|
** ... more to come...
|
|
* Messtechnik zum bauen finden sich
|
|
** im HQ des C3D2
|
|
** im Turmlabor??
|
|
** diverse Oszis, Messbrücken usw. bei Mr. Smith im Wald
|
|
|
|
=== Links ===
|
|
|
|
** Radio Shield für Ardoino http://wiki.argentdata.com/index.php?title=Radio_Shield
|
|
** http://www.possumliving.com/2011/02/packet-radio-app-for-apocalypse.html
|
|
** http://www.pcworld.com/article/218155/get_internet_access_when_your_government_shuts_it_down.html
|
|
** PIC basierter TNC http://tnc-x.com/
|
|
** Cubieboard (Alternative zum RasperryPi) http://www.indiegogo.com/cubieboard
|