Weitere Informationen

Hardwarediskriminierung
Monday, August 23, 2010, 22:25 - Geeks & Co., WLAN, Linux
Danke, liebe Entwickler:
The staging driver depends on the x86 or x86-64 architecture (Debian i386 and AMD64 ports respectively) at this time.

{i} Ralink 802.11n PCI devices are supported by the rt2860sta driver. Ralink 802.11g USB devices are supported by the rt73usb and rt2500usb drivers.

Daß der Treiber von Ralink ebenfalls nicht durchgebacken wird: Details …
wusel@greebo:~/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1$ make ARCH=arm
make -C tools
make[1]: Entering directory `/home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/tools'
gcc -g bin2h.c -o bin2h
make[1]: Leaving directory `/home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/tools'
/home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/tools/bin2h
cp -f os/linux/Makefile.6 /home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/Makefile
make -C ../linux-2.6.34 SUBDIRS=/home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux modules
make[1]: Entering directory `/home/wusel/DockStar-images/linux-2.6.34'
  CC [M]  /home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../os/linux/sta_ioctl.o
/home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../os/linux/sta_ioctl.c: In function 'rt_ioctl_siwencode':
/home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../os/linux/sta_ioctl.c:1479: warning: suggest parentheses around operand of '!' or change '&' to '&&' or '!' to '~'
/home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../os/linux/sta_ioctl.c: At top level:
/home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../os/linux/sta_ioctl.c:2986: error: unknown field 'private' specified in initializer
/home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../os/linux/sta_ioctl.c:2986: warning: initialization from incompatible pointer type
/home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../os/linux/sta_ioctl.c:2987: error: unknown field 'num_private' specified in initializer
/home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../os/linux/sta_ioctl.c:2987: warning: excess elements in struct initializer
/home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../os/linux/sta_ioctl.c:2987: warning: (near initialization for 'rt28xx_iw_handler_def')
/home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../os/linux/sta_ioctl.c:2988: error: unknown field 'private_args' specified in initializer
/home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../os/linux/sta_ioctl.c:2988: warning: excess elements in struct initializer
/home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../os/linux/sta_ioctl.c:2988: warning: (near initialization for 'rt28xx_iw_handler_def')
/home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../os/linux/sta_ioctl.c:2989: error: unknown field 'num_private_args' specified in initializer
/home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../os/linux/sta_ioctl.c:2989: warning: excess elements in struct initializer
/home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../os/linux/sta_ioctl.c:2989: warning: (near initialization for 'rt28xx_iw_handler_def')
make[2]: *** [/home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../os/linux/sta_ioctl.o] Error 1
make[1]: *** [_module_/home/wusel/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux] Error 2
make[1]: Leaving directory `/home/wusel/DockStar-images/linux-2.6.34'
make: *** [LINUX] Error 2
wusel@greebo:~/DockStar-images/2010_0709_RT2870_Linux_STA_v2.4.0.1$
Schade; statt verkabelte 100 MBit/sec drahtlose 150 MBit/sec (brutto) wäre schon fast eine Alternative …

Technik und Tücken
Monday, August 16, 2010, 21:45 - Geeks & Co., Verschiedenes
Mein Audi-MMI hat leider keinen AUX- oder USB-Eingang (obwohl das wohl technisch kein Problem darstellt, in der Anleitung sind diese Dinge alle beschrieben; leider mit * markiert, dem Zeichen, wir kennen das aus den DSL- und Klingeltonwerbungen, für ganz viel Extrakosten), mein neues (Firmen-) Nokia N900 aber einen UKW-Sender.

Also N900 auf die Mittelkonsole gelegt, UKW-Sender eingeschaltet — und erst einmal traurig festgestellt, daß nur 88,0 bis 106,9 MHz eingestellt werden können, schade, denn das Radio tuned in einem weiteren Frequenzbereich …

Und jeder Frequenzschritt wäre wichtig, denn zwischen Berlin und Gütersloh eine freie Frequenz zu finden, ist leider unmöglich. Kurzum: diese FM-Sendetechnik ist lustig, ja auch praktisch — könnte neben der Musik ja auch die Navigation von einem Multifunktionsgerät wie dem N900 so über die Autolautsprecher ausgegeben werden. Aber leider ist aufgrund der lächerlichen kleinen Sendeleistung, gepaart mit einem lustigen Flickenteppich querbeet vergebener Senderfrequenzen diese Technik mehr so für die Katz' — es zischt, es rauscht, und in Ballungsräumen ist kaum eine auch nur halbwegs freie, vom lokalen »Störsender« ausreichend zu überdeckende Frequenz auffindbar :(

Beim Videorecorder hat man seinerzeit ja mal Kanal 37 als für den VCR vorgesehen gehabt; von diesem Luxus können die FM-Transmitter leider nur träumen …
1 Kommentar 1 Kommentar (105 mal angeschaut)  | [0 Trackbacks]  | Permalink  |  (3/24)

Supermarkthardware und Linux …
Saturday, August 14, 2010, 22:49 - Geeks & Co., Technologien, WLAN, Linux
Ich kann's ja nicht lassen, und wenn ein Supermarkt (hier: Marktkauf) für 7,99 ein USB-WLAN-Dongle anbietet (was sich im Markt dann als 802.11n-tauglich herausstellt, da neben der beworbenen Charge »WL0079« – 802.11g – auch Logilink »WL0049« – 802.11n – hängen und als »WL0079« für 7,99 in der abgelaufenen Woche verkauft wurden), dann schlage ich schon mal zu. Und mittlerweile scheint es treibermäßig bei Linux immer besser auszusehen: 
Aug 14 22:47:47 ysabell kernel: [ 4493.755964] usb 2-1.2: new high speed USB device using ehci_hcd and address 3
Aug 14 22:47:47 ysabell kernel: [ 4493.869787] usb 2-1.2: configuration #1 chosen from 1 choice
Aug 14 22:47:47 ysabell kernel: [ 4493.934508] cfg80211: Disabling channel 2484 MHz on phy1 due to Country IE
Aug 14 22:47:47 ysabell kernel: [ 4493.934631] phy1: Selected rate control algorithm 'minstrel'
Aug 14 22:47:47 ysabell kernel: [ 4493.935662] Registered led device: rt2800usb-phy1::radio
Aug 14 22:47:47 ysabell kernel: [ 4493.935699] Registered led device: rt2800usb-phy1::assoc
Aug 14 22:47:47 ysabell kernel: [ 4493.935726] Registered led device: rt2800usb-phy1::quality
Aug 14 22:47:47 ysabell kernel: [ 4493.935988] usbcore: registered new interface driver rt2800usb
Aug 14 22:47:47 ysabell kernel: [ 4493.941055] rt2870sta: module is from the staging directory, the quality is unknown, you have been warned.
Aug 14 22:47:47 ysabell kernel: [ 4493.952383] rtusb init —>
Aug 14 22:47:47 ysabell kernel: [ 4493.952468] usbcore: registered new interface driver rt2870
Aug 14 22:47:47 ysabell libvirtd: 22:47:47.816: error : udevStrToLong_ui:73 : Failed to convert 'ff' to unsigned int#012
Aug 14 22:47:47 ysabell NetworkManager: <info>  Found wlan radio killswitch rfkill5 (at /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/ieee80211/phy1/rfkill5) (driver <unknown>)
Aug 14 22:47:47 ysabell NetworkManager:    SCPlugin-Ifupdown: devices added (path: /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/net/wlan1, iface: wlan1)
Aug 14 22:47:47 ysabell NetworkManager:    SCPlugin-Ifupdown: device added (path: /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/net/wlan1, iface: wlan1): no ifupdown configuration found.
Aug 14 22:47:47 ysabell NetworkManager: <info>  (wlan1): driver supports SSID scans (scan_capa 0x01).
Aug 14 22:47:47 ysabell NetworkManager: <info>  (wlan1): new 802.11 WiFi device (driver: 'rt2800usb')
Aug 14 22:47:47 ysabell NetworkManager: <info>  (wlan1): exported as /org/freedesktop/NetworkManager/Devices/2
Aug 14 22:47:47 ysabell NetworkManager: <info>  (wlan1): now managed
Aug 14 22:47:47 ysabell NetworkManager: <info>  (wlan1): device state change: 1 -> 2 (reason 2)
Aug 14 22:47:47 ysabell NetworkManager: <info>  (wlan1): bringing up device.
Aug 14 22:47:47 ysabell kernel: [ 4493.975277] rt2800usb 2-1.2:1.0: firmware: requesting rt2870.bin
Aug 14 22:47:48 ysabell kernel: [ 4494.225944] ADDRCONF(NETDEV_UP): wlan1: link is not ready
Aug 14 22:47:48 ysabell NetworkManager: <info>  (wlan1): preparing device.
Aug 14 22:47:48 ysabell NetworkManager: <info>  (wlan1): deactivating device (reason: 2).
Aug 14 22:47:48 ysabell NetworkManager: <info>  (wlan1): supplicant interface state:  starting -> ready
Aug 14 22:47:48 ysabell NetworkManager: <info>  (wlan1): device state change: 2 -> 3 (reason 42)
OS: Ubuntu 10.04. Gut, das Gerät ist derzeit nicht wirklich nutzbar, was immer auch die Gründe »2« und »42« (#ilike) sein mögen; auf »iwlist wlan1 scan« reagiert es jedenfalls mit nicht zutreffenden »no results«. Aber die HW scheint prinzipiell ja schon mal erkannt zu werden und auch bekannt zu sein, so daß ich mir Hoffnungen mache, mit dem Stick betagteren Geräten zu mehr Wummms in neu aufzubauenden WLANs nach 802.11n zu verhelfen — ca. 2 MByte/sec (entsprich den max. gut 20 MBit/sec einer guten 802.11g-Verbindung) sind bei Dateien im Multi-GByte-Bereich nicht mehr zeitgemäß …

Nachtrag: Dank des Hinweises im UbuntuUsers.de-Forum rennt der USB-Stick jetzt; notwendige Änderungen: 
root@ysabell:~# grep -B1 rt2 /etc/modprobe.d/blacklist.conf 
# wusel, 2010-08-14
blacklist rt2800usb
blacklist rt2x00usb
blacklist rt2x00lib
Resultat: 
root@ysabell:~# ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr 00:24:d7:00:00:00  
          inet addr:192.168.5.55  Bcast:192.168.5.255  Mask:255.255.255.0
          inet6 addr: fe80::whatever/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:60290 errors:0 dropped:0 overruns:0 frame:0
          TX packets:31841 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:48340185 (48.3 MB)  TX bytes:4562226 (4.5 MB)

root@ysabell:~# ifconfig wlan1
wlan1     Link encap:Ethernet  HWaddr 00:1f:1f:00:00:00 
          inet addr:192.168.5.55  Bcast:192.168.5.255  Mask:255.255.255.0
          inet6 addr: fe80::whatever/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:711 errors:0 dropped:0 overruns:0 frame:0
          TX packets:76 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:64135 (64.1 KB)  TX bytes:7971 (7.9 KB)
Nunja, an den dhcpd muß ich wohl noch mal ran ;) Nach Deaktivierung von wlan0 im NetworkManager funzt die Verbindung aber wieder einwandfrei. (Nur noch nicht schneller, denn mehr als 802.11g kann die Infrastruktur hier noch nicht; die 7270 steht noch im OG …)

Die Zivilisation hat mich wieder – sprich: ich habe DSL
Thursday, August 12, 2010, 23:56 - Geeks & Co., Berlin, Painseeker, xDSL, Alice
Das N900 per USB-Kabel an einen Dockstar gekoppelt und via ttyACM0 als Modem verwendet. Bluetooth-Dongles waren grade aus ;)
Hach ja, man kann mit 3.5G-Netzen (HSPA) schon einige tolle Dinge machen; aber da letztlich, je nach Tarif, zwischen 1 und 5 GB die Drosselung auf »ISDN-Geschwindigkeit« greift, ist »echte« Internetnutzung per 3.5G ein teuerer Spaß. Was mich doch ziemlich erstaunt hat war die Tatsache, daß sogar Sessions mit Burnout Paradise von der PS3 aus, samt VoIP, möglich waren — die Ruckler waren erträglich (nur bei wenigen Mitspielern traten wirklich große Sprünge auf, das ist mir aber auch schon mal am heimischen VDSL-Anschluß passiert), xnetload zeigte rd. 40 KByte/Sec Traffic.

Verglichen mit »echtem« DSL (wobei 3.5G-Mobilfunk ja auch eine Art DSL darstellt, wenn auch ohne physikalische »Line«) ist ein Internet-Zugang per HSPA doch begrenzt. Insbesondere, wenn künstlich auf 8 KByte/sec gedrosselt wird …
Aber ich bin dennoch froh, daß seit heute nun endlich mein Alice-DSL-Zugang funktioniert; Alice hat zwar auch diesmal sein »Anschlußversprechen«, mit Ansage, nicht gehalten und der analoge Teil dieses auf PSTN-Basis realisierten Anschlusses (lies: Telefonie kommt via Splitter und »echter Telefonietechnik« ins Haus, nicht als »NGN«, sprich über VoIP realisiert) funktioniert auch nur eingeschränkt (lautes und nervendes Brummen auf der Stimme des Gegenübers; in Senderichtung scheint es kein Problem zu geben, wie immer das bei der Technik überhaupt passieren kann). Aber gut, nach nur 27 Minuten Handytelefonat mit Alice, davon sicher >20 nur in der Warteschleife, weiß ich nun einerseits, daß ich eine schlechte Leitung habe (schlechter Signal-Rauschabstand; Kommentar des Technikers: »Sie werden wohl Leitungsabbrüche haben; ich habe eine ähnliche Leitung und nur 10 MBit. Aber ich gönne Ihnen die 16 natürlich.«), daß meine Leitung nicht testbar ist (»Und wieder: Test kann nicht durchgeführt werden. Komisch.«) und daß ich bis Freitag, 21 Uhr, entweder eine SMS mit dem Hinweis, die Störung sei behoben (imho eher unwahrscheinlich; irgendwo brummt ja jemand oder etwas in meine Leitung) oder den Hinweis auf einen notwendigen Technikerbesuch. Den würde ich dann wohl mal auf einen Sonntag terminieren, denn die arbeitende Bevölkerung hat ja werktags eigentlich was anderes vor, als 4 Stunden auf einen übellaunigen, augenscheinlich akkordarbeitenden, Telekomiker zu warten … (Wobei, meiner war dann doch noch relativ nett, aber er kam natürlich wieder deutlich im Bereich des letzten Viertels der avisierten Zeit …) Naja, es wird wohl weiter Spaß mit Alice geben; daß ich mein Modem gestern nicht mehr bekommen habe, schrieb ich ja schon … Kleiner Tipp, liebes Alice-Logistik-Team: wenn man schon seine eigene feste Drei-Wochen-Zusage reißt, muß man dem Kunden nicht auch noch am letztmöglichen Tag erst die Hardware schicken; denn, wieder der dummdreiste Hinweis auf die – offensichtlich im Alice-Klientel in der Minderheit befindlichen – arbeitende Bevölkerung, mit ein paar Tagen, gar einem Wochenende, Luft könnte man die Abholung der Hardware deutliche einfachen organisieren als so …

Anyway, so sieht meine »SpeedBox« (gefritzter SpeedPort W900V) die DSL-Seite:
Empfangsrichtung Senderichtung
Max. DSLAM-Datenrate kBit/s 18080 1152
Min. DSLAM-Datenrate kBit/s 32 32
Leitungskapazität kBit/s 16533 1340
Aktuelle Datenrate kBit/s 16533 1148
 
Latenz 7 ms 1 ms
Bitswap an an
Seamless Rate Adaption aus aus
Impulse Noise Protection 0.4 0.0
L2 Power Mode NA - -
 
Signal/Rauschabstand dB 7 12
Leitungsdämpfung dB 20 18
Powercutback dB 0 0

Anders als das Modem von Alice (»Alice Modem 1111«) bietet die Fritz!Box-Oberfläche die Möglichkeit, DSL-Informationen zu bekommen …
Eigentlich wollte ich ja das Alice-Modem dran lassen, aber da dies a) ein »traditioneller« PPPoE-Zugang mit PSTN-Telefonie ist und b) Alice mir ja den Zugriff auf diese, aus meiner Sicht wichtigen, Informationen vorenthalten will und c) hier der Austausch wirklich simpel ist, habe ich dann doch noch umgestellt und das Modem im W900V in Betrieb genommen. Wehrmutstropfen: die vorher (über OpenVPN-Tunnel) funktionierende Kopplung mit einer FB in Gütersloh funktioniert nun wieder nicht mehr.

Naja, die Optimierung muß dann wohl auf's Wochenende oder bis zur nächsten Woche warten, latent möchte ich ja auch hier OLSR und Fallback auf 3G nutzen, zumindest für die nächsten zwei Alice-Mobile-Flat-Monate …

DUN mit dem Nokia N900
Tuesday, August 10, 2010, 00:21 - Geeks & Co., Painseeker, GSM/GRPS/UMTS/..., Linux, Maemo
Cool. Für mein N900 habe ich heute ein paar Sachen installiert; unter anderem gibt es ein »Hotspot-Programm« (welches zumindest bei mir aber nicht so recht mag) sowie ein Package, welches DUN, Dial-Up-Networking, nachzurüsten vorgibt.

Gut, die Business-Telefone oder auch mein N95 haben das von Haus aus drin, aber das Maemo-, d. h. letztlich Linux-basierte, N900 kann DUN scheinbar nicht von Haus aus. Da ich es aber als mein primäres Telefon nutzen möchte, brauche ich diese Funktionalität, und ich teste sie hier grade: funktioniert ;)

Zwar muß ich auch hier wieder die Daten des Telefons in /etc/bluetooth/rfcomm.conf (Ubuntu 10.04) händisch eintragen (also BT-Adresse und Kanal des DUN-Dienstes) und auch wieder manuell »rfcomm connect 1« (bei mir 1, weil 0 noch das E72 ist) starten (rfcomm habe ich mittlerweile SUID root gemacht, da das auf diesem System keinen erkennbaren Schaden hat) und dann endlich die »Mobile Broadband«-Verbindung im Network Manager aktivieren — aber: es geht, und das ist für mich derzeit die Hauptsache, damit das N900 als primäres Telefon eingesetzt werden kann.

Wie weit ist eigentlich der Meego-Port, schon ansatzweise im Bereich »benutzbar«? Hinsichtlich des Look-and-Feel hat sich beim N900-Meego gegenüber des N810-Meegos ja doch einiges getan, auch in Richtung Eye-Candy … Eine der nächsten Aufgaben wird sein, DUN für Android zu suchen, so schwer kann da ja eigentlich nicht sein, derlei zu implementieren, oder?


Weiter