Selfnet Blog

Jul 07, 2017

Erweiterung des Selfnet-Netzwerkes in der Stuttgarter City (Teil I)

Als Selfnet vor mehr als 17 Jahren gegründet wurde war dies nur durch eine große Anzahl an Bürgschaften, Spenden, Krediten und personeller Unterstützung möglich. Dass aus dieser Vereinigung von damaligen Studenten einmal eine so große Angelegenheit wird, hätte damals vermutlich nie jemand gedacht.

Mittlerweile sind diese damaligen Studenten bei verschiedenen Technologieunternehmen eingestiegen. Durch die nachfolgenden Generationen von Studenten ist Selfnet eines der größten Studentennetze in Deutschland geworden. Selfnet trägt sich nach wie vor nur durch Spenden, Mitgliedsbeiträge und der ehrenamtlichen Arbeit der Mitglieder selbst, ohne eine Einflussnahme von außen. Dadurch können wir technisch und auch ideell Dinge in unserem Netzwerk realisieren, welche man in einem industriellen Umfeld niemals finden würde.

Durch diese "Wir wollen dass alle Studenten eine gute Netzwerkanbindung haben" Mentalität, welche sich bis heute gehalten hat, wurde vieles verwirklicht. In den letzten Jahren kamen in der Stuttgarter Innenstadt mehrere große Wohnheime zu unserem Netzwerk dazu, unter anderem die Heilmannstraße 3-7 (190 Zimmer) und die Rosensteinstraße 1-5 (346 Zimmer) welche auch gleichzeitig flächendeckend mit WLAN versorgt werden konnten. Nach langen Diskussionen mit dem Vorstand und der Mitgliederversammlung, sowie Verhandlungen mit dem Studierendenwerk Stuttgart können wir jetzt einen weiteren Schritt gehen.

Vor einigen Wochen haben wir mit dem Studierendenwerk einen Vertrag geschlossen, welcher es uns ermöglicht in den kommenden Monaten weitere Wohnheime in der Innenstadt an unser leistungsstarkes Netzwerk anzubinden. Es handelt sich dabei um die Wohnheime

  • Neckarstraße 132
  • Wohngruppen im Studierendenhotel (Neckarstr. 172)
  • Rieckestraße
  • Kernerstraße
  • Landhausstraße
  • Anna-Herrigel-Haus (Nach der Kernsanierung im Februar 2018)

Die Umstellung der Wohnheime wird voraussichtlich zwischen September und Oktober vorgenommen, ein genaues Datum für jedes Wohnheim ist durch verschiedene Faktoren leider nicht festlegbar. Die Bewohner werden vor den Arbeiten natürlich noch einmal benachrichtigt.

Die Anbindung der Wohnheime wird dabei durch eine Glasfaser-Anbindung zu unserem bestehenden Netz realisiert, sodass zukünftig auch in diesen relativ kleinen Wohnheimen die Netzwerkgeschwindigkeiten pro Zimmer auf 1 GBit/s angehoben werden können. Durch die relativ hohen Investitionskosten (insgesamt etwa 200.000 €) können wir dort vorerst keine WLAN-Abdeckung aufbauen, werden aber natürlich versuchen diese in den kommenden Jahren zu realisieren.

In Zukunft wollen wir auch versuchen die noch verbliebenen Wohnheime in Stuttgart anzubinden. Ob, wann und wie schnell dies geschieht, hängt aber auch davon ab, ob wir Unterstützung von Bewohnern vor Ort bekommen. Da die Projekte wie immer von Ehrenamtlichen durchgeführt werden, suchen wir auch Leute vor Ort, die bei der Planung und Realisierung helfen möchten. Sofern du uns helfen willst in (deinem oder anderen) Wohnheimen deine Ideen zu verwirklichen: Komm einfach zum Schluss einer Sprechstunde bei uns vorbei und lass dir völlig unverbindlich alles zeigen. Wir sind immer auf der Suche nach neuen und motivierten Mitgliedern. Es spielt dabei keine Rolle, ob du dich für Technik begeisterst oder nicht. Lediglich Neugierde ist eine wichtige Voraussetzung.

Jul 02, 2017

Ceph storage upgrade post mortem

Unser Servernetz besteht hauptsächlich aus virtuellen Maschinen auf VM-Hosts, deren Daten in einem Storage-Cluster (SAN) verteilt liegen. Die Maschinen sind aus Redundanzgründen aufgeteilt auf verschiedene Standorte in Vahingen und Stadtmitte. Wichtige Dienste (z.B. DHCP, DNS) sind auch redundant auf mehreren VM-Hosts verteilt.

Wir haben vorgestern (nach dem AOA) und gestern auf unserem Storage-Cluster ein Update der Ceph Version von "Hammer" auf "Jewel" durchgeführt. Gleichzeitig haben die Admins von unseren VM-Hosts diese auf ein aktuelles Debian geupdated.

Damit es nicht zu Ausfällen kommt, haben wir auf einem unserer 3 VM-Hosts (den in der Stadt) alle wichtigen VMs am laufen gehalten.

Das Update vom Ceph-Cluster lief anfänglich gut, bis auf eine kurze Downtime. Das Cluster hat Lese- und Schreibzugriffe blockiert, weil kurzzeitig zu wenige Teile vom Cluster online waren. Aber dann waren auch alle Clusterknoten auf der neusten LTS Version.

Das "Upgrade" der VM-Hosts wurde zu einer Neuinstallation, damit alles mal wieder sauber und gleichmäßig aufgesetzt ist. Daher hat das länger als geplant gedauert. Besonders kamen hier unerwartete Inkompatibilitäten zwischen Betriebssystem, verwendeter Virtualisierungssoftware und Storage zu Tage, welche den Prozess weiter verzögerten.

Die wichtigsten VMs (auf dem KVM-Host in der Stadt) konnten dann leider unerwarteterweise nicht mehr mit der neuen Ceph Version reden und damit waren auch DHCP/DNS-Dienste nicht mehr verfügbar. Das war Freitagbend gegen viel-zu-spät Uhr und das war auch der Zeitpunkt als die ersten Mails von euch eintrudelten :)

Um den Netzbetrieb schnellst möglich wieder herzustellen wurde ein manuelles Upgrade des Linuxes auf dem VM-Host in der Stadt durchgeführt (das dauert leider auch etwas...). Nach dem Upgrade waren die Ceph Versionen wieder kompatibel und die wichtigsten Server konnten wieder gestartet werden. Damit hatten alle (ok fast alle) Nutzer wieder Internetzugriff.

Die Ausfälle haben also lediglich unsere Server betroffen. Unser (Kabel-)Netzwerk ist super stabil und redundant aufgebaut. Die Ausfälle des Internetzugangs rühren daher, dass man ohne DHCP-Server keine IP-Adresse bekommt und ohne DNS-Server keine Domains in IP-Adressen auflösen kann.

Zusätzlich erschwerend kam hinzu, dass es aktuell ungelöste Probleme im Netzwerk zwischen der Serverfarm in der Stadtmitte und den Wohnheimen Pfaffenhof 2 und Bauhäusle gibt. Dieses Problem sorgt zum Beispiel dafür, dass der zweite DHCP-Server in der Stadt seine Antworten nicht an eure Computer in den betroffenen Wohnheimen schicken kann, die Pakete gehen unterwegs verloren oder kommen so kaputt an, dass sie verworfen werden. Daher kamen die meisten eurer E-Mails auch aus den besagten Wohnheimen.

Wenn du es geschafft hast bis hier zu lesen: Komm doch demnächst nach dem Support mal bei uns vorbei und lass dir alles zeigen. Wir sind auf der Suche nach neuen und motivierten Mitgliedern. Du lernst hier spannende Dinge und hast die Möglichkeit mit neuer cooler Hardware zu spielen.

Feb 09, 2015

Plastikonf, dumping the flash

The last time, I analyzed the the hardware and figured out where the firmware is stored. So let's dump it. The datasheet tells us, that the flash IC has an SPI interface. Now we need something that adapts SPI to a more common interface like preferably USB. There are several devices to to this:

  • Use some microcontroller and write firmware for it that reads the SPI flash and dumps its contents via UART/USB. Downside: have to write code for microcontroller, hard to debug
  • Bus Pirate already supports SPI flashes. Unfortunately, Selfnet doesn't have one.
  • FTDI also makes USB to SPI converters besides USB to UART. I didn't have one at hand either, but I've had existing code for using certain FTDI bridges as USB - SPI converts.

So I purchased the FT2232H Mini Module and built an adapter to connect the SPI flash to it.

Picture of FT2232H Setup

The FT2232H contains a so called MPSSE (Multi-Protocol Synchronous Serial Engine) to do SPI. Side note: FTDI claims that the MPSSE also supports I²C, but since the FT2232H doesn't have open-drain outputs and has some glitching issues, it's really painful to implement. Since my existing code was developed on Windows™, it used the proprietary FTD2XX driver. After some fiddling, I got ftd2xx to work on python 3. Sorry, libftdi people :(

Implementing the protocol used by the SPI flash was rather straightforward since its datasheet is available. One particular nice aspect of the protocol is that you can read an arbitrary amount of data after sending the start address. So I hacked an IPython notebook to dump the flash. Magically, it worked the first time, therefore I didn't bother to clean it up to make it publishable.

That's inside the romdump:

$ binwalk romdump

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
94976         0x17300         U-Boot version string, "U-Boot 1.1.3 (Dec  4 2013 - 08:55:41)"
131584        0x20200         LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 3515396 bytes
1441792       0x160000        Squashfs filesystem, little endian, version 4.0, compression:lzma (non-standard type definition), size: 5051300 bytes,  627 inodes, blocksize: 131072 bytes, created: Fri Jun 20 05:19:24 2014
8126480       0x7C0010        XML document, version: "1.0"

In the next post, we'll dig into the romdump.

← Previous Next → Page 9 of 11