Es hat eine Woche gedauert, aber nun funktioniert mein VDSL-Anschluß auch mit meiner Fritzbox 7570 (in Speedport W920V-Verkleidung).
Continue reading “VDSL mit congstar und Fritzbox”
Yeah. Solved the NAT puzzle ;)
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 “Yeah. Solved the NAT puzzle ;)”
Seagate GoFlex Net, debianized
This is kind of an update to a previous article focussed on puitting Debian onto a Dockstar. In the meantime — it’s two years since the Dockstar was famous (and cheap; or: famous because it was so damned cheap :-)) –, it’s SATA brother, the Seagate FreeAgent GoFlex Net (yes, a long name; STAK200 is the product code), dropped into the 30 EUR prince range, and, frankly, if you do use the USB bus for anything, like e. g. stream DVB off attached devices, you do not want your system’s normal disk I/O gets in the way here.
Continue reading “Seagate GoFlex Net, debianized”
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?
LTE ist cool ;)
Grade mit meinem Multi-Link-AP kurz nach dem Halt in Hannover Hbf ausprobiert, als der USB-Stick mir Vodafone-SIM LTE signalisierte:
Tue Apr 24 07:34:48 CEST 2012 PING gw-d2.uu.org (193.26.120.206) 56(84) bytes of data. --- gw-d2.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9082ms rtt min/avg/max/mdev = 38.021/42.213/51.538/4.231 ms
Zum Vergleich, D1 mit baugleichem Stick (Huawei K5005) und o2 mit Huawei E1550:
Tue Apr 24 07:34:49 CEST 2012 PING gw-d1.uu.org (193.26.120.204) 56(84) bytes of data. --- gw-d1.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 11814ms rtt min/avg/max/mdev = 216.279/3340.028/7213.291/2193.227 ms, pipe 8/
Tue Apr 24 07:34:49 CEST 2012 PING gw-o2.uu.org (193.26.120.208) 56(84) bytes of data. --- gw-o2.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9778ms rtt min/avg/max/mdev = 208.762/291.890/508.182/78.296 ms
Alles, wohlgemerkt, aus dem schon wieder fahrenden ICE.
(Die Verbindung läuft über OpenVPN (per UDP) über dedizierte Endpunkt-IPs an einem Server im ‘Festnetz’, die über die jeweile PPP-Verbindung der USB-Mobilfunkmodems geroutet werden. Das alleine ist schon ein Big Win bei den laufend abbrechenden PPP-Sessions wegen Abdeckungsmangel …)
Ein bißchen später, so in Höhe Gifhorn im ICE 541, sieht das dann allerdings auch anders aus:
Tue Apr 24 07:57:09 CEST 2012 PING gw-d1.uu.org (193.26.120.204) 56(84) bytes of data. --- gw-d1.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9006ms rtt min/avg/max/mdev = 10064.308/12367.812/15869.452/1888.586 ms, pipe 10
Tue Apr 24 07:57:08 CEST 2012 PING gw-d2.uu.org (193.26.120.206) 56(84) bytes of data. --- gw-d2.uu.org ping statistics --- 10 packets transmitted, 8 received, 20% packet loss, time 57635ms rtt min/avg/max/mdev = 984.208/2262.540/3884.146/834.960 ms, pipe 3
Tue Apr 24 07:57:07 CEST 2012 PING gw-o2.uu.org (193.26.120.208) 56(84) bytes of data. --- gw-o2.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 85126ms rtt min/avg/max/mdev = 590.445/1558.000/4091.427/1151.067 ms, pipe 2
Internet im ICE — noch immer ein Abenteuer ;) Zum Abschluß — auch der Reise ;) — nochmal Pings aus dem stehenden ICE im Bahnhof Berlin.-SPandau, mit LTE bei D2:
Tue Apr 24 08:58:11 CEST 2012 PING gw-d1.uu.org (193.26.120.204) 56(84) bytes of data. 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=1 ttl=64 time=886 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=2 ttl=64 time=1327 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=3 ttl=64 time=334 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=4 ttl=64 time=107 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=5 ttl=64 time=107 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=6 ttl=64 time=155 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=7 ttl=64 time=94.9 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=8 ttl=64 time=103 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=9 ttl=64 time=112 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=10 ttl=64 time=221 ms --- gw-d1.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9494ms rtt min/avg/max/mdev = 94.927/345.152/1327.262/399.590 ms, pipe 2
Tue Apr 24 08:58:11 CEST 2012 PING gw-d2.uu.org (193.26.120.206) 56(84) bytes of data. 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=1 ttl=64 time=69.6 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=2 ttl=64 time=65.4 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=3 ttl=64 time=69.4 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=4 ttl=64 time=65.5 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=5 ttl=64 time=57.1 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=6 ttl=64 time=59.9 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=7 ttl=64 time=62.1 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=8 ttl=64 time=60.8 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=9 ttl=64 time=61.0 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=10 ttl=64 time=71.0 ms --- gw-d2.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9006ms rtt min/avg/max/mdev = 57.137/64.225/71.063/4.502 ms
Tue Apr 24 08:58:12 CEST 2012 PING gw-o2.uu.org (193.26.120.208) 56(84) bytes of data. 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=1 ttl=64 time=687 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=2 ttl=64 time=729 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=3 ttl=64 time=229 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=4 ttl=64 time=559 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=5 ttl=64 time=319 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=6 ttl=64 time=239 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=7 ttl=64 time=239 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=8 ttl=64 time=239 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=9 ttl=64 time=239 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=10 ttl=64 time=239 ms --- gw-o2.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9367ms rtt min/avg/max/mdev = 229.667/372.074/729.099/193.154 ms
Leider ist o2 derzeit, was die RTT angeht, deutlichst im Hintertreffen; 200ms bei einer HSPA-Verbindung ist … unzureichend :-(
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: