Some time ago I wrote about my issues with NAT not working as expected on my multi-uplink OpenWRT-based always-on access point. Pondering one night in Austria about it (I was preparing it for the trip home), I think I finally solved the issue.
Continue reading
Category Archives: OpenWRT
Von Entertain, Rechten und meinen Visionen
Ich muß mal wieder etwas Luft ablassen, eine Kategorie »Contentmafia« ist wohl langsam überfällig … Wie dem auch sei, die Vorstellung von »Entertain to go« möchte ich zum Anlaß nehmen, ein bißchen über das technisch machbare, aus meiner Sicht notwendige Grenzen der Einflußnahme der Rundfunkanstalten sowie meine Visionen hinsichtlich des Medienkonsums (Schwerpunkt Bewegtbild; Musik ist abgedeckt durch Squeezecenter und -player) zu reden.
Continue reading
NAT or no-NAT — what the firetruck?
I have to admit defeat. Yes, I’m out of ideas currently …
Thing is: I have three TL MR-3020 (well, 2 3020 and one 3040 right now, but they should be identical except for the lack of buttons and the existence of a battery in the 3040 case), all running, installed from a local copy of the repository, …
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
ATTITUDE ADJUSTMENT (Bleeding Edge, r32930)
-----------------------------------------------------
* 1/4 oz Vodka Pour all ingredients into mixing
* 1/4 oz Gin tin with ice, strain into glass.
* 1/4 oz Amaretto
* 1/4 oz Triple sec
* 1/4 oz Peach schnapps
* 1/4 oz Sour mix
* 1 splash Cranberry juice
Caught in the act ;)
My little webcam project today caught this:
TL-MR 3020 as a webcam server
Took me a while, but I’m now rather confident that the issues I was having with the MR3020 as a mjpg-streamer powered streaming webcam server are related to the camera(s) used, not (only) to the tiny box. As you can see below, “only” in daylight the images gets distorted:
As of now I assume that the framerate reported by the camera is responsible for this, as that cam is reporting only 30 fps for all resolutions. It’s working nicely on a SheevaPlug with full-blown Debian, but Sheeva is a different hardware to the MR3020 (and 3 to 5 times as expensive per box); I might try a Dockstar as the host for this cam, but time will tell.
Just FTR, with a quickly ordered Logitech C270 HD, the MR320 is serving just nicely as a streaming webcam server (cam reports 5 and 10 fps for 1280×720, I choose 5, which is sufficient for now):
Webcam server with TL-MR 3020?
Hmm. Previously, I build two nice webcam-servers out of Fonera 2.0g boxes (German posts: 1 & 2). cpuinfo of the Foneras is as follows:
root@cam-serv3:~# cat /proc/cpuinfo system type : Atheros AR2315 processor : 0 cpu model : MIPS 4KEc V6.4 BogoMIPS : 183.50 wait instruction : yes microsecond timers : yes tlb_entries : 16 extra interrupt vector : yes hardware watchpoint : no ASEs implemented : shadow register sets : 1 core : 0 VCED exceptions : not available VCEI exceptions : not available
There I run two jobs, for /dev/video0 and /dev/video1, of mjpg_streamer -i input_uvc.so -f 10 -r 960x720 ..., which results in this top output:
Mem: 19836K used, 10080K free, 0K shrd, 1140K buff, 6096K cached CPU: 19% usr 11% sys 0% nice 1% idle 0% io 31% irq 34% softirq Load average: 2.57 2.51 2.45 PID PPID USER STAT VSZ %MEM %CPU COMMAND 1518 1064 root R 8732 29% 33% mjpg_streamer -i input_uvc.so -d /dev 1517 1060 root R 8572 29% 26% mjpg_streamer -i input_uvc.so -f 10 - 1065 1064 root R 8732 29% 20% mjpg_streamer -i input_uvc.so -d /dev 1061 1060 root S 8572 29% 7% mjpg_streamer -i input_uvc.so -f 10 - 1577 1520 root R 1960 7% 6% top -d 2 1519 933 root S 1996 7% 1% /usr/sbin/dropbear -p 22 1064 1058 root S 8732 29% 0% mjpg_streamer -i input_uvc.so -d /dev 1058 1 root S 8732 29% 0% mjpg_streamer -i input_uvc.so -d /dev 1067 1064 root S 8732 29% 0% mjpg_streamer -i input_uvc.so -d /dev 1060 1056 root S 8572 29% 0% mjpg_streamer -i input_uvc.so -f 10 - 1056 1 root S 8572 29% 0% mjpg_streamer -i input_uvc.so -f 10 - 1066 1060 root S 8572 29% 0% mjpg_streamer -i input_uvc.so -f 10 - 1055 1 root S 1976 7% 0% udhcpc -t 0 -i ath0 -b -p /var/run/at 520 1 root S 1972 7% 0% udhcpc -t 0 -i eth0.1 -b -p /var/run/ [...]
Recently I joined the MR3020 hype, them being quite similar to the Fonera 2.0g systems, i. e. Atheros-based, supported by OpenWR, rather cheap (<30 EUR) and with USB; only drawback is the ridiculously small on-board Flash:
root@cam-serv5:~# cat /proc/cpuinfo system type : Atheros AR9330 rev 1 machine : TP-LINK TL-MR3020 processor : 0 cpu model : MIPS 24Kc V7.4 BogoMIPS : 265.42 wait instruction : yes microsecond timers : yes tlb_entries : 16 extra interrupt vector : yes hardware watchpoint : yes, count: 4, address/irw mask: [0x0000, 0x0280, 0x05d0, 0x0630] ASEs implemented : mips16 shadow register sets : 1 kscratch registers : 0 core : 0 VCED exceptions : not available VCEI exceptions : not available
But to my big disappointment, running even only one process of mjpg_streamer, /usr/bin/mjpg_streamer --input input_uvc.so --device /dev/video0 --fps 1 --resolution 1280x720 ..., seems to max the system out, and anything above 1 fps, I tested 2, 5, 10, gives quite chopy images, distorted in odd ways. top says:
Mem: 25868K used, 3308K free, 0K shrd, 1412K buff, 5392K cached CPU: 0% usr 0% sys 0% nic 97% idle 0% io 0% irq 0% sirq Load average: 0.06 0.11 0.11 1/41 1542 PID PPID USER STAT VSZ %VSZ %CPU COMMAND 1514 1 root S 24424 84% 0% /usr/bin/mjpg_streamer --input input_ 1541 1431 root R 1496 5% 0% top -d 2 1430 1362 root S 1216 4% 0% /usr/sbin/dropbear -P /var/run/dropbe 1431 1430 root S 1504 5% 0% -ash 592 1 root S 1504 5% 0% /sbin/syslogd -C16 1140 1 root S 1504 5% 0% /sbin/udhcpc -t 0 -i wlan0 -b -p /var ...
So, it does not seem to be a CPU limitation; the CPU should be even more powerful than the Fonera’s, and the minor increase in resolution, 1280×720 instead of 960×720, should be compensated by far by the two USB cams served by the Fonera. Any opinions or tips?
Schnee-Timelapse, die nächste ;)
Eigentlich war ich im Begriff, die lustigen Skripte, die mir aus vielen Teilen der Welt Webcam-Bilder archivieren, zu deaktivieren und die paar hundert GB zu recyclen, als doch noch mal was Sehenswertes über Deutschland passierte: Schnee im (meterologischen) Frühling — ansich nichts ungewöhnliches, denn, wie ich seit Jahren eine alte Weißheit wiederhole: »zur CeBIT schneit’s nochmal«.
Naja, wie dem auch sei, viel Spaß mit dem Zeitraffer zum neuerlichen Wintereinbruch über Ostwestfalen ;)
Wie Miss #Daisy uns hängen lies …
Tja.
All den guten Ratschlägen zum Trotz: weder hundert heiße Ladenhüterdecken konnte man gestern an den Mann oder die Frau bringen noch stellte sich der herbeigeredete Stillstand Deutschlands durch Schnee im, Obacht!, Winter ein. Ja, es war frisch; nicht kalt, die Kälte war nur gefühlt. Durch den Wind. Der, zumindest in Mediatown City, eher mehr so spürbar war denn auffällig. Und groß anders war es offensichtlich nicht in Bielefeld (oben links), Detmold (oben rechts) oder Lemgo (unten links); vielen Dank an dieser Stelle an die Stadtverwaltungen und sonstigen Betreiber der öffentlichen Webcams für die Bereitstellung minütlicher Updates (über Mobotix-Standardzugänge)! Trotzdem waren im zu Fuß – auch während einer Eiszeit – erreichbaren LIDL in Steinwurfnähe unter anderem Toastbrot und andere Dinge des täglichen Bedarfs schon seit Freitag ausverkauft — go figure.
Und wer noch immer nicht die Lust an derlei Filmchen verloren hat: die Nacht von Daisy in Gütersloh, mit dem Tag davor und danach, aus anderer Perspektive nochmals im Zeitraffer:
Daisy in OWL im Zeitraffer
Kurzer Zeitraffer von heute Mitternacht bis Mittag von öffentlichen Webcams in Bielefeld, Detmold, Lemgo und meiner Parkplatz-Cam in Gütersloh – Schnee ja, Chaos nein würde ich sagen:
Wireless-Web-Cam, die 2.
Angespornt vom super Wetter (Schnee!), habe ich nun meinen zweiten Fonera 2.0g in einen drahtlosen Kameraserver verwandelt. Zwar leider nicht für ältere Webcams, aber bei den UVC-kompatiblen Kameras gibt es ja auch einige schmucke Geräte.
Diesmal habe ich mir das OpenWRT-Image selbst zusammengebaut, im Endeffekt ist es reichtlich simpel, auf dieser Basis eine wireless Webcam zusammenzubauen, die, wie man sehen kann, auch bei unter -10 Grad Celsius noch funktioniert. Eine Creative Optia AF hatte ich schon im Sommer in ein entsprechendes Gehäuse (Baumarkt-Druckguß-300W-Halogenstrahler) gepackt und auf der Terrasse moniert (parallel zu einem ungeschützt aufgehängten alten Philips-pwc-Ei), nur leider klappte es seinerzeit nie, jene Cam weder mit blanken USB-Verlängerungskabeln noch mit aktiven USB2-Verlängerungskabeln noch mit letzteren plus eines außen dazwischengeschalteten netzgespeisten USB-2.0-Hubs irgendwie an den »cam-serv« und das darauf laufende »motion« anzuschließen. Lustige USB-Fehlermeldungen oder nur einen Start nach dem Reset überlebende Konstellationen waren die Folge; schade eigentlich, da jene Cam eine der wenigen ist, die unter Linux einen funktionierenden Autofocus mitbringen. Allerdings zeigt sich grade jetzt im Nachteinsatz, daß dieser Autofocus bei schlechten Lichtverhältnissen arg zum ziellosen pumpen neigt :(
Ich habe also heute abend, nachdem mein dedizierte Cam (s. o.) schneehöhenbedingt nur noch ein Schwarzbild zu liefern vermochte, auch meine zweiten Fonera 2.0g der kalten Unwirtlichkeit übereignet – und besagte Optia AF angeschlossen. Deren Bild liefert jetzt – leider liefert sie nur 800×600 als MJPEG-Stream – als kleines Einblendimage zusätzliches Bildmaterial, da mein Hauptimage ja schneehöhenbedingt uninteressant geworden ist.
Kurzer Abriß der eingesetzten Technik: Die »Himmelscam« als auch die »Parkplatzcam« sind Notebook-Pro-USB-Cams von Logitech, die an einem SheevaPlug (Parkplatz) bzw. einer Fonera-2.0g mit OpenWRT (Himmel); die Wetterdaten werden empfangen über FHEM in Verbindung mit CUL und CUN sowie S300TH/S555TH als Sensor. Ferner tut eine WS3600 Dienst, welche minütlich seriell über FHEM ausgelesen wird; deren Werte wandern allerdings, anders als jene der S300-Sensoren, noch nicht in die rrd-Datenhaltung, weshalb nur zwei Werte, die des Sensors in der Gartenhütte und die des Sensors oberhalb des Parkplatzes, in den Plot auftauchen. Bedingt durch die Funkübertragung gibt es gelegentlich Aussetzer, die im Graphen sich als fehlende Fortschreibung der entsprechenden Linie manifestieren; in der Folge fehlen dann entsprechend auch einen Tag später die als Fläche aufgetragenen Werte des Vortags. Warum es diese Aussetzer, insbesondere Nachts, gibt, ist eines der Themen, an denen ich derzeit kaue … Anyway, der Film der letzten zwei Tage: