Search Results for: wlan kabel

der kleine, weisse kasten ist ein umts-wlan-router. weil der empfang im zimmer so schlecht ist, haengt das teil am (strom)kabel aus dem fenster. und damits nicht gleich nass wird, ist eine plastiktuete drumherum.

fast waere das geraet abgestuerzt, als das kabel raus gerutscht ist. nur die tuete hats noch gehalten. irgendwann war dann auch der eingebaute akku leer.

aber da sieht man mal, wofuer so ein “wlan kabel” (neben der stromversorgung) eigentlich da ist: damit das wlan nicht runterfaellt 😉

nachdem ich nun schon zwei umts-sticks geschrottet habe, musste was anderes her. bei problemen mit diesen usbsticks konnte auch nie eine hotline helfen, wenn man nur das wort “mac” in den mund genommen hat. da war es egal, ob das anliegen ueberhaupt irgendwas mit dem stick oder dem OS zu tun hatte. ein kollege empfahl mir dann den router huawei e5830 – ein umts-wlan-router mit integriertem akku. auf dem deutschen markt ist das geraet anscheinend bisher kaum bekannt, was mich dann zu ebay uk getrieben hat.

wie bei normalen billig-plastik-dsl-routern wird das geraet ueber eine weboberflaeche administriert. die sieht billig aus und ist nicht ganz intuitiv bedienbar, aber sie tut es. der akku soll angeblich 4 stunden halten, was sicherlich auch von der nutzungsintensitaet abhaengt. ziemlich viel schnickschnack ist eingebaut, den man im normalbetrieb nicht benoetigt.

der erste verbindungsversuch zwischen macbook und router klappte zuhause nicht, was wahrscheinlich daran lag, dass in den werkseinstellungen kanal 6 eingestellt ist – genauso wie bei den unzaehligen wlans meiner nachbarn. aber in einer “funkaermeren” umgebung klappte das dann wunderbar. die verbindung ist sehr schnell, die latenzzeiten sind besser als bei den bisher von mir verwendeten usb-sticks. die integrierte “anzeige” in form von fuenf, teils mehrfarbigen leuchtdioden laesst ein bischen zu wuenschen uebrig. im webinterface kann man wenigstens die signalstaerke sehen, im gegensatz zum ladestand des akkus. der wird durch nur eine leuchtdiode signalisiert: gruen = voll, rot = halbvoll, rot blinkend = fast leer usw. wenigstens kann man das ding waehrend des betriebes mit einem standard mini-usb-kabel laden.

trotzdem: ich bin begeistert! ich muss keine treiber mehr installieren, bin unabhaengig was das OS angeht, kann mehrere geraete darueber ans internet anbinden und die usb buchse des laptops wird nicht mehr ausgeleiert.

nach meinen erfahrungen mit wlan auf bali hatte ich beschlossen niemals mehr ohne wlan repeater in den uraub zu fahren. ein guter alter linksys wrt54g v2 lag noch im keller rum und dank dd-wrt firmware ist das ding zu allem moeglichen umzufunktionieren. ganz einfach hatte ich mir das vorgestellt. die konfiguration als repeater war auch ganz einfach. nur leider hat das nicht so toll funktioniert wie ich das gerne haette. beim betrieb ohne repeater gingen permanent pakete verloren, so dass die verbindung aeusserst unzuverlaessig und langsam war. vielleicht lag das daran, dass in meiner reichweite 5 AP’s mit der gleichen SSID waren und das roaming nicht so toll funktionierte. der repeater verbesserte das etwas, aber vermutlich nach ablauf der dhcp lease war die verbindung ganz weg. dann habe ich einfach den linksys als client in das bestehende wlan eingebunden und meinen laptop mit einem kabel drangeklemmt. und siehe da… es klappt alles wunderbar. ohne verbindungsabbrueche, verlorene pakete und auch rasend schnell. den linksys habe ich direkt an einen der fuenf AP des vorhanden wlans “geklemmt”. vielleicht war das des raetsels loesung? auf jeden fall kann der besser funken als die im laptop eingebaute wlan karte.
und die moral von der geschicht? das naechste mal statt einem linksys plasterouter gleich zwei mitnehmen, damit der eine als client arbeiten kann und der andere als AP fuer mein laptop 😉

das wlan-kabel:

christian macht immer so bloede witze ueber wlan kabel 😉

ohne das ziel aktiv verfolgt zu haben, bin ich schon einen schrit weiter 😉
unter dem namen “ArduWash – Embedded Knitterschutz mit Arduino” hat jemand den gleichen ansatz verfolgt und sein projekt bei heise hardware hacks veroeffentlicht. ich werde dank vorhandener kabel auf die wlan loesung verzichten, was das vorhaben minimal vereinfachern wird 🙂

bei der momentanen projektarbeit ist der mobilfunkempfang im gebaeude aeusserst bescheiden. telefonieren geht meist nur bei offenem fenster. an umts am arbeitsplatz garnicht zu denken. aber ich habe ja noch einen umts-wlan-router.. den haenge ich einfach aus dem fenster und habe dann internet per wlan. eingepackt in eine tuete, damits beim regen nicht nass wird, einen haken als zugentlastung, damits mir das usb kabel fuers netzteil nicht vermurkst und gut 😉

mal sehen, was das geraet bei minusgraden macht…

wie wir ja alle wissen, ist nicht alles gold, was glaenzt. wie schon geschrieben, habe ich auf meinem weissen macbook ein update auf osx snow leopard gemacht.
die original cd die ich hatte, war natuerlich nur die version 10.6, welche wie zu erwarten mit fehlern behaftet war. nicht umsonst habe ich ein paar wochen gewartet, bis die fehler bereinigt sind. aktuell ist die 10.6.2, welche ich jetzt auch drauf habe. das problem war, dass ich erstmal ein ethernet kabel dranstoepseln musste, um mir das update auf 10.6.2 zu ziehen, da das wlan nicht mehr funktionierte.
auf den ersten blick scheint fast alles zu funktionieren. nur mein launch2net fuer den mobilen internetzugang per umts verweigerte den dienst.

nach eingabe des kennworts passierte nichts. die loesung des problems war schnell gefunden. anchliessende tests mit umts deckten ein anderes verhalten z.b. von ping unter snow leopard auf:

64 bytes from 80.xx.xx.xx: icmp_seq=7 ttl=48 time=162.567 ms
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
64 bytes from 80.xx.xx.xx: icmp_seq=9 ttl=48 time=4373.707 ms
64 bytes from 80.xx.xx.xx: icmp_seq=10 ttl=48 time=3475.756 ms
64 bytes from 80.xx.xx.xx: icmp_seq=11 ttl=48 time=2476.617 ms
64 bytes from 80.xx.xx.xx: icmp_seq=12 ttl=48 time=1528.739 ms
64 bytes from 80.xx.xx.xx: icmp_seq=13 ttl=48 time=531.465 ms

frueher waren verlorene pakete nur anhand fehlender nummern in der icmp sequenz zu entdecken. jetzt werden die verlorenen pakete als timeout angezeigt. merkwuerdig nur, dass doch eine antwort kommt, wenn vorher ein timeout ausgegeben wurde (in dem oben gezeigten beispiel die sequenznummern 9 bis 12). kann man sicherlich mit einer der unzaehligen kommandozeilen parameter ausbuegeln, ist aber fuer ein “standard verhalten” unschoen.
viel weiter kam ich bis jetzt noch nicht. aber ich kann mir schon vorstellen, dass ich das ein oder anderen noch zu der integrierten exchange anbindung zu berichten habe 😉