FeM Blog (Artikel mit Tag technik)

Prevent DoS attacks from a Bluecoat proxy using HAProxy

nospam@example.com (Marcel Pennewiß) — Sat, 30 Jan 2016 21:25:05 +0100

We provide shared hosting for a huge number of non-profit organizations located at our university. We have been using haproxy and multiple web-nodes for load balancing and reliability ever since our service is used by more and more organizations.

Over the last few weeks we have observed that one of our hosted websites (medienbewusst.de) regularly comes under DoS attacks. This is incredibly annoying and we have now started to investigate this issue in more detail.

All requests are generated by one or multiple-source ip address(es), which always belong to the network of a single company. The attack pattern is almost always identical: First there is a request by a well-known User-Agent (e.g. Firefox 38), which is followed by more than 1500 requests in approximately 3 or 4 minutes, to name one example. These all have the same User-Agent: "Mozilla/4.0 (compatible;)".



::ffff:1.2.3.4 - - [26/Jan/2016:14:47:55 +0100] "GET /fernsehen/20130531/programmtipps-fur-juni-2013.html HTTP/1.1" 200 70439 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0"
::ffff:1.2.3.4 - - [26/Jan/2016:14:47:56 +0100] "GET /2015/08 HTTP/1.1" 200 58606 "-" "Mozilla/4.0 (compatible;)"
::ffff:1.2.3.4 - - [26/Jan/2016:14:47:56 +0100] "GET /cms/favicon.ico HTTP/1.1" 404 63555 "-" "Mozilla/4.0 (compatible;)"
::ffff:1.2.3.4 - - [26/Jan/2016:14:47:56 +0100] "GET /2014/03 HTTP/1.1" 200 57874 "-" "Mozilla/4.0 (compatible;)"
::ffff:1.2.3.4 - - [26/Jan/2016:14:47:56 +0100] "GET /fernsehen/20130531/medienbewusst.de%20& HTTP/1.1" 404 63583 "-" "Mozilla/4.0 (compatible;)"
::ffff:1.2.3.4 - - [26/Jan/2016:14:47:56 +0100] "GET /2014/06 HTTP/1.1" 200 58581 "-" "Mozilla/4.0 (compatible;)"
::ffff:1.2.3.4 - - [26/Jan/2016:14:47:56 +0100] "GET /2015/06 HTTP/1.1" 200 58251 "-" "Mozilla/4.0 (compatible;)"

After talking to a technician, who is responsible for one of these company networks, it turned out that the company uses proxy appliances build by Blue Coat. Their proxy seemingly prefetches the whole webpage really fast, which causes a DoS in association with the used content management system. Users in blogs and forums report that this is typical for Blue Coat proxies and the requests can be identified by the HTTP-Header "HTTP_X_BLUECOAT_VIA" next to the User-Agent.

We now prohibit the requests on our HAProxy-Loadbalancers with the following configuration:

frontend web-1 ... # Block Bluecoat proxy prefetch requests with User-Agent and special HTTP header acl blocked_ua hdr_sub(user-agent) -i Mozilla/4.0\ (compatible;) acl blocked_proxy hdr_cnt(X-BlueCoat-Via) gt 0 use_backend blocked-proxy-ua if blocked_ua blocked_proxy ... backend blocked-proxy-ua mode http errorfile 503 /etc/haproxy/errors/503_blocked_proxy_ua.txt

File /etc/haproxy/errors/503_blocked_proxy_ua.txt
HTTP/1.0 503 Service Unavailable Cache-Control: no-cache Connection: close Content-Type: text/html <html> <head> <title>503 - Service Unavailable</title> </head> <body> <h1>Your request was blocked.</h1> The proxy you are using prefetches the whole webpage with a very high rate per second. To prevent this DoS attack your request was blocked. <br /> Please contact your IT Administrator. </body> </html>

Sources:
https://www.webmasterworld.com/search_engine_spiders/3749904.htm
http://johannburkard.de/blog/www/spam/Mozilla-4-0-compatible.html

Neuer Backup-Server für die FeM

nospam@example.com (Michael Pfeiffer) — Sun, 26 Apr 2015 21:04:08 +0200

In den letzten Monaten war im Technik-Team der Gedanke gereift, dass zumindest der Ältere unserer beiden Backup-Server in Jahre gekommen ist, und so langsam einmal ersetzt werden sollte. Zudem war er auch vom Energieverbrauch her (bedingt durch den Pentium 4-Prozessor) nicht mehr sinnvoll weiterzubetreiben.

Da das Problem durch Abwarten offensichtlich nicht zu lösen war, wurde ein neuer Backup-Server bestellt, und am 15.4.2015 in einem Betriebsraum im Haus L verbaut. Im Unterschied zum vorherigen Backup-System, der mit einem Gentoo-Linux betrieben wurde, läuft auf dem neuen Server ein FreeBSD, so dass ZFS als Dateisystem benutzt werden kann. Der neuen Server stellt ca. 7 TB Speicherplatz mit doppelter Parität zur Verfügung, was bedeutet, dass von den 6 Datenplatten zwei ausfallen dürfen, ohne dass Daten verloren gehen. Bisher liefern der Mail-Server, der Jabber-Server und die AdminDB ihre Backups per SSH und FTP auf dem System ein. Wenn im Laufe der nächsten Wochen alle Dienste migriert sind, wird der alte Backup-Server abgeschaltet.

Der neue Backupserver (oben), der Vorgänger (Mitte), die zugehörige USV (unten)

Noch ein paar Daten und Fakten zum neuen System:

CPU: Intel Xeon E3-1231 v3

RAM: 16 GiB ECC DDR3

Betriebssystem-HDD: 2x 160 GB (gespiegelt)

Daten-HDD: 6x 2 TB (RAIDZ2)

Netto-Speicherkapazität: 7 TB

Betriebsystem: FreeBSD 10.1

Admins: Bammes, Michael

Zuse-Uplink-Migration am 24.02.2015

nospam@example.com (Michael Pfeiffer) — Wed, 04 Mar 2015 15:31:40 +0100

Pünktlich zu Heiligabend am 24.12.2014 war unser Switch im Zuse-NSP (Cisco WS-C3750G-24) ausgefallen. Dieser stellte den Uplink für alle vom Internet aus erreichbaren FeM-Dienste (Websites, E-Mail, Jabber, ...) zur Verfügung, welche damit nicht erreichbar waren. Bedingt durch die Feiertage konnten wir erst am 29.12. den defekten Switch durch eine spontane Leihgabe des Rechenzentrums ersetzen. Für uns ein Grund mehr, die schon länger fällige Migration in einen anderen Netzbereich des RZs anzugehen.

Am 24.02. um 13:00 wurde dann der Leih-Switch wieder ausgebaut und an das Rechenzentrum zurückgegeben. Die Server im Zuse-NSP wurden umgepatcht und stecken nun direkt auf einer Linecard eines Cisco 4500 des RZs. Dadurch steigt auch die Geschwindigkeit der Anbindung unserer Server von 1 Gigabit auf 2x10 Gigabit. Zeitgleich mussten auch im Medienlabor 2 einige Server, die IP-Addressen aus demselben Subnetz besitzen, migriert werden. Um 13:28 waren die Dienste im Großen und Ganzen wieder verfügbar, und kurz darauf waren auch alle verbleibenden Ruckler beseitigt.

Beteiligte: Bammes, Texec, Pegro, Rafi, Meineeiner, Michael

Hier stecken die Server noch auf dem geliehenen Switch...

Umpatchen auf das Patchpanel.

Ohne Plan is nix... (Bammes und Texec)

Männer, die auf Server starren... (Pegro, Meineeiner, Bammes)

FeM-WLAN Ausbauplanung

nospam@example.com (Michael Braun) — Fri, 17 Oct 2014 14:23:35 +0200

Nachdem ein Teil der AccessPoints nun geliefert ist, schreitet der Ausbau voran.

Aktuell ist Haus P vollständig, im Haus I sind noch 2, im Haus H noch 4 und im Haus K noch 23 AccessPoints zu installieren; diese sind auch als Nächstes für den Ausbau eingeplant.

Voraussetzung für den Ausbau mit FeM-WLAN sind freie LAN-Kabel und die Unterstützung von Strom-über-LAN (POE). Im Haus A, C, D, E, Q, CJD ist POE verfügbar, allerdings fehlen noch Kabel. Im Haus B, L und N sind Kabel verfügbar, aber noch kein POE - was sich jedoch nachrüsten ließe.

Daneben gibt es an ausgewählten Standorten (beispw. in den Clubs) bereits jetzt FeM-WLAN zu empfangen.

Wenn du also Interesse hast, den Ausbau beispw. in deinem Block zu beschleunigen, dann komm doch einfach mal vorbei.

Donnerstags in ungeraden Wochen um 20:30 Uhr im Haus L, Eingang 6d, im Keller.

FeM-WLAN Ausbau

nospam@example.com (Michael Braun) — Wed, 07 May 2014 18:58:58 +0200

Der WLAN-Ausbau auf dem Campus schreitet voran. Nach und nach werden die AccessPoints geliefert, die Software installiert und die Geräte verbaut.

Dafür sind wir auf eure Mithilfe angewiesen, da die AccessPoints in den Fluren der WGs installiert werden sollen! Wir werden euch daher in den kommenden Zeit bei Bedarf persönlich ansprechen oder anschreiben, sofern in eurer WG ein AccessPoint installiert werden soll.

Derzeit ist das Haus I an der Reihe. Außerdem gibt es in den Studentenclubs, im Keller des Haus A, im Interclub, im Haus P, im FeM-Office sowie bei einigen Administratoren bereits FeM-WLAN.

DNS ReBind-Protection mit ISC BIND

nospam@example.com (Michael Braun) — Sun, 15 Dec 2013 21:33:53 +0100

Seit einigen Jahren ist der sogenannte DNS-"ReBind"-Angriff bekannt. Dabei wird ausgenutzt, dass im DNS unerwartete IP-Adressen eingetragen sind, und kann dazu genutzt werden, beispielsweise eine Firewall oder andere Zugriffskontroll-Maßnahmen zu umgehen. Datails dazu unter [1] oder [2] und anderen.

In der Folge kann es ratsam sein, dagegen schützende Filter im lokalen DNS Server einzurichten. Eine andere Möglichkeit besteht darin, den Filter im Browser einzurichten - beispielsweise mit der Firefox-Erweiterung NoScript und ihrem Feature Application Boundary Enforcer (ABE).
"DNS ReBind-Protection mit ISC BIND" vollständig lesen

WPA-PSK - warum eigentlich nur für Heimnutzer?

nospam@example.com (Michael Braun) — Fri, 13 Dec 2013 11:29:41 +0100

WPA-PSK wird nur für Heimnutzer empfohlen, da alle Geräte an einem AccessPoint das gleiche Passwort verwenden - was im Kontext großer Organisationen jedoch nur unzureichende Sicherheit bietet.

So kann jeder Teilnehmer einen eigenen AccessPoint aufsetzen, welcher mit allen anderen Geräten eine Verbindung aufbaut (AP Impersonation), da jeder Teilnehmer das gemeinsame Geheimnis kennt. Dies kann zur Überwachung und Man-In-The-Middle Angriffen genutzt werden.

Weiterhin muss bei Änderungen der Gruppe der Berechtigten allen Teilnehmern ein neues Passwort mitgeteilt werden

und es kann über die verwendeten Zugangsdaten nicht mehr rekonstruiert werden, welcher Nutzer ein bösartiges Gerät genutzt hat.

Für größere Organisationen wird daher WPA-EAP empfohlen, welches neben unbestreitbaren Vorteilen jedoch auch Nachteile hat. Der größte Nachteil ist in meinen Augen, dass beim Einsatz von TTLS-PAP Passwörter ausspioniert werden können sowie AP-Impersonation möglich ist, sofern auf dem Gerät das CA-Zertifikat nicht eingerichtet wurde (oder der Angreifer ein gültiges Server-Zertifikat besitzt). Der Einsatz von TTLS empfiehlt sich jedoch, wenn die Nutzeridentität gegenüber dem AP-Netzbetreiber anonym bleiben soll.

Weniger bekannt ist die Möglichkeit, WPA-PSK mit geräte-spezifischen Zugangsdaten zu betreiben. Dabei wird auf dem AccessPoint jedem Client ein eigenes Passwort zugeordnet, die Identifikation erfolgt anhand der MAC-Adresse des Gerätes. Eine solche Konfiguration wird beispielsweise von hostapd unterstützt, welches in neueren Versionen die WPA-Passphrase auch mittels RADIUS (Tunnel-Passwort Attribut) abfragen kann sowie mehrere Passwörter je Gerät (beispielsweise für mehrere Nutzer) unterstützt. Weiterhin ist es auch möglich, den gleichen Satz Passwörer für alle MAC-Adressen zu erlauben - und so die Vorregistrierung der Geräte überflüssig zu machen und doch nutzerspezifische Passwörter zu verwenden. Nicht implementiert - aber prinzipiell möglich - wäre es sogar, weitere Einstellungen (beispw. VLAN) abhängig von der verwendeten Passphrase anzupassen.

Vorteile:

Keine Fehlkonfiguration am Client möglich - es wird nur die Passphrase für WPA-PSK benötigt.
Automatischer Schutz vor AP-Impersonation und damit ggf. verbundenem Passwortausspionieren, Netzwerküberwachung und Man-In-The-Middle angriffen.

Der vielleicht wichtigste Nachteil dabei ist jedoch, dass das Passwort (im Klartext) an jeden der AccessPoints übermittelt werden muss - ein kompromitierter AccessPoint also die WLAN-Zugangsdaten ausspionieren könnte.

Die hostapd-Implementierung für die Übertragung des PSK mittels RADIUS einschließlich der Unterstützung mehrerer PSKs je Gerät ist übrigens im Rahmen des FeM WLAN Projektes entstanden.

Großer Netzumbau am Uplink-Switch

nospam@example.com (Bernhard Hammes) — Thu, 14 Nov 2013 15:41:32 +0100

Gerbi stellt das Netz ab

Am Dienstag, dem 12.11.2013 trafen sich gegen 07:00 verschlafene FeM-Aktive um den großen angekündigten Netzumbau zu zelebrieren.
Nach etwas koffeinhaltigem Heiß- und zuckerhaltigem Kaltgetränk begab sich die Gruppe zum Haus M, um dem FeM-Netz um 07:30 durch das Herunterfahren von c-fem-1 (dem zentralen Router, aka "der cisco") den temporären Garaus zu machen.
Während die eine Hälfte nun damit beschäftigt war, den Ist-Zustand der Kabelage zu dokumentieren und dann den Cisco abzunabeln, bereitete ein weiteres Team den neuen Netzwerkschrank durch kleine Umbauten auf den Einbau des Routers vor.

Cisco im Landeanflug

Nach einer gefühlten Ewigkeit (gemessen: 1h10m) stand der Router an seinem neuen Platz, der Uplink ins Rechenzentrum nebst der ersten Verbindungen steckte und alles starrte gebannt die Konsole des Routers an.
Nach dem obligatorischen Umstecken (lechts und rings kann man nicht verwechseln!) konnte dann als erster Meilenstein das Studentenwerk wieder ans Netz genommen werden.

Pegro experminentiert mit innovativer Lichtwellen-Technologie

Zeitgleich zum Stecken der weiteren Verbindungen zum Cisco spaltete sich ein kleiner Trupp ab, um in den Betriebsräumen in den Wohnheimblöcken die nötige Steck- und Konfigurationsarbeit zu leisten.
Gegen 10:50 war die Arbeit im Haus M getan und gemeinsam wurden, unterbrochen von einer Mittagspause in der Mensa, in den letzten Blöcken die Uplinks konfiguriert und gesteckt. Leider gab es hier verschiedenste Fehlerquellen (kaputte Fasern zwischen den Häusern, fehlkonfigurierte Switche), was zu weiteren Wegen zwischen den Betriebsräumen führte. Gegen 16:00 stellte sich dann jedoch ein gewisser Erfolg ein und wir konnten schlussendlich in das FeM-Office zurückkehren.
Wieder bei koffeinhaltigen Heiß- und zuckerhaltigen Kaltgetränken wurde dann die getane Arbeit im Wiki dokumentiert und der Arbeitseinsatz beendet.

Hebbet trägt Verantwortung!

Was wurde erreicht:

-Wohnheim H, E, L und P mit 10 Gigabit/s angeschlossen (vorher 1Gigabit/s)
-Wohnheim I mit 3 Gigabit/s angeschlossen (vorher 1Gigabit/s)
-Leute (ohne Internet) zur direkten sozialen Interaktion gebracht
-Leute (ohne Internet) zum Lesen eines Buches gebracht
-Leute (ohne Internet) mit Frischluft vergiftet
-Leute (ohne Internet) zum Lernen gebracht

Der Cisco wieder bei der Arbeit

MySQL- und PostgreSQL-Backup per SSH leichtgemacht...

nospam@example.com (Marcel Pennewiß) — Tue, 11 Dec 2012 17:48:00 +0100

Unzählige Tipps & Tricks kursieren im Internet, wie man denn am besten von einem Server auf dem man SSH-Zugriff einen Dump einer MySQL-Datenbank erstellt. Spätestens wenn man dies regelmäßig tun will kommt man an ein paar vernünftig strukturieren Skriptzeilen nicht vorbei.

Ein ähnliches Problem stellte sich bei der Erneuerung der Infrastruktur unseres Webhostings. Wir haben einen Backup-Server, der sich das Daten-Backup nächtlich vom Webserver abholt. Doch wie macht man nun am besten die Dumps von einem der MySQL-Master-Systeme? Da diese in einem internenen Management-Netz stehen hätte man natürlich einfach nativ mit einem MySQL oder PostgreSQL-Client vom Backupserver darauf zugreifen können, hätte sich dann aber trotzdem was skripten müssen, dass keinen kompletten Dump, sondern einzelne Dumps der Datenbanken erstellt. Letztere waren die Bedingung ans Restore - wenn jemand seine einzelne Datenbank restauriert haben möchte ist ein kompletter Dump mit mehreren Gigabyte nicht unbedingt der Weisheit letzter Schluss Und die Clients wollte man auch nicht zwingend auf dem Backupserver...

Nach anfänglich 2 getrennten Skripten für MySQL und PostgreSQL wurde irgendwann der Entschluss gefasst, dass jetzt mal ordentlich zu machen. Entstanden ist daraus sql-ssh-backup - mittlerweile in Version 1.8 - ein Tool um komfortabel MySQL- oder PostgreSQL-Dumps per SSH zu erstellen. Dabei verwenden wir die auf den zu sichernden Systemen vorhandenen Datenbank-Tools (mysqldump, pgdump) und leiten die Daten gesichert auf den Backupserver. Diese werden anschließend grundlegend geprüft und bei Bedarf gepackt. Im Laufe der Zeit hat dann die ein oder andere Erweiterung noch Einzug gehalten und für neue Ideen, Patches oder Fehlerberichte sind wir immer offen. Diese kann man gern an webserver@fem.tu-ilmenau.de senden.

Die Features in der Übersicht:

Dump für MySQL und PostgreSQL via SSH

benötigt kein MySQL/PostgreSQL auf dem Backup-Server

sichere Übertragung/Nutzung der Datenbank-Zugangsdaten möglich

Einzel- oder Gesamtsicherung aller Datenbanken

Sicherung einzelner Datenbanken

Kompression der Dumps mit bzip2/xz (MySQL) oder PosgreSQL-Dump-Format möglich

mehrere Backups täglich möglich (Verzeichnisstruktur enthält dann Uhrzeit)

automatische Bereinigung von alten Backups

Das unter der GPL-2 lizensierte Skript steht im FeM-Subversion zur Verfügung:
http://subversion.fem.tu-ilmenau.de/repository/fem-overlay/trunk/app-backup/sql-ssh-backup/files/

Und für die Freunde eines "Copy'n'Paste"-HowTo gibt es eine ausführliche Anleitung in unserem Wiki, die auch erklärt, wie der Backup-Nutzer angelegt wird und welche Datenbank-Rechte er benötigt:
http://wiki.fem.tu-ilmenau.de/public/technik/howto/sql-ssh-backup

Viel Spaß damit.

Einmal mit ProPhiS arbeiten

nospam@example.com (Tobias Müller) — Fri, 31 Aug 2012 10:24:47 +0200

Motivierte FeMies haben es geschafft! Eine neue Funkstrecke verbindet die neu errichteten Studentenwohnungen an der Professor-Philippow-Straße (ProPhiS) mit dem Fem-Net.

Bevor wir die Funkstrecke in Betrieb nehmen konnten, mussten viele technische als auch bürokratische Hürden überwunden werden.
Es war quasi ein Hürdenlaufen gegen den Zeitplan des Bauunternehmens.
Und wir sind an der ein oder anderen Hürde hängen geblieben und somit haben wir kein olympisches Gold holen können.

Doch alles der Reihe nach.

Als letztes Jahr mit dem Bau des ersten Gebäudes begonnen wurde, war für uns relativ schnell klar, dass wir diese Wohnheime mit an unser Netz anbinden wollen.
Die Nähe zum Campus und somit auch zum FeM-Net war zu verlockend.
Wir haben daher versucht, das auch dem Bauträger schmackhaft zu machen. Leider war die Kontaktaufnahme nicht von Erfolg gekrönt.
Kurz vor Beginn des Wintersemesters wurde dann auch noch der Parkplatz oberhalb des Haus N neu gepflastert. Wir haben mehr als nur einmal mit dem Gedanken gespielt, diese Situation zu nutzen und zumindest Leerrohr zu verlegen, bevor die Asphaltdecke auf die neu verlegten Fernwärmerohre gezogen wird.
Aber wir haben zu lange überlegt und somit ist das Porjekt bei uns zunächst eingeschlafen.

Die ersten Studenten kamen auf uns zu und wollten wissen, ob wir Ihnen Zugang zum FeM-Net ermöglichen können. Während wir noch über diese Anfrage nachdachten, haben jene Studenten ihre Hausverwaltung gebeten, sich mit uns in Verbindung zu setzen um dieser Anfrage eine offzielle Form zu geben.
Bei den ersten Gesprächen konnten wir uns recht schnell auf die grundlegenden Projektpunkte einigen. Nun musste unsere Idee noch mit dem Rechenzentrum und der Universitätsleitung geklärt werden. Bis zu diesem Zeitpunkt, waren die neuen Wohnheime noch keine offiziellen Gebäude des Campus und somit durften wir diese laut Kooperationsvertrag mit dem RZ nicht ohne weiteres verkabeln. Diese politische Hürde konnte in Gesprächen mit RZ und Rektor schnell ausgeräumt werden und dem Projekt stand nun nichts mehr im Weg.

Technik:
Das Projekt WLAN hatte für die neu gefundenen begeisterten FeMies zwei Testgeräte parat und somit konnten wir sofort loslegen. Es handelt sich um zwei RouterStation PRO von Ubiquiti, die über mehrere Abende mit verschiedenen Anordnungen und Konfigurationen getestet wurden. Mit Datenverlusten mussten wir auch kämpfen, also immer brav Sicherungskopien bereit halten
Wir hatten dabei viel Spaß und speziell die jungen FeM-Techniker haben von den alten Hasen viel gelernt, was nicht heißt, dass auch diesen immer wieder neue Probleme die Köpfe rauchen lassen.
Irgendwann war die Software fertig. Wieder einen Schritt geschafft.
Hardware basteln gehört natürlich auch dazu! Also wurde die empfindliche Hardware in Frischehalteboxen eingepackt, denn diese geben ein gutes Gehäuse für WLAN-APs ab. Schnell noch einige Löcher gebort, ein über USB getrieben Lüfter eingebaut und das luftdurchlässige "Case" Marke Eigenbau war perfekt.
Zum Anbringen der APs kamen wir erstmal nicht....

Anbringen der APs:
Das Anbringen der APs war der dritte Versuch in diesem olympischen Spiel, der zum Glück auch mit Bestmarke gültig war!
... Leider hatten wir bei unserer Planung vergessen, dass wir mit zwei Löcher in der Wand, um den AP an der Wand des Block N zu befestigen – was sich am Ende als unnötig heraus stellte – die Bausubstanz eines Neubaublockes zerstören würden.

WLAN-Accesspoint bei den ProPhiS

Geplante Anbindung an das Fem-Net: 1. Juli.2012
Tatsächliche Anbindung: 26. Juli 2012
Zwei strategisch platzierten Access Points. 6 motivierte FeM-Techniker. 2 StuWe Mitarbeiter

Es ist der 26. Juli, 14 Uhr. Die Mittagssonne scheint und blendet uns, als wir das Dach von Block N betreten. Sowohl die FeM, als auch das Studentenwerk sind vor Ort, um die "Baumaßnahmen" zu koordinieren.
Wow, das ilmenauer Wetter war gut zu uns, viel zu gut. Schweiß war bei der Hitze auf dem Dach garantiert. Eine Hitze auf dem Dach. Zum Glück existiert ein Funkmast mit entsprechender Verkabelung. Diese führt vom Betriebsraum aufs Dach, perfekte Bedingungen, da keine weiteren Bohrungen nötig waren.

Bis jetzt sind die APs trotz des wechselhaftem Ilmenauer Wetters weder geschmolzen noch abgesoffen. Leider können wir keine Temperaturwerte messen, da die entsprechende Sensoren nicht zum funktionieren gebracht werden konnten.

WLAN-Accesspoint auf dem Dach des Haus N

Zwar handelt es sich bei der WLAN-Anbindung der ProPhiS um eine temporäre Lösung, um die Bewohnern ans FeM-Net anzubinden solange noch kein Glasfaserkabel verlegt wurde, jedoch bietet sich für uns die Chance unsere APs endlich unter realen Bedienungen zu testen.
Mit einem Glasfaserkabel, welches verraussichtlich für Ende Sommersemester 2012 (die Baufreigaben von der Stadt und dem Dezernat für Gebäude und Technik liegen uns nun vor) geplant ist, wird die nutzbare Bandbreite natürlich um einiges besser.

Dieses Projekt hat uns aber viel Aufschluss über den Aufbau von Funkstrecken und dem zukünftigen WLAN-Projekt für den Campus gegeben.
Mit anderen Worten: Wir haben vieles gelernt...

Weitere Details finden Nutzer des FeM-Net im vereinseigenen Wiki [http://wiki.fem.tu-ilmenau.de/technik/projekte/prophi]. Alle anderen Interessierten können sich gern per Mail an die Projekt-Mailingliste (projekt-wlan@fem.tu-ilmenau.de) wenden.

FeM verbindet!

Die WLAN Wolke braut sich zusammen...

nospam@example.com (Michael Braun) — Sat, 25 Feb 2012 20:20:55 +0100

FeM-CampusWLAN

Mailingliste:
technik@fem.tu-ilmenau.de

nächstes Treffen:
Donnerstags in ungeraden Wochen
20:30 im FeM-Office
(Haus L, Keller 6d)

Zwei Jahre arbeiten wir nun schon am FeM-WLAN und ihr fragt euch sicherlich, wann ihr es endlich nutzen könnt.

Nun, wir waren nicht untätig, aber die verfügbare Technik erschien uns für unseren Zweck als noch nicht geeignet.
So haben wir in der Zeit zwei kommerzielle Komplettsysteme anhand von Teststellungen evaluiert und verworfen. Außerdem wurden vier weitere Systeme mit Standardhardware aber eigener, angepasster Software (Selbstbaulösung) evaluiert sowie die Verwaltungssoftware auf einen neues Fundament gestellt und für den Betrieb des FeM-WLANs vorbereitet. Bei den kommerziellen Systemen waren Bugs, fehlende Features und mangelnde Stabilität ausschlaggebend, bei unseren Selbstbaulösungen Performanzprobleme.

Aktuell arbeiten wir mit Freescale P1020E-WLAN Geräten und speziell angepasstem OpenWRT. Diese Geräte lieferten in ersten Tests eine zufriedenstellende Geschwindigkeit, bieten hervorragende Linux–Unterstützung und zehn Jahre Verfügbarkeitsgarantie. Ich bin zuversichtlich, dass wir damit im kommenden Sommersemester den ersten Block mit WLAN versorgen können.

Promise VTrak M500i wieder in Takt bringen...

nospam@example.com (Marcel Pennewiß) — Fri, 21 Jan 2011 11:58:55 +0100

FeM hat in den letzten Jahren einige Promise iSCSI-Storagesysteme angeschafft.

Da die Daten auf einem der älteren M500i (Baujahr 2005) sowieso vernichtet und das Gerät als iSTUFF-Archiv eingebunden werden sollte, bot es sich an, das Gerät gleich mit der neuesten Firmware zu versehen. Eines Abends begab es sich also, dass man genau dieses erfolglos versuchte. Das eigentliche Firmware-Upgrade war zwar von Erfolg gekrönt, den anstehenden Reboot überlebte das Gerät aber nicht und beschwerte sich fortan, dass seine RTC-Batterie leer wäre. In diesem Zustand ist eine weitere Nutzung des Gerätes nicht möglich da es sich weigert den Bootvorgang fortzusetzen.

Warning: Real Time Clock battery power is low
Power down and check RTC/NVRAM battery module.
IBL_RAM>

Nicht so schlimm, diese Knopfzelle wird man ja sicherlich einfach tauschen können. Dachten wir uns zumindest.

Also fix den Promise-Support angeschrieben, wo man die denn findet und wie man das Problem löst. Die Antwort kam prompt und die entsprechenden Teile des Promise waren schnell zerlegt. Nur die beschriebene Knopfzelle war nicht so einfach zu finden. Also lieber nochmal Support angeschrieben bevor Ello die Platine komplett zerlegt
Der Support hat sich offensichtlich getäuscht und uns Informationen über das M610i zukommen lassen (nicht weiter tragisch, kann man sicher in Zukunft mal gebrauchen). Laut zweiter Antwort besitzt das M500i eine Knopfzelle (CR1632 in einer Batteriekappe (DS9034PCX)), welche die RTC versorgt. Da das Gerät End-of-Life und außerhalb der Garantie ist, erfolgt der Austausch auf eigene Gefahr. Gesagt, zerlegt, Batterie bestellt, getauscht. Ergebnis: Keine Verbesserung

Also nochmal fix mit dem Support geschrieben und anschließend telefoniert. Ergebnis: Man vermutet, dass der Controller (auf dem die RTC sitzt) defekt ist. Ersatzteile dafür sind nach Promise-eigener Recherche nicht mehr zu bekommen und man würde den Controller auch nur ungern tauschen wollen - es gibt neue Modellreihen, die besser sind, weniger fehleranfällig usw. Promise Deutschland unterbreitete uns daraufhin ein durchaus faires Angebot, wenn wir das M500i gegen ein neues Modell (M610i) "tauschen".

Da unsere Erfahrungen in den letzten Jahren allerdings nicht sonderlich gut waren (von dieser leeren Batterie/defekten RTC über spontane Reboots bis zum kompletten Datenverlust war so ziemlich alles vertreten) würde die Mehrheit der Techniker dem sowieso nicht zustimmen. Und Ello war auch noch nicht so richtig zufrieden mit der Lösung. Also wurde der Controller nochmal erneut zerlegt, der genaue Typ von dem RTC-Chip (DS1556WP-120) aufgeschrieben und ein passendes Ersatzteil (DS1556WP-120+, ROHS) besorgt.

Als die Postfrau endlich zweimal klingelte, ging es ab in die Werkstatt, der Chip wurde gewechselt und der Controller zusammen mit der Tauschbatterie aus dem ersten Versuch wieder komplettiert. Stefan hatte dann die ehrenvolle Aufgabe, das gute Stück auf den Berg ins Medienlabor 2 zu tragen, reinzustecken und das Gerät einzuschalten.

Tata... Es bootete zwar nicht gleich völlig problemlos, weil ihm sämtliche zeitlichen Zusammenhänge verloren gegangen waren. Nachdem wir das Promise zurück ins Jahr 2011 geholt haben, verrichtet es aber wieder froher Dinge seinen Dienst. Mal sehen wie lange

Experimentelles Fernsehn via DVB-T

nospam@example.com (Volker 'cosrahn' Henze) — Wed, 20 Oct 2010 14:27:29 +0200

Sendeturm des Fraunhofer IIS

Am 26.10.2010 startet die FeM e.V. nach langer Vorbereitungszeit das experimentelle Fernsehen via DVB-T. Schon zu Events wie der ISWISION 2007 und ISWISION 2009 sammelten wir Erfahrung mit DVB-T und der dazugehörigen Sende-Technik. Zahlreiche Ideen aus dem Bereich des "etwas anderen Fernsehens" und das Interesse an Sender und Technik ermutigte uns einen DVB-T Sender als Plattform für experimentelles Fernsehen aufzubauen. Während der Planung eines dauerhaften Senders ergab sich die Möglichkeit den Sender auf dem neuen Sendeturm des Fraunhofer IIS zu installieren. Der Standort "Am Vogelherd" ist besonders gut geeignet für solch einen Sender. Von hier kann man mit sehr kleiner Sendeleistung eine hohe Reichweite erreichen und ganz Ilmenau "ausleuchten".

WLAN-Funkstrecke zum DVB-T-Turm

Um Bild, Ton und Daten vom Studio zum Sender zu bekommen verwenden wir WLAN-Funk-Strecken. Mit hoch empfindlichen Antennen und um bei Ausfällen trotzdem senden zu können, wird der Turm von drei Funkstrecken angebunden. Diese Strecken werden im 5GHz WLAN-Band betrieben und verwenden ganz normale WPA2-PSK-Verschlüsselung. Sie bieten genug Bandbreite um den DVB-T-Sender mit den nötigen Datenströmen zu versorgen. Die drei Funkstrecken bilden ein Dreieck zwischen Campus, Pörlitzer Höhe und dem Sendeturm am Vogelherd und versorgen die Ilmenauer Amateurfunker an der Pörlitzer Höhe gleichzeitig mit Netz.

Die Datenströme werden am Turm in einen ASI-Strom gewandelt und mit Hilfe des Kompaktsenders der Firma PLISCH an die Sendeantennen auf dem Turm weitergegeben. Die maximale Leistung des Verstärkers liegt bei 100W wir nutzen aber nur 32 Watt da nicht mehr von unserer Sende-Lizenz abgedeckt wird. Aber schon mit dieser Leistung ist der Empfang unseres experimentellen Fernsehens in Ilmenau möglich. Ob unser Signal auf Kanal 26 auch in den Wohnstuben empfangen werden kann, wissen wir noch nicht, aber wir werden es testen.

Kompaktsender der Firma PLISCH

Die Eröffnungsfeier wird am 26.10.2010 um 16 Uhr am Sendeturm stattfinden. Der HSF und iSTUFF werden dieses Ereignis live übertragen, bei dem der berühmte "Rote Knopf" den Sender in Betrieb nehmen wird. Danach sind alle Gäste zu Bratwurst und Glühwein eingeladen und können den Turm und die Sendetechnik Vor-Ort erleben. Wir freuen uns auf zahlreiche Fragen und reges Interesse rund um den Turm und die Technik.

Sol9-Display - endlich sind die Teile da und es kann getestet werden

nospam@example.com (Matthias Eller) — Fri, 23 Jul 2010 15:38:54 +0200

Leider hat die Lieferung der neuen Platinen etwas länger gedauert, aber sie sind nun schon eine Weile da und ich habe angefangen damit zu experimentieren.

Anfangs war die Ausgangsspannung äußerst unsauber. Nach Untersuchungen mit dem Oszi schien es so, als ob massiv Störungen in die Eingangsspannung eingetreut werden. Zwei Kondensatoren am Eingang als Filter haben aber auch das beseitigt. Damit wird die Unter-/Überspannungsabschaltung nun durch die unsaubere Eingangsspannung nicht mehr verwirrt und tut auch zuverlässig ihren Dienst.

Ein Platz für die Platine wurde schnell gefunden. An dieser Stelle sind auf der Gehäuserückseite Lüftungsschlitze, die notwendig sind, da der Spannungswandler doch recht warm wird.
Weiterhin sind auf der Platine des Displays dort keine Teile im Weg so dass der Zusammenbau problemlos gelingen kann.

Die Hauptstromversorgung des Displays wird direkt dort angeschlossen, wo auch das externe Steckernetzteil Strom ins Display speist.

An dieser Stelle wurde die Stromversorgung der Hintergrundbeleuchtung unterbrochen und der Poweradapter eingeschleift.

Mit dem großen Canon-Akku vom Typ BP-970G läuft das Display 2 Stunden und 15 Minuten mit aktiviertem Video-Eingang. Bei DVB-T dürfte es einiges weniger sein, leider funktioniert das noch nicht zuverlässig. Da wir das Display in Artern morgen aber brauchen, hab ich es erstmal Zusammengesetzt.

Kaum eingetroffen und schon demontiert

nospam@example.com (Matthias Eller) — Tue, 06 Apr 2010 09:29:06 +0200

Ja, so gehört sich das nunmal für einen (angehenden) Ingenieuer.

Es wird ersteinmal alles auseinander geschraubt bevor es in Betrieb geht. Beim mobilen DVB-T und Video-Display SOL9 war das sogar geplant.

Die immerwieder fehleranfälligen Cinch-Buchsen sollen gegen BNC-Buchsen getauscht bzw. ergänzen werden um eine zuverlässige Kontaktierung zu ermöglichen und die stetige Verwendung von Adaptern zu vermeiden, denn bei uns kommt für die Video-Verkabelung sonst nur BNC zum Einsatz. Für diese Buchse gilt es einen passenden Platz im Gehäuse zu finden.

Das Display ist zwar tragbar, allerdings gibt es keine Akkus mehr dafür zu kaufen, da dieses Modell abgekündigt ist. Aber wir sind doch Ingenieure. Bauen wir uns eine eigene Akku-Versorgung. Dazu muss die Elektronik ersteinmal analysiert werden um festzustellen mit welcher Betriebbspannung das Display wirklich läuft.

Auf dem Typenschild ist 10-15V angegeben. Das mitgelieferte Netzteil hat auch eine Ausgangsspannung von 10V.
Ich war damals sehr von den SWIT-Monitoren angetan, die uns die Firma mit dem großen "S" auf dem Ü-Wagen freundlicherweise zur Verfügung gestellt hat. Diese Monitore kann man mit verschiedenen Kamera-Akkus betreiben. Wir hatten das Modell für Canon-Akkus. Da wir bereits 3 Canon-Kameras mit jeder Menge Akkus besitzen liegt es doch nahe, auch unser Display mit einem Canon-Akku zu speisen. Diese Akkus liefern 7,4V. Da die Elektronik höchstwarscheinlich mit 5V oder sogar 3,3V läuft kann das aber eigenlich nicht so kritisch sein. Das Display läuft auch wunderbar mit dieser Betriebsspannung.

Wenn da nicht die Hintergrundbeleuchtung des TFT wäre.

Laut einem Rudimentären Datenblatt läuft diese zwar auch schon bei 6V. In meinen Tests tat sie das aber nicht zuverlässig. Der Controller vom Typ MP1029EM kam nicht richtig ins Schwingen. Das Datenblatt schreibt vor, bei Verwendung von 7V und weniger als Betriebsspannung 2 Dioden einzusetzen. Das half aber nicht weiter. Auch Versuche die Schaltfrequenz zu erhöhen schlugen fehl, weil das Datenblatt zur Dimensionierung der externen Beschaltung des Controller nix aussagte. Der Controller lief nicht richtig an und machte dadurch fürchterliche Geräusche. Diese Geräusche verschwanden erst bei 10V oder mehr Betriebsspannung.
Also blieb nix anderes Übrig, als für die Hintergrundbeleuchtung eine höhere Betriebspannung zur Verfügung zu stellen.

Dafür wurde eine Schaltung entwickelt. Mit Hilfe der Webbench von National Semiconductor ist das recht einfach. Da der Canon-Akku ein Li-Ion-Akku ist, hab ich in die Schaltung gleich noch eine Unterspannungsabschaltung integriert, damit der Akku durch Tiefentladung nicht zu Schaden kommt.
Das alles ist im Wiki ausführlich beschrieben. Sobald das Wiki extern zugänglich ist, wird hier ein Link stehen.

Die Platinen und Bauteile sind bestellt. Sobald die Schaltung aufgebaut ist, gibts einen neuen Artikel.