WLAN Tunings

So manch einer fragt sich sicher :“Warum ist die Banane krumm ?!?“.
Aber darum geht es hier nicht. 🙂
Es soll allerdings die Frage beantwortet werden : „Warum ist mein WLAN so langsam…. ?!?“

Tja, dafuer gibt es viele Gruende….

1. Ein Kabel ist ein kabel.
Wenn es geht, ist natuerlich immer ein Kabel vorzuziehen. Aber in der heutigen Zeit sitzt ja keiner mehr
vor einem PC. Und ein Haendy oder ein Tablet hat halt kaum einen LAN Anschluss; fuer Laptops ist es auch eher unpraktisch.
2. Interferrenzen
Mein Nachbar betreibt ein WLAN auf Kanal 1.
Um keine gegenseitgen Stoerungen zu verursachen, verwende ich, schlau, wie ich bin -> Kanal 2.
-> Super Idee !!!
Nur: leider komplett falsch !
WLAN Kanaele sind mind. 20MHz breit, die einzelnen Kanaele sind aber nur 5MHz auseinander !!!
(Kanal = jeweils die Mitten-Frequenz, +- 10 MHz werden benötigt, beim nächsten AP ist natürlich das gleiche notwendig)
-> Um das WLAN Spektrum im 2,4 GHz Spektrum bestmoeglich auszunutzen, duerfen NUR FOLGENDE KANAELE benutzt werden :
1,5,9,13(*)
Allerdings kommt es noch viiiiel schlimmer :
Soll z.B. ein „300MHz“ WLAN Router verwendet werden, dann benoetigt man (weil man 40 MHz Bandbreite braucht)
natuerlich UNBEDINGT 2 solcher Kanaele.
D.h. es darf dann nur mehr :
1 und 9
verwendet werden !!!!
Hat man einen Nachbarn, der z.B. auf Kanal 6,7 oder 8 sendet, dann hat man verloren. -> max die Haelfte moeglich, weil keine 40 MHz durchgehend vorhanden sind !!!

3. Klingt alles voll super. Ich habe mehrere Accesspoints auf Kanal 1,6,11 laufen. Ist das falsch ?
Falsch ist es nicht.
Aber es nutzt halt nicht alle in Europa verfuegbaren Kanaele aus.
(In Amerika ist nur 1-11 erlaubt, in Europa 1-13)
Das bringt aber unweigerlich das Problem zum Vorschein, dass es in Amerika nur 1(!) Kanal im 2,4 GHz Bereich gibt,
der 40MHz Bandbreite bringt.

Das Schema „1-6-11“ war allerdings frueher auch in Europa ueblich.
Der Grund dafuer ist – ganz einfach – die höhere damals noetige Bandbreie im „alten“ 802.11b (=“11MBit WLAN“).
Die war naemlich 22MHz statt 20MHz.
Dabei galt allerdings das gleiche : Kanal 12,13 war damals nutzlos.

Sind Geraete im Einsatz, die nur fuer den amerikanischen Markt bestimmt sind, dann ist das Kanalschema
„1-6-11“ keine schlechte Option; die Nachbarn wirds aber sicher nicht freuen !!
-> besser auf 1-5-9(-13) bzw. noch besser : NUR 1 oder 9 einstellen !!!

Raspberry PI Basics

Muss man einen Raspberry PI neu aufsetzen, dann stellen sich sofort immer wieder ein paar grundlegende Fragen.
z.B.: „Brauch ich Monitor, Maus, etc. dafuer ?“

Antwort :
Nein. Braucht man nicht. Zumindest nicht ab Raspbian Jessie. (Bei Wheezy gehts braucht man Tastatur&Bildschirm !!) Es ist allerdings ein DHCP Server („Router“) notwendig, mit dem
man moeglichst einfach die IP des PIs herausfinden kann.

-> z.B. mit Win32DiskImager ein frisches Image auf die SD/microSD Karte schreiben, den PI mit
der Karte ans LAN+Strom anschliessen, und etwas warten.

Dann kann man sich per SSH (mit der IP, die man aus dem Router herausfinden muss) einloggen.
Username : pi
Passwort : raspberry

Als erstes mit „passwd“ gleich mal ein Passwort fuer den „pi“-User setzen.
Mit „sudo -i“ wechselt man zum Root-User. Beim ersten Mal wird gleich „rapsi-config“ aufgerufen.
Damit kann man so grundlegende Dinge machen, wie z.B. Dateisystem vergroessern, Hostname setzen, etc…
(Zumindest dann,) wenn das Dateisystem vergroesser werden soll, ist ein erstmaliger Reboot notwendig.

Um was vernuenftiges machen zu koennen, emfiehlt nach dem ersten reboot folgendes :

apt-get update
apt-get upgrade -y
apt-get install vim screen tightvncserver mc -y

Ist man sich nicht sicher, ob man vom DHCP jedes mal die gleiche IP bekommen wird (nachdem die lease-time abgelaufen ist),
dann sollte auf jeden Fall eine fixe IP eingestellt werden. (Ausserhalb des DHCP IP Ranges, ebenfalls im Router nachzuschaun) :
vi /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
gateway 192.168.1.1
#pre-up iptables-restore > /etc/resolv.conf
echo „nameserver 8.8.4.4“ >> /etc/resolv.conf
Das mit den Name-Servern ist aber leider nicht Reboot-Resisdent.
-> Am besten in die /etc/rc.local vor dem „exit 0“ einbauen.

Damit werden die am haeufigsten beschriebenen Verzeichnisse in eine RAMDisk gelegt :
echo „tmpfs /tmp tmpfs defaults,noatime,nosuid,size=100m 0 0“ >> /etc/fstab
echo „tmpfs /var/tmp tmpfs defaults,noatime,nosuid,size=30m 0 0“ >> /etc/fstab
echo „tmpfs /var/log tmpfs defaults,noatime,nosuid,mode=0755,size=100m 0 0“ >> /etc/fstab
echo „tmpfs /var/run tmpfs defaults,noatime,nosuid,mode=0755,size=2m 0 0“ >> /etc/fstab

Das hat nicht nur den Vorteil, dass die SD Karte kaum mehr verschleissen wird; ausserdem wird der PI
dadurch recht unempfindlich gegen Stromausfaelle, da ja kaum mehr Dateien schreibend geoeffnet sind.
(zumindes nicht auf der Karte). Log-Files sind halt dann weg… (!auch bei einem ordnungsgemaessen reboot!)

Anm.: hat man das gemacht, kommt es bei einigen Diensten zu Problemen.
z.B. apache startet nach einem reboot nicht mehr (obwohl man es ordnungsgemaess installiert hat, und es vor
dem Reboot auch problemlos funktioniert hat).
Der Grund dafuer ist ganz einfach :
Das Verzeichnis /var/log/apache2 wird bei der installation angelegt, aber NICHT bei einem Reboot.
Abhilfe :
vi /etc/init.d/apache2
/start)
und direkt danach :
mkdir -p /var/log/apache2

Dann kann man – ganz einfach – mit :
„service apache2 start“

testen, ob es wieder klappt.

Update !!!!!!

Beim Raspbian Jessie sind per default schon einige Verzeichnisse als RAMDisk gemountet.
Da darf nur mehr /var/log und /tmp in die fstab eingetragen werden !!!
Das ist natuerlich z.B. bei einem Upgrade unbedingt zu beachten !!

Random Number Generator

modprobe bcm2708-rng
echo „bcm2708-rng“ >> /etc/modules

ssh mit ROOT
Es ist zwar ein tolles Feature, dass man sich als „root“ per ssh nicht einloggen kann,
sondern erst nach dem Login z.B. via „sudo -i“ den user wechselt, allerdings hat das
(solange der PI sowieso nicht via oeffentlicher IP aus dem Inernet erreichbar ist)
und natuerlich, solange man den „pi“ – user weiterverwendet keinerlei Sicherheitsvorteile.
Das Schaltet man ab mit:

In der /etc/ssh/sshd_config

PermitRootLogin without-password
Aendern in :
PermitRootLogin yes

service ssh restart

ssh ohne DNS
Dauert es recht lange (ca. 5 Sekunden) zwischen Username und Passwort Abfrage beim Login via ssh,
dann liegt es meisst an einem DNS-Feature.
Um das abzustellen :

echo „UseDNS no“ >> /etc/ssh/sshd_config
service ssh restart

PI Nachteile :

*) Fehlende Echtzeit Uhr (da gaebe es allerdings was zum Basteln… evtl. auch mit DCF77 ?!?)
*) Fehlende SATA Anschluesse
*) LAN nur 100MBit (und intern nur via USB angeschlossen) -> hohe CPU Last !!
*) Stromversorgung via Micro-USB Netzteil (damit sind die 4 USB Anschluesse des B+ und B2 nur recht eingeschraenkt nutzbar)
*) KEIN GBitLAN/KEIN USB3 !!
*) MicroSD (geht aber trotzdem recht zuverlaessig) besser waere aber sicher ein int. 4 oder 8 GB Flash
oder alternativ : 2 Einschuebe, mit denen man ein RAID machen kann !!!
*) „Bootloader“ auf einer FAT (!!!!) Partition -> ging zumindest zu Anfangszeiten schon mal „kaputt“ !!
ist DAS im Jahre 2015 notwendig ?!?

Am Raspberry PI eine USB Webcam betreiben

Dafuer gibt es unzaehlige Anleitungen im Internet. Die meissten davon funktionieren
aber nicht, oder nicht ordentlich.

Grundsaetzlich gibt es 2 vielversprechende Programme dafuer :

motion -> braucht aber recht viel CPU (kann theoretisch auch mehr; z.B. aufzeichnen, sobald sich was bewegt…)
mjpegstreamer -> besser aber nur mit Tricks optimal :

Wenn man den einfach so kompiliert, dann funktioniert die „mjpeg“ Option nicht.
Die Webcam geht nur mit dem „-y“ Parameter; sie liefert dann „raw“ – Bilder
an die CPU und die CPU muss daraus den Mpeg Stream erzeugen.
Beim PI2 mit seinen 4 Kernen ist das zwar nicht schlimm, aber schoen ist es auch nicht.
(1 Kern zu 100% ausgelastet)
Beim PI1 ist das natuerlich voelliger Non-Sense. In diesem Fall waere der PI natuerlich fuer andere Einsatzzwecke
kaum mehr zu gebrauchen.

Nach einiger Recherche hab ich dafuer aber einen Patch gefunden unter :
https://www.raspberrypi.org/forums/viewtopic.php?t=97983

Damit klappts dann auch ohne „-y“; die Kamera liefert dann direkt komprimierte Bilder zur CPU.
-> CPU Last = 1% beim PI1; 0,3% beim PI2

Allerdings es es halt doch einiges an Aufwand, alles korrekt zusammenzusuchen, zu patchen etc.

Drum hab ich mein gepatchtes Build-Verzeichnis mal gepackt, und hier nochmal hochgeladen.
Dann gehts einfacher :

apt-get update
apt-get install libjpeg8-dev imagemagick libv4l-dev
ln -s /usr/include/linux/videodev2.h /usr/include/linux/videodev.h
mkdir -p /install
cd /install
wget http://downloads.walterschlag.net/mjpg-streamer.tgz
tar xfz mjpg-streamer.tgz
cd mjpg-streamer
make clean # Fuer den Fall, dass schon mal kompiliert wurde …
make

In der Datei „start.sh“ finden sich nun einige Beispiele, wie der Streamer zu starten ist.
Mein Start Script sieht so aus :

#!/bin/sh
cd /install/mjpg-streamer
export LD_LIBRARY_PATH=“/install/mjpg-streamer“
./mjpg_streamer -i „input_uvc.so -d /dev/video0 -r 1280×960 -f 5“ –output „output_http.so -c BENUTZERNAME:PASSWORT -w www/“ &

Und wird – ganz einfach – ueber die /etc/rc.local mitgestartet …

Seagate Goflex serielle Verbindung

So schön und toll wie embedded Linux Systeme auch immer sind, hin und wieder ist halt leider doch eine serielle Konsole notwendig.
Vorallem z.B. dann, wenn man so ein System auf ein neues kopiert.
Dann ist man froh, wenn z.B. aus China ein USB-Serial adapter mit 3,3V TTL Signalen bereit liegt :

image

image

image

In meinem Fall hab ich damit herausgefunden, dass sich der Name der Netzwerkschnittstelle geändert hat.
eth0 -> eth1
Dadurch war das Gerät natürlich nicht mehr erreichbar…

USV Bypass

Warum bin ich da drauf nicht gleich gekommen ?!? Hab für meine USV Versorgung einen Bypass gebaut. Ist ein zweipoliger Wechselschalter in einer Feuchtraumdose.
So kann ich jetzt ohne Unterbrechung die USV entnehmen, testen, reparieren u.ä. falls es notwendig ist.