FeM Blog (Artikel mit Tag wlan)

HowTo enable WiFi roaming with hostapd and VLANs

nospam@example.com (Michael Braun) — Tue, 03 Nov 2015 21:13:00 +0100

A WiFi client is usually connected to an AccessPoint for WPA-protected network access. When the AccessPoint becomes unreachable for example as the client moved, the client needs to switch over to an other AccessPoint providing the same extended service set (ESSID). This is called roaming.

Roaming involves the following steps:

Scanning for an other reachable AccessPoint (Probe)
Disconnect from the old AP
Changing the WiFi-channel
Authentication and Association
WPA-EAP-Handshake (only for 802.1X)
4-way WPA handshake
Connection is ready again

These steps need time and the client is disconnected until he completed them, but there are some options available to speed things up: "HowTo enable WiFi roaming with hostapd and VLANs" vollständig lesen

HowTo enable address sanitizer with OpenWRT

nospam@example.com (Michael Braun) — Thu, 14 May 2015 20:17:05 +0200

When debugging program crashes, memory misuse debuggers become handy. AddressSanitizer [1] is implemented by the compiler (both gcc and clang support it), where each memory access is first checked against some state information that indicate whether the address is safe to access (e.g. malloc'ed and not freed). The state information is maintained by some library called libasan.so or libsanitizer, and all programms compiled with address sanitizer support need to be linked (statically or dynamically) against it.

To get a program with address sanitizer support compiled in, it needs the following flags:



  TARGET_CPPFLAGS += -fsanitize=address -fno-omit-frame-pointer

  TARGET_CFLAGS += -fsanitize=address -fno-omit-frame-pointer

  TARGET_LDFLAGS += -lasan -fsanitize=address

  TARGET_LDFLAGS_C += -lasan -fsanitize=address

So the toolchain (gcc) needs to be compiled with support for compiling for address sanitizer, that is using gcc "--enable-sanitizer" configure argument. The trouble with OpenWRT is that it uses uClibc, so libsanitizer does not compile out of the box against it. Additionally, libasan.so needs to be packed (it depends on libstdcpp) and packets compiled with address sanitizer need to depend on libasan, thought that was not that much of an issue.

So how can one enable libsanitizer with uclibc? The following steps are for toolchain gcc 4.8, gcc 4.9 will be more difficult because its extra features result in more (conflicting) dependencies.

patch gcc 4.8 to avoid using __libc_malloc as uClibc does not provide this [2]
change OpenWRT toolchain Makefiles to enable sanitizer support for gcc
diff --git a/toolchain/gcc/final/Makefile b/toolchain/gcc/final/Makefile index 3fb5ccf..4fae52f 100644 --- a/toolchain/gcc/final/Makefile +++ b/toolchain/gcc/final/Makefile @@ -4,7 +4,7 @@ include ../common.mk GCC_CONFIGURE += \ --with-headers=$(TOOLCHAIN_DIR)/include \ - --disable-libsanitizer \ + --enable-libsanitizer \ --enable-languages=$(TARGET_LANGUAGES) \ --enable-shared \ --enable-threads \ @@ -58,7 +58,7 @@ endef define Host/Install $(CleanupToolchain) - $(_SINGLE)$(GCC_MAKE) -C $(GCC_BUILD_DIR) install + $(_SINGLE)$(GCC_MAKE) -C $(GCC_BUILD_DIR) install install-target-libsanitizer # Set up the symlinks to enable lying about target name. set -e; \ (cd $(TOOLCHAIN_DIR); \ diff --git a/toolchain/gcc/minimal/Makefile b/toolchain/gcc/minimal/Makefile index 0344e1a..e14f64a 100644 --- a/toolchain/gcc/minimal/Makefile +++ b/toolchain/gcc/minimal/Makefile @@ -6,7 +6,7 @@ GCC_CONFIGURE += \ --with-newlib \ --without-headers \ --enable-languages=c \ - --disable-libsanitizer \ + --enable-libsanitizer \ --disable-libssp \ --disable-shared \ --disable-threads @@ -30,11 +30,11 @@ define Host/Prepare endef define Host/Compile - +$(GCC_MAKE) $(HOST_JOBS) -C $(GCC_BUILD_DIR) all-gcc all-target-libgcc + +$(GCC_MAKE) $(HOST_JOBS) -C $(GCC_BUILD_DIR) all-gcc all-target-libgcc all-target-libsanitizer endef define Host/Install - $(GCC_MAKE) -C $(GCC_BUILD_DIR) install-gcc install-target-libgcc + $(GCC_MAKE) -C $(GCC_BUILD_DIR) install-gcc install-target-libgcc install-target-libsanitizer endef define Host/Clean
fix uClibc to pass the sixth syscall argument to the kernel on powerpc (as my platform is powerpc) (or you will get "failed to mmap" errors)
--- uClibc-0.9.33.2/libc/sysdeps/linux/powerpc/syscall.S 2015-05-14 09:24:29.299815401 +0200 +++ uClibc-0.9.33.2/libc/sysdeps/linux/powerpc/syscall.S 2015-05-14 09:24:41.187991584 +0200 @@ -30,6 +30,7 @@ mr 5,6 mr 6,7 mr 7,8 + mr 8,9 sc bnslr;
add libasan to OpenWRT packages
diff --git a/package/libs/toolchain/Makefile b/package/libs/toolchain/Makefile index 42b9935..aad3d3c 100644 --- a/package/libs/toolchain/Makefile +++ b/package/libs/toolchain/Makefile @@ -133,6 +133,34 @@ define Package/libstdcpp/config endef +define Package/libasan +$(call Package/gcc/Default) + NAME:=libasan + TITLE:=GNU Standard ASAN Library v3 + DEPENDS=+libstdcpp +endef + +define Package/libasan/config + menu "Configuration" + depends on EXTERNAL_TOOLCHAIN && PACKAGE_libasan + + config LIBASAN_ROOT_DIR + string + prompt "libasan shared library base directory" + depends on EXTERNAL_TOOLCHAIN && PACKAGE_libasan + default TOOLCHAIN_ROOT if !NATIVE_TOOLCHAIN + default "/" if NATIVE_TOOLCHAIN + + config LIBASAN_FILE_SPEC + string + prompt "libasan shared library files (use wildcards)" + depends on EXTERNAL_TOOLCHAIN && PACKAGE_libasan + default "./lib/libasan.so.*" + + endmenu +endef + + define Package/libc/Default SECTION:=libs CATEGORY:=Base system @@ -420,6 +448,11 @@ ifeq ($(CONFIG_EXTERNAL_TOOLCHAIN),) $(CP) $(TOOLCHAIN_DIR)/lib/libstdc++.so. $(1)/usr/lib/ endef + define Package/libasan/install + $(INSTALL_DIR) $(1)/usr/lib + $(CP) $(TOOLCHAIN_DIR)/lib/libasan.so. $(1)/usr/lib/ + endef + use_libutil=$(if $(CONFIG_EGLIBC_OPTION_EGLIBC_UTMP),libutil) use_libnsl=$(if $(CONFIG_EGLIBC_OPTION_EGLIBC_NIS),libnsl) use_nsswitch=$(if $(CONFIG_EGLIBC_OPTION_EGLIBC_NSSWITCH),libnss_dns libnss_files) @@ -568,6 +601,15 @@ else exit 0 endef + define Package/libasan/install + for file in $(call qstrip,$(CONFIG_LIBASAN_FILE_SPEC)); do \ + dir=`dirname $$$$file` ; \ + $(INSTALL_DIR) $(1)/$$$$dir ; \ + $(CP) $(call qstrip,$(CONFIG_LIBASAN_ROOT_DIR))/$$$$file $(1)/$$$$dir/ ; \ + done ; \ + exit 0 + endef + define Package/libstdcpp/install for file in $(call qstrip,$(CONFIG_LIBSTDCPP_FILE_SPEC)); do \ dir=`dirname $$$$file` ; \ @@ -638,6 +680,7 @@ $(eval $(call BuildPackage,libgcc)) $(eval $(call BuildPackage,libatomic)) $(eval $(call BuildPackage,libssp)) $(eval $(call BuildPackage,libstdcpp)) +$(eval $(call BuildPackage,libasan)) $(eval $(call BuildPackage,libpthread)) $(eval $(call BuildPackage,libthread-db)) $(eval $(call BuildPackage,librt))
fix malloc being called from within malloc replacement function indirectly due to stack unwinding needing it (similar to [3], but that patch does apply to gcc 4.8 ). This patch might lose backtraces when used with threaded applications.
--- gcc-linaro-4.8-2014.04/libsanitizer/sanitizer_common/sanitizer_linux.cc.orig 2015-05-15 09:50:10.190769407 +0200 +++ gcc-linaro-4.8-2014.04/libsanitizer/sanitizer_common/sanitizer_linux.cc 2015-05-15 09:50:52.503376258 +0200 @@ -494,9 +494,13 @@ } void StackTrace::SlowUnwindStack(uptr pc, uptr max_depth) { + static int nested = 0; this->size = 0; + if (nested) + max_depth = 0; this->max_size = max_depth; if (max_depth > 1) { + nested++; _Unwind_Backtrace(Unwind_Trace, this); // We need to pop a few frames so that pc is on top. // trace[0] belongs to the current function so we always pop it. @@ -507,6 +511,7 @@ else if (size > 4 && MatchPc(pc, trace[4])) to_pop = 4; else if (size > 5 && MatchPc(pc, trace[5])) to_pop = 5; this->PopStackFrames(to_pop); + nested--; } this->trace[0] = pc; }
fix register usage in asan (or you'll see all kinds of false-positive errors): [3] (the changelog part is not required)
recompile OpenWRT from the scratch or atleast
make toolchain/gcc/final/clean make toolchain/gcc/final/install make toolchain/uClibc/clean make toolchain/uClibc/install
change and possibly recompile the packages you need address sanitizer support with (mind the libraries!)

When recompiling uClibc, make sure that all copies of libuClibc-0.9.33.2.so got updated, or you might end up with a copy that does not have the syscall function fixed. If not fixed, when stracing, you will see the last argument of mmap2 to be 0xffffffff or alike; and program startup will fail with "mmap failed".

With this, I finally got hostapd on an embedded device running and found the memory corruption bug I introduced by accident.

[1] http://en.wikipedia.org/wiki/AddressSanitizer
[2] http://patchwork.ozlabs.org/patch/233933/
[3] https://github.com/gcc-mirror/gcc/commit/a15fa55a4a13bde63a86422bba672b3af8232a31

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.

HTML5 WLAN-Speedtest

nospam@example.com (Michael Braun) — Tue, 12 Aug 2014 11:30:41 +0200

Wie ermittelt man eigentlich aus dem Browser heraus, wie schnell gerade das WLAN ist? Diese Frage stellte sich uns, bei dem Versuch, über eine Webseite den Nutzern die Möglichkeit einzuräumen, uns Feedback zur FeM-WLAN Qualität und -Empfang zu geben. "HTML5 WLAN-Speedtest" vollständig lesen

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.

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.

Das Campus-WLAN kommt

nospam@example.com (Michael Braun) — Wed, 31 Jul 2013 19:35:39 +0200

Seit Anfang Mai steht unseren studentischen Mitgliedern auf dem Hans-Stamm-Campus der TU-Ilmenau neben dem kabelgebundenen Zugang zum Forschungsnetzwerk auch ein drahtloser Zugang in den Studentenclubs des ILSC e.V. sowie im Haus P zur Verfügung. Mittels WLAN können nun also auch mobile Geräte wie Smartphones oder Tablet-PCs zur Internetrecherche für Studium und private Zwecke genutzt werden. Es ist geplant, das WLAN in den kommenden drei Jahren auf alle Ilmenauer Wohnheime des Studentenwerkes Thüringen auszuweiten.
"Das Campus-WLAN kommt" vollständig lesen

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.

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.

Radius mit LDAP und Gruppen

nospam@example.com (Michael Braun) — Fri, 06 Aug 2010 14:16:05 +0200

Auch auf dem Campus gibt es verschiedene WLANs und noch immer sind einige WLANs von Vereinen und anderen Organisationen mit einem Passwort gesichert, welches allen Teilnehmern bekannt sein muss (shared secret). Soll ein Teilnehmer ausgeschlossen werden oder dieses Passwort geändert, müssen alle neuen Teilnehmer informiert werden. Außerdem lässt sich nur schlecht nachvollziehen, wer das Netz wann genutzt hat. Dies ließe sich jedoch vermeiden, indem diese auf WPA2-Enterprise umgestellt würde. Ein wichtiger Schritt dabei ist die Einrichtung eines Radius-Servers, über den die WLAN-Nutzer authentifiziert werden können.

Was soll erreicht werden:

Anbindung an zentrales Login (LDAP),

Zugriffssteuerung über Gruppen,

verschlüsselte Kommunikation zwischen Laptop und Radius-Server.

Was ist schon da:

zentraler LDAP-Server für Benutzer (posixAccount) und Gruppen (posixGroup mit memberUid),

Proxy-Login zum Abrufen der Benutzerdaten,

AccessPoint mit WPA2-Enterprise und Radius-Unterstützung,

sonstige Netzinfrastruktur.

Am einfachsten installiert man nun auf einem Linux-Server Freeradius (2.1.8 ) (mit LDAP- und EAP-Unterstützung).
Unter Ubuntu Lucid sind dies die Pakete freeradius und freeradius-ldap.
Es müssten nun folgende Änderungen an der Standardkonfiguration vorgenommen werden. Angegeben sind nur die Veränderungen, d.h. alle anderen Zeilen bleiben unverändert in den Dateien erhalten.



# /etc/freeradius/modules/ldap

ldap { 

        server = "127.0.0.1" # IP des LDAP Servers

        identity = "cn=proxy,..." # Proxy-Nutzer

        password = "..." # Passwort des Proxy-Nutzers

        basedn = "dn=base" # Suchbasis des LDAP

        filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})" 

        base_filter = "(objectclass=posixAccount)" # nur posixAccount Nutzer (keine Windows-Machinen)

        groupname_attribute = cn

        groupmembership_filter = (&(objectClass=posixGroup)(memberUid=%{Stripped-User-Name:-%{User-Name}})) 

}



# /etc/freeradius/sites-enabled/default

authorize {

        #files

        #unix

        eap {  

                ok = return

        }

        ldap

}

authenticate {

        Auth-Type LDAP {

                ldap

                if (LDAP-Group == "wireless") {

                        noop

                }

                else { 

                        reject

                }

        }

        eap

}

post-proxy {

        eap

}



# /etc/freeradius/sites-enabled/inner-tunnel

authorize {

        #files

        #unix

        ldap

}

authenticate {

        Auth-Type LDAP {

                ldap

                if (LDAP-Group == "wireless") {

                        noop

                }

                else { 

                        reject

                }

        }

}

In /etc/freeradius/certs müssen Serverzertifikate hinterlegt werden (die Dateinamen stehen in der eap.conf),
diese können beispielsweise mit OpenSSL erstellt werden (Anleitung: http://sial.org/howto/openssl/self-signed/).

Weiterhin müssen noch die APs (hier im Subnetz 192.168.0.0/16) eingetragen werden:



# /etc/freeradius/clients.conf

client localhost {

 ipaddr = 127.0.0.1

 secret = ganzGeheim

}

client 192.168.0.0/16 { # Subnetz der APs

        secret          = ganzganzgeheim

        shortname       = accesspoints

}

.

Nun kann man den Freeradiusserver starten und am AccessPoint dessen IP und das secret einstellen.
Um Nutzern den Zugang zum WLAN zu gewähren, müssen diese sich in der Gruppe wireless befinden und einen WPA2-Enterprise fähigen Clienten benutzen. Linux-Distributionen bringen diese normalerweise mit, unter Windows funktionieren SecureW2 oder wpa_supplicant.

Zum Testen und zur Fehlersuche des Radiusservers sollte Freeradius im Debug-Modus gestartet (freeradius -Xxx),
sehr nützlich sind dabei die Tools radtest und eapol_test. Dabei ist radtest im freeradius-Paket enthalten und
selbstdokumentierend, die Verwendung von eapol_test wird auf http://deployingradius.com/scripts/eapol_test/ beschrieben.