[Berlin-wireless] Testhardware für entwickler ... erste schritte

[Stefan Pirwitz]

das ganze ist nun ins wiki gezoggn.
erreichbar unter http://wiki.freifunk.net/Capturetunnel


Am 28.12.2008 um 21:46 schrieb Stefan Pirwitz:

> Hallodi,
> um etwas mehr mit den Entwicklern der Openwrt und OLSR  
> zusammenzuarbeiten, wäre es schön, wenn wir gemeinsam ein paar  
> "über" geräte zum allgemeinen gefriemel freigeben können und über  
> das netz zugriffsfähig zu machen. Um jedoch nicht alles jedem gleich  
> sofort zugänglich zu machen, wäre dazwischen ein "System" ganz  
> schick, das freigegebene "bastelhardware" für entwickler  
> bereitstellt. Hier mal ein grobriss unserer Gedanken:
>
>
>
> === DEV-Bugfind-Tunnel ===
> ==== Grundprinzip ====
> Angedacht ist es ein "Problemkind" oder ein "Testknoten" der  
> Developer-Communitiy zu Testzwecken bereit zu stellen.
> Dies sollte auf Layer2 - Ebene bis zum Entwickler durchgetunnelt  
> werden.
>
> Hierzu sollen vorzugsweise Linux-Boardmittel benutzt werden, um die  
> Kapazitäten auf den Knoten vor dem Router zu schonen.
>
> <pre>
>
>
> Server im Internet
> 	|   Tunnelbeginn Layer 2
> 	V
> 	/* NAT / DSL
> 	|
> 	V
> 	/* Z.B. MESH oder Zielnetzwerk
> 	|
> 	V    Ende Tunnel Layer 2
> Knoten vor Router (Wirtsknoten)
> 	* Reset		$(Bridge zwischen TunnelIf und eth* )
> 	* via 		$
> 	* Kaltstart	$/*Lankabel
> 	* z.b. Relais	$
> 	* via GIP0	$
> 	V		V
> =================================
> *		DUT		*
> * 		Device under 	*
> *		Test		*
> * 	   /Testnknoten 	*
> =================================
> </pre>
>
> ===== Feinkonzept =====
> Im Internet sollte ein Server als Tunnelkonzentrator oder besser  
> noch als Portalserver vorhanden sein.
>
> Das Portal hätte die Form eines Registers, in welchem die Knoten mit  
> ihren Umgebungsbedingungen vom Knotenbetreiber beschrieben werden.
> Der Entwickler wählt den passenden Testknoten und stellt  
> (automatisiert?) eine Anfrage auf Zugriff (und reserviert sogar Zeit  
> für die Tests?).
> Stimmt der Knotenbetreiber zu, wird der Tunnel zwischen Wirtsknoten  
> und Server aufgebaut und vom Server aus der Tunnel dem Entwickler  
> angeboten.
>
> Vorteile:
> - Layer2-connectivity zum Testknoten
> - kein portfw an NAT-Gateways nötig
> - Zugang vom knotenbetreiber einfach abschaltbar
>
> Probleme:
> - Zeiteinteilung sicherstellen / Parallelgefrickel vermeiden
>
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20081231/8d786adb/attachment.html>