WL-HDD Alternative

Status:
habe wie beschrieben nach der PEARL 400b7
als naechstes die 'CHD2WLANU_R400b7unlock.BIN' geflasht und dann die 'upgrade-v4.img' von Macsat.
Habe jetzt auch telnet Zugang über 192.168.123.254.

Problem:
Nachdem ich das autobootfs-openwrt.gz (OpenWrt filesystem image for V4 upgrade/openbootfs-openwrt.gz) in autobootfs für ext2 bzw. autoboot für fat32 umbenannt habe und auf Usb-Stick (fat322 Formatiert beim 1. Versuch, ext2-formatiert beim 2. Versuch) geschrieben habe, bootet er immer noch aus dem flash. Auch bietet sich nur telnet/WEB Zugang über IP (192.168.123.254).

Mit dem Shutdown-Taster habe ich die autobootfs bzw. autoboot auch schon auf die hd kopiert. Aber auch das ändert nichts. Reboot wurde ausgeführt (4 Sekunden gedrückt, Netzschalter aus und dann wieder ein -- Ist doch richtig so ? )

Ich sollte danach doch Zugang über die neue IP 192.168.2.1 bekommen mit anderem Passwort und dazuhin noch ssh Zugang.

Ein weiteres Problem:
Bekomme mit ftp zwar Zugang auf 192.168.123.254, jedoch kann ich im GFTp Programm die Verzueichnisse nicht wechseln.

Komme diesbezüglich einfach nicht weiter und bitte um Hilfe !

Quote:

---

Originally Posted by tobi

Status:
habe wie beschrieben nach der PEARL 400b7
als naechstes die 'CHD2WLANU_R400b7unlock.BIN' geflasht und dann die 'upgrade-v4.img' von Macsat.
Habe jetzt auch telnet Zugang über 192.168.123.254.

---

Schön, damit funktioniert das...

Quote:

---

Nachdem ich das autobootfs-openwrt.gz (OpenWrt filesystem image for V4 upgrade/openbootfs-openwrt.gz) in autobootfs für ext2 bzw. autoboot für fat32 umbenannt habe und auf Usb-Stick (fat322 Formatiert beim 1. Versuch, ext2-formatiert beim 2. Versuch) geschrieben habe

---

Ähm... Vor dem Umbenennen musst du die Datei erstmal dekomprimieren. Das '.gz' am Ende deutet auf gzip hin, so ziemlich jedes UNIX/Linux hat das dafür nötige 'gunzip', nach dem Auspacken sollte sie genau 30MB gross sein.
Ansonsten müsste das auch mit Winzip auspackbar sein.

Tes

Quote:

---

Originally Posted by Tes

Schön, damit funktioniert das...



Ähm... Vor dem Umbenennen musst du die Datei erstmal dekomprimieren. Das '.gz' am Ende deutet auf gzip hin, so ziemlich jedes UNIX/Linux hat das dafür nötige 'gunzip', nach dem Auspacken sollte sie genau 30MB gross sein.
Ansonsten müsste das auch mit Winzip auspackbar sein.

Tes

---

Super und Dankeschön für die schnelle Hilfe.

Zunächst lag's wie gesagt daran, daß ich nicht entpackt hatte.
Danach war noch eine Neupartitionierung des sticks auf 1. primäre P. mit 128 mb, da er mit vollen 1 GB einfach nicht wollte.
Open-wrt web Interface klappt auch.

Ich hatte inzwischen mal die Möglichkeit, die angekündigten Geschwindigkeitstests zu machen, indem ich zwei andere Switches zwischen die dBox und das MGB100 gehängt habe. Die Ergebnisse waren allerdings extrem merkwürdig:

1. Exemplar war ein Longshine LCS-883R-SW500M+ (älterer 5-Port-Switch). Hier funktionierten die Netzzugriffe untereinander soweit problemlos, aber wenn ich von der dBox aus auf das NFS-Laufwerk vom MGB100 zugreifen wollte, kamen dort kaum Daten an und das ganze endete kurze Zeit später dann in einer Input-/Output-Fehlermeldung. Normal dauert die Übertragung einer 64 MB Datei rund eine Minute. Hier war die Testdatei nach 3 Minuten erst bei gut 1 MB und kurze Zeit später brach das ganze ab. Dieses Verhalten trat immer auf, auch wenn ich die Geräte zwischendurch rebootet hatte oder andere Ports am Switch genutzt habe. Die einzige Erklärung, die ich habe, ist, dass der Switch sich mit einem der beiden Geräte überhaupt nicht versteht, vermutlich mit der dBox und ihren 10 MBit Halfduplex, obwohl der Switch laut den LED den Halfduplex-Modus und die 10 MBit korrekt erkennt. Nicht ganz zum Erscheinungsbild passt, dass sonstige Zugriffe (telnet etc.) keine Probleme machen.

2. Exemplar war ein Longshine LCS-883R-SW800M+, also die 8-Port-Version von obigem Switch. Hier klappte der NFS-Test auf Anhieb und verbesserte die Geschwindigkeit auch von meinen bisherigen ca. 72 Sekunden auf 60-61 Sekunden. Das sind schon recht ordentliche Werte. Allerdings habe ich hier das extrem merkwürdige Problem, dass der Switch anscheinend das MGB100 früher oder später zum Absturz bringt?! Es funktionert durchaus über Stunden erst alles problemlos, selbst wenn ich größere Datenmengen im Gigabyte-Bereich hin- und herschiebe. Irgendwann ist dann jedoch auf einmal das MGB100 "weg", d. h. es ist nicht mehr anpingbar und die per WLAN über das MGB100 als Accesspoint angebundenen Clients haben keinerlei Internetzugriff und Zugriff auf das MGB100 mehr. Fehlermeldung bekomme ich natürlich keine, aber es sieht mir so aus, als wenn das MGB100 irgendwie abstürzt. Wie ist das zu erklären? Das Problem trat bisher nur auf, wenn ich das MGB100 an den o. g. Switch angeschlossen hatte; dann allerdings auch meistens erst nach einigen Stunden. An einem anderen Switch läuft mein neues MGB100 auch tagelang völlig problemlos.

Hat jemand Ideen zu den Erscheinungsbildern? Ich deute es mal als gewisse Form von Inkompatibilität, wobei ich so etwas in Netzwerken bisher noch nie erlebt habe. Die Switches waren schon lange nicht mehr im Einsatz, sollten aber grundsätzlich keinerlei Defekte haben, weil sie früher problemlos ihren Dienst taten. Ziemlich mysteriös das Ganze.

Was den eigentlichen Sinn der ganzen Testerei angeht: Es ging ja ursprünglich um NFS-Geschwindigkeitstests. Es zeigt bestätigt sich einmal mehr, dass das MGB100 offenbar nicht die Bremse ist, sondern es - zumindest in Zusammenspiel mit der dBox 2 - viel auf den benutzten Switch ankommt. Ob nun das MGB100 sehr empfindlich auf die beiden Switches reagiert oder die Switches einfach nur sehr empfindlich beim MGB100 sind, ist nicht so genau feststellbar.

Quote:

---

Originally Posted by tobi

Super und Dankeschön für die schnelle Hilfe.

Zunächst lag's wie gesagt daran, daß ich nicht entpackt hatte.
Danach war noch eine Neupartitionierung des sticks auf 1. primäre P. mit 128 mb, da er mit vollen 1 GB einfach nicht wollte.

---

Hm, hier funktioniert ein 1GB Stick von Kingston problemlos als Träger des autobootfs (Notfallboot, falls ich Mist gebaut habe) :) . Es gibt allerdings Sticks die gar nicht laufen. :(

Quote:

---

Open-wrt web Interface klappt auch.

---

Naja, der Webserver läuft, aber viel mehr kann man damit nicht machen. Ich hab ihn abgeschaltet und mache die Konfig komplett über Scripte mit 'vi' als Editor.

Tes

Quote:

---

Originally Posted by marobo

I
2. Exemplar war ein Longshine LCS-883R-SW800M+, also die 8-Port-Version von obigem Switch. Hier klappte der NFS-Test auf Anhieb und verbesserte die Geschwindigkeit auch von meinen bisherigen ca. 72 Sekunden auf 60-61 Sekunden. Das sind schon recht ordentliche Werte. Allerdings habe ich hier das extrem merkwürdige Problem, dass der Switch anscheinend das MGB100 früher oder später zum Absturz bringt?! Es funktionert durchaus über Stunden erst alles problemlos, selbst wenn ich größere Datenmengen im Gigabyte-Bereich hin- und herschiebe. Irgendwann ist dann jedoch auf einmal das MGB100 "weg", d. h. es ist nicht mehr anpingbar und die per WLAN über das MGB100 als Accesspoint angebundenen Clients haben keinerlei Internetzugriff und Zugriff auf das MGB100 mehr. Fehlermeldung bekomme ich natürlich keine, aber es sieht mir so aus, als wenn das MGB100 irgendwie abstürzt. Wie ist das zu erklären? Das Problem trat bisher nur auf, wenn ich das MGB100 an den o. g. Switch angeschlossen hatte; dann allerdings auch meistens erst nach einigen Stunden. An einem anderen Switch läuft mein neues MGB100 auch tagelang völlig problemlos.

---

Hier kann ich mir eigentlich nur ein Problem mit dem Ethernettreiber vorstellen. Welches Image benutzt du? 2.4.28 oder Schuftis 2.4.35 (400S1/2)? Letzteres enthält eine neuere Version des Treibers (V 0.15 vom 26-Sep-2006). Falls du die nicht schon benutzt wäre ein Update eine Idee. So findet man die Treiberversion:

Code:

---

root@mgb100:~#> dmesg | grep 6040
r6040: RDC R6040 net driver, version 0.15 (26Sep2006)
r6040: RDC R6040 net driver, version 0.15 (26Sep2006)
r6040: RDC R6040 net driver, version 0.15 (26Sep2006)

---

(So siehts bei mir aus... Keine Ahnung warum er 3 Instanzen listet)

Quote:

---

Hat jemand Ideen zu den Erscheinungsbildern? Ich deute es mal als gewisse Form von Inkompatibilität, wobei ich so etwas in Netzwerken bisher noch nie erlebt habe. Die Switches waren schon lange nicht mehr im Einsatz, sollten aber grundsätzlich keinerlei Defekte haben, weil sie früher problemlos ihren Dienst taten. Ziemlich mysteriös das Ganze.

---

Wenn sie wirklich alt sind könnten sie noch Eigenheiten bei der Autonegotiation haben oder nicht in der Lage sein Pause-Frames zu senden. Aktuelle Switches sollten keine solchen Probleme mehr zeigen.

Tes

Hi,

also so sehr ich meine dBox liebe, aber beim etherinterface haben die ganz schön Sch.... gebaut. Denn egal, gegen welche Netzwerkkarte im PC man sie testet, vernünfig läuft es nur, wenn man fix auf 10Mb/hdx stellt. Auch mit einem Router dazwischen läuft es oft erst bei fixen Settings. Ich gehe daher davon aus, dass der Grund allen Ärgers in der dBox liegt, aber dort nichts machbar ist, sonst wäre das schon geschehen bei sovielen Betroffenen.

Gott sei Dank gibt es meist eine Möglichkeit eine laufende Konfiguration zu finden. Leider ist das bei der sich hier aufdrängenden Anwendung (noch) nicht möglich. Ich bin weiterhin auf Problemsuche im Treiber, leider löschen die bei RDC email ungelesen.

Eventuell läßt sich eine Version für dBox machen, wo der Treiber fest auf 10Mb/hdx gestellt ist.

schufti

Quote:

---

Originally Posted by Tes

Hier kann ich mir eigentlich nur ein Problem mit dem Ethernettreiber vorstellen. Welches Image benutzt du? 2.4.28 oder Schuftis 2.4.35 (400S1/2)? Letzteres enthält eine neuere Version des Treibers (V 0.15 vom 26-Sep-2006). Falls du die nicht schon benutzt wäre ein Update eine Idee. So findet man die Treiberversion:

Code:

---

root@mgb100:~#> dmesg | grep 6040
r6040: RDC R6040 net driver, version 0.15 (26Sep2006)
r6040: RDC R6040 net driver, version 0.15 (26Sep2006)
r6040: RDC R6040 net driver, version 0.15 (26Sep2006)

---

(So siehts bei mir aus... Keine Ahnung warum er 3 Instanzen listet)

---

Ich habe nachgeschaut: Die Version bei mir ist die 0.12

Es gibt aber neue Erkenntnisse zu meinen Problemen:

Das Problem mit dem LCS-883R-SW500M+ Switch trat ja bei jedem Versuch auf. Da sehe ich keine Lösung. Es scheint halt eine Inkompatibilität zu sein, vermutlich durch die 10-MBit/s-Halfduplex von der dBox im Zusammenspiel mit dem Switch.

Bei dem Problem mit dem LCS-883R-SW800M+ war ich aber wohl etwas zu voreilig. Ich hatte offenbar versäumt, neben der WLAN-Verbindung zum MGB100 eine Kabelverbindung zur vermeintlich komplett abgestürzten Box zu testen. Das habe ich gestern Abend nachgeholt, als sich das MGB100 mal wieder verabschiedet hatte. Und siehe da: Über die eth1-Schnittstelle ist die Box weiterhin ganz normal erreichbar. Die wl0-Schnittstelle ist laut ifconfig auch "UP":

Quote:

---

root@WHD:~# ifconfig
br0 Link encap:Ethernet HWaddr 00:50:18:48:D8:89
inet addr:192.168.1.253 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1582 errors:0 dropped:0 overruns:0 frame:0
TX packets:438 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:165734 (161.8 KiB) TX bytes:77944 (76.1 KiB)

eth1 Link encap:Ethernet HWaddr 00:00:60:00:00:02
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7094152 errors:0 dropped:0 overruns:0 frame:0
TX packets:4043989 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:856761461 (817.0 MiB) TX bytes:279916898 (266.9 MiB)
Interrupt:11 Base address:0xe900

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:56 errors:0 dropped:0 overruns:0 frame:0
TX packets:56 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3920 (3.8 KiB) TX bytes:3920 (3.8 KiB)

wl0 Link encap:Ethernet HWaddr 00:50:18:48:D8:89
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4131327 errors:0 dropped:0 overruns:0 frame:0
TX packets:7098860 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:387555302 (369.6 MiB) TX bytes:1013579270 (966.6 MiB)
Interrupt:12 Base address:0x4000

---

Allerdings hängt sich die wl0-Schnittstelle offenbar auf, denn wenn ich

ipconfig wl0 down
ipconfig wl0 up

aufrufe, ist sie wieder da und WLAN-Zugriffe funktionieren ganz normal. Außerdem ist das Problem gestern das erste Mal auch ganz ohne den Longshine-Switch aufgetreten. Im Zweifel spielt dieser also gar keine Rolle, sondern es war nur ein zufälliger Zusammenhang. Gewundert hatte mich das ja gestern schon. Allerdings drängte sich dieser Zusammenhang auf, weil das Problem seit dem Eintreffen meines neuen MGB100 viele Tage lang kein einziges Mal aufgetreten war, dagegen beim Testen des Switches gleich mehrfach.

Aktuell hatte ich das Problem gerade wieder. Die Box hat eine Uptime von etwa 15 Stunden und auf einmal ist das WLAN weg. Ich habe eben wieder das wl0-Interface neugestartet und jetzt läuft wieder alles. Bisher ist das WLAN übrigens noch nie während größeren Dateiübertragungen (im GByte-Bereich) über das WLAN-Interface weggebrochen, sondern immer erst einige Zeit danach. Das kann aber natürlich Zufall sein.

Trotzdem ist es natürlich unbefriedigend, wenn das WLAN jetzt 1-3 Mal am Tag plötzlich weg ist und ich erst mit dem Notebook zur Box und die Netzwerkeinstellungen umkonfigurieren muss, damit ich mich per SSH einloggen und das Interface neu starten kann. Tritt dieses Problem sonst noch bei jemandem auf? Woran könnte es liegen, also welche Treiber, Module etc. hängen sich möglicherweise auf?

Installiert ist übrigens aktuell bei mir immernoch die PaganoV4-Firmware mit autobootfs (auf USB-Stick). Diese wurde nur bezüglich der hiesigen Netzwerk- und WLAN-Einstellungen so konfiguriert, dass sie als Access-Point dient. Ansonsten habe ich nur per ipkg den pure-ftpd installiert und aktiviert, sowie den nfs-kernel-server und die nfs-kernel-server-utils installiert. Schuftis Image wollte ich auch immer mal testen, aber momentan war ich eigentlich erstmal zufrieden, dass alles lief. Bisher zumindest...

Quote:

---

Originally Posted by schufti

Hi,

also so sehr ich meine dBox liebe, aber beim etherinterface haben die ganz schön Sch.... gebaut. Denn egal, gegen welche Netzwerkkarte im PC man sie testet, vernünfig läuft es nur, wenn man fix auf 10Mb/hdx stellt. Auch mit einem Router dazwischen läuft es oft erst bei fixen Settings. Ich gehe daher davon aus, dass der Grund allen Ärgers in der dBox liegt, aber dort nichts machbar ist, sonst wäre das schon geschehen bei sovielen Betroffenen.

---

Wobei es bei meinen Test so war, dass per direkter Verbindung zwischen dBox und Rechner (Notebook) per Crossover-Kabel die Übertragungswerte trotz fixer Einstellung auf 10 MBit/s Halfduplex immer schlechter waren als mit zwischengeschaltetem Switch. Zunächst hatte ich auch nicht geglaubt, dass es mit Switch besser wäre; aber die Tests sprachen eine eindeutige Sprache.
Deswegen wird ja wohl auch immer wieder ein Switch in den dBox-Foren empfohlen.

Insofern ist es aber vielleicht gar nicht ganz sooo wichtig, dass man das MGB100 fix auf 10 MBit/s Halfduplex einstellen kann.

@ marobo:

aber die Eleganz der angestrebten Lösung liegt ja gerade darin, dass die dBox direkt am MGB100 liegt, dorthin streamt und per WLAN ans Netz angebunden ist. Da tut ein switch dazwischen ja wirklich in der Seele weh .... da verzichte ich lieber auf das eine oder andere kb/s :)

schufti

Quote:

---

Originally Posted by schufti

@ marobo:

aber die Eleganz der angestrebten Lösung liegt ja gerade darin, dass die dBox direkt am MGB100 liegt, dorthin streamt und per WLAN ans Netz angebunden ist. Da tut ein switch dazwischen ja wirklich in der Seele weh .... da verzichte ich lieber auf das eine oder andere kb/s :)

schufti

---

Die Lösung hätte natürlich was. Aber ich vermute, dass selbst mit entsprechendem "10 MBit/s Tuning" des MGB100 die Geschwindigkeitswerte ohne zwischengeschalteten Switch, also bei direkter Verbindung per Crossover-Kabel nicht überzeugend sein werden - zumindest lassen mich das meine Test mit dem Notebook in verschiedenen Konstellationen und Postings in dBox-Foren vermuten. Wenn es ansonsten zuverlässig läuft, sehe ich eigentlich auch keine Probleme, wenn zwischen dBox und MGB100 noch ein kleiner Switch hängt. So teuer sind diese ja auch nicht und soviel uneleganter ist das meiner Meinung nach auch nicht. Falls Du es aber schaffen solltest, gleich viel Geschwindigkeit (oder sogar mehr :) ) ohne Switch aus dem MGB100 herauszuholen, wäre das natürlich nicht schlecht.

Bei mir werde ich um einen Switch schon deshalb nicht herumkommen, weil das MGB100 vor allem auch als AccessPoint dienen soll und somit als Bridge zwischen dem kabelgebundenen Teil des LANs (in dem auch die dBox hängt) und dem kabellosen Teil (wo ein Rechner und ein Notebook sind) dienen soll. Insofern wird das MGB100 bei mir auf jeden Fall an einem Switch zuhause sein - entweder direkt am Hauptswitch oder an einem separaten kleinen Switch, der dann das separate Segment dBox / MGB100 mit dem Hauptswitch verbindet. Letzteres macht natürlich nur Sinn, wenn dieser Extraswitch besser mit der dBox harmonisiert und dadurch bessere Performance verspricht. Eine gute Wahl für alle, die sich so einen Switch separat kaufen wollen, ist wohl der D-LINK DES-1005D für um die 20 EUR.

Was mein Problem mit dem MGB100 angeht: Es bringt mich langsam zur Verzweifelung! :mad:

Ich habe gestern nochmal eine jungfräuliche autobootfs auf den USB-Stick gezogen, um auszuschließen, dass meine Abstürze des wl0-Interface mit irgendwelchen bei missglückten Shutdowns beschädigten Dateien zusammenhängen. Der Fehler trat aber heute Morgen trotzdem wieder auf. :mad: Nach dem Neustart des Interfaces mit

ifconfig wl0 down
ifconfig wl0 up

läuft wieder alles. Warum hab ich auf einmal dieses Problem, dass es anfangs nicht gab??? Ein erneutes Hardwareproblem würde so einen plötzlich neu auftretenen Fehler ja vielleicht erklären, aber meiner Meinung nach passt das nicht so ganz zum Erscheinungsbild, das für mich eher auf ein software-seitiges Problem hindeutet. Ich habe übrigens aktuell das MGB100 wieder am Longshine-Switch hängen, den ich zwischenzeitlich für den Übeltäter hielt. Aber das Problem trat ja mittlerweile auch ohne Switch auf, und plausibel ist ein Zusammenhang für mich in keinster Weise, so dass er vermutlich auch nicht bestehen wird.

Falls niemand eine Idee zur Behebung des eigentlichen Problem haben sollte, würde mir noch der Workaround einfallen, dass man z. B. stündlich per cron-Job das wl0-Interface neu startet. Cron-Jobs sollte man auf dem MGB100 doch einrichten können, oder? Jedes Mal das Notebook in die andere Etage zu schleppen, die Netzwerkeinstellungen so umzukonfigurieren, dass ich per Kabel auf das MGB100 komme, um dann per SSH das Interface neu zu starten, ist auf jeden Fall keine Dauerlösung :mad:


Es gibt aber noch ein weiteres Problem: Bei der Neuinstallation musste ich gestern dann auch noch feststellen, dass die Paketupdates für pure-ftpd und nfs-kernel-server per ipkg nicht mehr klappen. Bisher bekam man ja (nach Korrektur der URL in der /etc/ipkg.conf auf http:/ /xwrt.kicks-ass.org/xwrt/kamikaze/7.07/x86-2.6/packages/) mit

ipkg update
ipkg list

eine Liste der verfügbaren Pakete, in der unter anderem auch der pure-ftpd sowie der nfs-kernel-server und die nfs-kernel-server-utils zu finden waren. Inzwischen scheint die Datei http:/ /xwrt.kicks-ass.org/xwrt/kamikaze/7.07/x86-2.6/packages/Packages, die sich die Updatefunktion wohl zieht, jedoch auf dem Server ausgetauscht worden zu sein (Dateidatum jetzt 28.08.2007), mit dem Ergebnis, dass nach einem ipkg update viel weniger Pakete zur Verfügung stehen als unter http:/ /xwrt.kicks-ass.org/xwrt/kamikaze/7.07/x86-2.6/packages/ gelistet sind. Vor allem sind jetzt weder der pure-ftpd, noch der nfs-kernel-server und die nfs-kernel-server-utils installierbar! Es scheint, als ob dort absichtlich oder unabsichtlich viele Pakete herausgenommen wurden.

Ändere ich in der conf-Datei die URL auf http:/ /xwrt.kicks-ass.org/xwrt/kamikaze/7.06/x86-2.6/packages/ kann ich zumindest den pure-ftpd installieren. Dort gibt es aber die Pakete für den nfs-kernel-server und die nfs-kernel-server-utils erst gar nicht, so dass sie natürlich auch nicht installierbar sind.

Wie bekomme ich die Pakete für den nfs-kernel-server nun trotzdem installiert?

So toll die Idee vom MGB100 auch ist, diese Box hat mich echt schon viele, viele Stunden gekostet und manches graue Haar gebracht. Wenn sie nicht bald ohne Probleme läuft, werde ich mich wohl doch nach einer anderen Lösung umsehen müssen. :(

Testweise habe ich jetzt mal cron aktiviert und einen cronjob eingerichtet, der stündlich das wl0-Interface neu startet. Auch wenn es eigentlich keine Lösung, sondern nur ein Workaround ist, bin ich mal gespannt, ob es mir die regelmäßigen Runs mit dem Notebook zum MGB100 erspart, wenn die WLAN-Schnittstelle mal wieder "weg" ist. Gespannt bin ich auch, wie sich eine FTP-Übertragung via MGB100 verhält, wenn mittendrin das Interface auf dem MGB100 neu gestartet wird und deshalb kurzzeitig weg ist.

Um die Probleme mit ipkg zu umgehen, habe ich vorerst mal wieder meine bisherige autobootfs auf den USB-Stick gezogen. Für Neuinstallationen ist das aber natürlich keine Lösung.



EDIT:

Ich habe den Cron-Job inzwischen auf "alle 5 Minuten" gesetzt, da die Abstürze trotz stündlichem Neustart des Interfaces wl0 weiterhin vorkommen. Eine Lösung ist es selbst so natürlich nicht. Man spart sich zwar den Weg mit dem Notebook zur Box, weil man weiß, dass die Box automatisch wiederkommt, aber es muss ja auch möglich sein, dass man ohne diese Abstürze klarkommt. Vor allem lief es ja bei mir auch schon absolut stabil, ohne dass ich seitdem noch etwas an der Konfiguration des MGB100 geändert hätte - jedenfalls wüsste ich nicht was.

Interessant ist vielleicht auch noch, dass der Absturz bisher noch nie aufgetreten ist, während ich größere Datenmengen über das MGB100 vom LAN ins WLAN geschaufelt habe. Ein Problem, dass das MGB100 unter zu großer Last zusammenbricht, ist also nicht zu erkennen - zumal die Loadwerte selbst bei solchen Übertragungen auf dem MGB100 lächerlich gering sind (deutlich unter 0.10). Diese Abstürze sind immer nur aufgetreten, wenn mehr oder weniger "Leerlauf" war. Dann holt nur mein PC regelmäßig alle 2 Minuten Mails ab.

Hat jemand eine Idee? Gibt es vielleicht einen neueren WLAN-Treiber? Ich verstehe all diese Probleme einfach nicht :mad: :mad: :mad:

Hi marobo,

ich weiß, ich nerve mit der Frage, aber hast du es schon mal mit der orig FW ausprobiert?

schufti

Hi Schufti!

Nein, Du nervst keineswegs. Bei meinem neuen MGB100 habe ich es noch nicht mit der Original-Firmware probiert. Da habe ich direkt die "Spezial-Firmware" installiert, die zunächst auch einige Tage ohne Probleme lief. Meinst Du denn, dass der Test was bringt?

marobo

Hi marobo,

ich denke mal, wenn das Problem mit der orig. FW bei dir weiter auftritt und kein anderer das Phänomen kennt, ist die Sache klar, oder?

schufti

Hi schufti,

OK, das ist ein Argument. Wobei es ja schon der Hammer wäre, wenn auch die zweite Kiste einen Defekt hätte. Kann man soviel Pech haben? Das Erscheinungsbild ist auf jeden Fall ein gänzlich anderes als bei letzten Mal.

Was vielleicht wirklich auf einen Defekt hindeuten könnte ist, dass der Fehler inzwischen anscheinend immer häufiger auftritt. Nach wie vor passiert dies aber unregelmäßig und nicht reproduzierbar. Merkwürdig finde ich vor allem, dass der Fehler noch kein einziges Mal während größeren FTP-Transfers von 1 Stunde oder mehr, die über das MGB100 zwischen LAN und WLAN liefen, aufgetreten ist. Hat das MGB100 weiter nichts zu tun, tritt er dagegen inzwischen häufiger auf und meistens auch nicht erst nach Stunden. Die Lösung ist immer einmal kurz das wl0-Interface neu zu starten.

Ich hatte vorhin mal verschiedene WLAN-Konfigurationen versucht: OPEN, WEP und WPA. Geändert hat sich nichts; daran liegt es also auch nicht.

Ich habe mich noch nicht so intensiv mit der Kiste beschäftigt. Du weißt sicher besser, wie da die verschiedenen Treiber etc. mitspielen und warum das Interface einfach so "weg" ist.

Den Test mit der anderen Firmware werde ich auf jeden Fall mal machen. Nur habe ich im Moment eigentlich gar keine Zeit für solche Spielchen. Naja, vorerst habe ich den cron mal wieder aktiviert und lasse das Interface jetzt alle 2 Minuten neu starten... :mad:

Hi marobo,

leider kann ich absolut nichts über die WLAN Treiber sagen. Ich verwende die, die im 400c01 GPL Paket drin waren. Leider läßt sich da keine Version feststellen. (rt2500.o 208529Byte rt2500sta.o 184704Byte beide vom 29.5.07)

Ich habe keine Ahnung, welche Version im KK Image von Pagano steckt.

Aber da sonst noch niemand gemeckert hat.... sollte es mit orig. FW laufen, ist es wohl ein Treiberfehler im Image oder zerkonfiguriert .....

schufti

Hi zusammen,

ich lese diesen Thread nun schon seit Beginn mit und bin echt beigeistert, mit welchem Elan hier einige versuchen, das Teil zu optimieren -> Respekt!

Als absoluter Linux-Anfänger kann ich nur sehr wenig zum Thema beitragen. Ich habe aber wahrscheinlich ein ähnliches Problem wie marobo. Ich hab auf dem MGB100 noch die Original-FW (R400b7) drauf und habe die Tage bemerkt, daß die WLAN-Verbindung sich ebenfalls regelmäßig irgendwann "aufhängt". Das Teil läuft (wie gesagt mit Original-FW) im "WDS-only"-Mode und läßt sich dann nur noch durch einen Neustart wieder zum Leben erwecken.

Vielleicht hilft euch diese Info ja irgendwie weiter...:o

Hi,

also etwas googeln (linux rt2500 driver) bringt einige eindeutige Threads zu Tage, die den originalen Treibern von ralink nicht zu Ehre gereichen. Positiv ist zu erwähnen, dass die Firma (im Gegensatz zu RDC mit den r6040 Treibern) Linux und die open source Szene aktiv unterstützen.

Unter http://rt2400.sourceforge.net/ gibt es neuere Treibersourcen, die stabiler sein sollen und auf der letzten Version von ralink aufbauen (und massig Fehler behebt), wie das Changelog erkennen läßt. Allerdings macht mich folgendes doch nachdenklich:

Quote:

---

CURRENTLY NOT SUPPORTED
* Power Saving Modes (1159331)
* Bridging with other interfaces

---

Zusätzlich dürfte da jetzt Client/AP in einem Modul kombiniert sein. Ob das mit den AMIT binaries vereinbar sein wird ??? im KK Image dürfte es weniger Probleme machen.


schufti

Quote:

---

Originally Posted by real-matze

Hi zusammen,

ich lese diesen Thread nun schon seit Beginn mit und bin echt beigeistert, mit welchem Elan hier einige versuchen, das Teil zu optimieren -> Respekt!

Als absoluter Linux-Anfänger kann ich nur sehr wenig zum Thema beitragen. Ich habe aber wahrscheinlich ein ähnliches Problem wie marobo. Ich hab auf dem MGB100 noch die Original-FW (R400b7) drauf und habe die Tage bemerkt, daß die WLAN-Verbindung sich ebenfalls regelmäßig irgendwann "aufhängt". Das Teil läuft (wie gesagt mit Original-FW) im "WDS-only"-Mode und läßt sich dann nur noch durch einen Neustart wieder zum Leben erwecken.

Vielleicht hilft euch diese Info ja irgendwie weiter...:o

---

Das ist doch mal eine interessante Info! Ich versuche gerade mir einen alternativen AP (Fonera mit OpenWRT 7.07 und 2.6er Kernel) einzurichten, damit ich mit dem MGB100 testen kann ohne dass ich jedes Mal kein WLAN mehr habe. Als nächstes werde ich dann mal versuchen, wieder die Original-Firmware zu flashen, um zu schauen, ob das Problem dann immernoch auftritt. Wenn dem so ist, steigen die Chancen, das ich dem MGB100 den Rücken kehre - so interessant das Konzept ansonsten auch ist.

Quote:

---

Originally Posted by schufti

Hi marobo,

leider kann ich absolut nichts über die WLAN Treiber sagen. Ich verwende die, die im 400c01 GPL Paket drin waren. Leider läßt sich da keine Version feststellen. (rt2500.o 208529Byte rt2500sta.o 184704Byte beide vom 29.5.07)

Ich habe keine Ahnung, welche Version im KK Image von Pagano steckt.

Aber da sonst noch niemand gemeckert hat.... sollte es mit orig. FW laufen, ist es wohl ein Treiberfehler im Image oder zerkonfiguriert .....

schufti

---

Hm, ich benutze im Moment noch dein Image in der Version 400S1 (das erste von dir gepostete) zusammen mit dem Autobootfs (WLAN-Module aus der RAM-Disk ins autobootfs kopiert) und habe keine Probleme mit WLAN, zumindest im Client-Mode (nur Client, nicht WDS), teilweise ist die Kiste über Stunden idle und die Verbindung steht (mit WEP) ohne Crash. Allerdings habe ich noch keine Tests über Tage gemacht und habe ich eine kleine Änderung in der RT2500STA.dat gegenüber der die die Firmware im Flash produziert:

Code:

---

StaWithEtherBridge=1

---

Die Firmware setzt das auf '0' was ich komisch finde, weil sie schliesslich eine Bridge aufbaut.

Tes

Quote:

---

Originally Posted by Tes

Hm, ich benutze im Moment noch dein Image in der Version 400S1 (das erste von dir gepostete) zusammen mit dem Autobootfs (WLAN-Module aus der RAM-Disk ins autobootfs kopiert) und habe keine Probleme mit WLAN, zumindest im Client-Mode (nur Client, nicht WDS), teilweise ist die Kiste über Stunden idle und die Verbindung steht (mit WEP) ohne Crash. Allerdings habe ich noch keine Tests über Tage gemacht und habe ich eine kleine Änderung in der RT2500STA.dat gegenüber der die die Firmware im Flash produziert:

Code:

---

StaWithEtherBridge=1

---

Die Firmware setzt das auf '0' was ich komisch finde, weil sie schliesslich eine Bridge aufbaut.

Tes

---

Wo liegt die RT2500STA.dat denn? Ich finde sie auf meiner Box nicht. Allerdings habe ich auch noch nicht das Image von schufti drauf.

Quote:

---

Originally Posted by marobo

Wo liegt die RT2500STA.dat denn? Ich finde sie auf meiner Box nicht. Allerdings habe ich auch noch nicht das Image von schufti drauf.

---

Sollte in /var, /tmp oder /etc zu finden sein, je nachdem wie die Symlinks gesetzt sind. Ich hab meine Version damals mit der upgradev4-Firmware erstellt, also einem 400b7-Derivat und dann umkopiert damit sie mit dem autobootfs benutzbar ist.

Tes

Ich hab mein Teil gestern von "WDS-Only" auf "Wireless Client" umgestellt ( immer noch Original FW). Seit dem hab ich keinerlei Abstürze mehr.

@real-matze: fein, das ist ja schon mal eine klare Aussage mit der man was anfangen kann.

Und ich denke als WDS ist es prinzipiell nur bedingt brauchbar. Generell sollte man WLAN ja nur mit mind. WPA einsetzen und da macht WDS mit AP von gemischten Anbietern regelmäßig Probleme, da WPA für AP <> AP nicht standardisiert ist; ev. kommt das Problem genau daher (WPA wird zwar korrekt initialisiert, kommt dann aber beim nächsten Schlüsselwechsel aus dem Tritt o.ä.).

@marobo: in welcher Konfig verwendest du das MGB100 client/WDS/???

schufti

Was für WPA-Modi als AP bietet das Teil eigentlich? Ist das WPA mit AES schon mit WPA2 gleichzusetzen?

Ich habe hier nämlich noch eine Apple Airport-Express, welche ich als WLAN-Client zum streamen von Musik mit dem MGB verkoppeln wollte. Da ging per WPA/WPA2 zum WPA+AES konfigurierten MGB überhaupt nichts.

Falls ich mir irgendwann mal eine Nintendo WII oder eine PS3 zulege, wäre es gut zu wissen, ob die Teile mit dem MGB funktionieren. Gibt es da schon Erfahrungen zu?

BTW:
Gibt es ein SMB-Mount, um auf andere SMB/AFP-only NAS zuzugreifen?

Ciao,
Norman

@normancz

ich denke mal, das liegt an dem Apfelteil, die zicken da immer rum. Ich hab einen Bekannten mit Apfelnotebook, für den muß ich immer meinen AP auf WPA/TKIP und "ABC" passphrase stellen, weil alles andere zum horrenden Konfigurationsmarathon wird. Am liebsten wäre ihm WEP ....

Und nein, WPA/AES ist nicht gleich WPA2. AES ist zwar in WPA2 Standard, aber WPA != WPA2. Und eine Menge WPA taugliche HW kommt mit AES auch nicht zurecht oder zumindest nicht automatisch obwohl das angeboten wird etc.

Konkreten Test zur WPA2 Kompatibilität des MGB100 habe ich aber noch keine gemacht. Kann ich aber mal fürs WE planen.

schufti

Quote:

---

Originally Posted by schufti

@normancz

ich denke mal, das liegt an dem Apfelteil, die zicken da immer rum. Ich hab einen Bekannten mit Apfelnotebook, für den muß ich immer meinen AP auf WPA/TKIP und "ABC" passphrase stellen, weil alles andere zum horrenden Konfigurationsmarathon wird. Am liebsten wäre ihm WEP ....

---

Komisch... Ich hab hier gerade das MGB100 auf WPA mit AES gestellt und mein Powerbook hat absolut keine Probleme damit. Key eingeben (deutlich länger als 'ABC') und die Verbindung steht. Mein Location-Manager hat inzwischen einige Einträge für WLAN und bisher musste keiner seinen AP umstellen damit ich bei ihm online gehen kann. U.U. gibts Probleme mit Sonderzeichen im Key. Zur Sicherheit hab ich bei sowas immer nur 7Bit-ASCII in Verwendung.

Hier die RT2500AP.dat zum aktuellen Test:

Code:

---

[Default]
SSIDNum=1
SSID=MGB100
HideSSID=0
CountryRegion=8
WirelessMode=0
TxRate=0
Channel=1
BeaconPeriod=100
DtimPeriod=3
TxPreamble=0
RTSThreshold=2347
FragThreshold=2346
TxBurst=1
TurboRate=0
NoForwarding=0
ShortSlot=0
AutoChannelSelect=0
AuthMode=WPAPSK
EncrypType=AES
WPAPSK=thisismykey
IEEE8021X=0
ReKeyMethod=DISABLE
ReKeyInterval=
AccessPolicy=0
AccessControlList=
WdsEnable=0
WdsNum=0
WdsList=

---

Quote:

---

Konkreten Test zur WPA2 Kompatibilität des MGB100 habe ich aber noch keine gemacht. Kann ich aber mal fürs WE planen.

---

Ich denke nicht, dass WPA2 möglich ist. Die Original-Firmware bietet es jedenfalls nicht an.

@normancz:

Zum Thema SMB-Mount... Der Kernel in der 400S1 die ich hier drauf habe hat kein smbfs einkompiliert. Du brauchst mindestens das Modul und das 'smbmount'-binary. Wenn es nur hin und wieder sein muss geh mal nach 'smbclient' suchen. Funktioniert wie FTP. Bei den Default-Pkgs ist beides leider nicht dabei.

Tes

Hi,

mal was ganz anderes:

hier gibt es ein Link zu TwonkyMedia server (Linux x86 uclibc 0.9.28, 30 Tage Testversion) und eine Installationsanleitung.

vielleicht interessiert es ja jemanden.

schufti

Edit: ja, WPA2 war ja nur beim 3,5" Modell (RT2561) ....

Quote:

---

Originally Posted by schufti

Hi,

mal was ganz anderes:

hier gibt es ein Link zu TwonkyMedia server (Linux x86 uclibc 0.9.28, 30 Tage Testversion) und eine Installationsanleitung.

vielleicht interessiert es ja jemanden.

---

In Verbindung mit dem ZyXEL DMA-1000 wäre es interessant, aber die Kombination scheint noch nicht so 100% zu laufen und das DMA-1000 liefert auch über SPDIF immer nur 2.0 Ton. Lieber noch etwas warten.

Tes

Quote:

---

Originally Posted by Tes

In Verbindung mit dem ZyXEL DMA-1000 wäre es interessant, aber die Kombination scheint noch nicht so 100% zu laufen und das DMA-1000 liefert auch über SPDIF immer nur 2.0 Ton. Lieber noch etwas warten.

---

;-) hatte/habe keinen Bock mehr zu warten und habe mir so ein DMA-1000 gegönnt (120€ inkl. Versand). Die Kiste macht echt Spass und hat imo Potenzial. Am Besten klappts mit dem freien TVersity-Server (damit geht sogar Internet Radio/Video) den ich uA. auf einem alten Notebook laufen habe. Der DMA-1000 macht WOL und das Notebook ist damit sowas wie ein Demandserver...geht nur an wenn ich es brauche :-)
Im Moment (bisher vergeblich) versuche ich an die Sourcen zu kommen da viele Teile der GPL unterliegen...aber die mauern bei Zyxel :-(

Hallo zusammen,

bisher gabs keine zuverlässigen Messungen zum Thema Stromverbrauch. Also habe ich heute mal zwischen Netzteil (5V) und MGB100 nachgemessen:

Idle, WLAN-Modul nicht geladen: 0,71A
Idle, wie oben, HD in Ruhe (*) : 0,67A
Download über NFS: 1,0-1,1A
WLAN-AP, idle, HD in Ruhe (*): 0,77A
WLAN-AP, NFS-Download: 1,1-1,2A
WLAN-AP, idle, HD spindown: 0,7A

(*) Die HD schaltet nach ein paar Sekunden idle in einen anderen Zustand um, der 40mA weniger braucht. Das ist kein Anhalten, das spart nochmal 70mA. So gesehen lohnt sich das Anhalten der HD nicht wirklich. Abschalten des WLAN bei Nichtgebrauch bringt hingegen 100mA weniger.

Vom Netzteil abgesehen liegt der Stromverbrauch also incl. HD (eine neue 2.5" von WDC mit 5400rpm) in den meisten Fällen unter 5W. Dem Netzteil billige ich nochmal 2W zu, also je nach Betrieb zwischen 6 und 8W alles zusammen. Nicht schlecht für die Leistung. Wer USB nicht oder nur sparsam benutzt (USB-Stick oder Geräte mit Fremdspeisung) kommt mit einem 1,5A Netzteil hin.

Tes

Hallo Leute,

hier MGB100_400S04.img gibt es wieder mal was Neues:

BusyBox 1.7.1
verbessertes Reboot/Halt (mit sync, umount)
Kernel_nfs integriert (mnt/C autom freigegeben)

über eine autoexec (/mnt/C/autoexec oder /mnt/USB/USB_C/autoexec) lassen sich natürlich die
/etc/exports
/etc/init.d/rcS
/etc/init.d/rc.shutdown
/etc/init.d/rc.restart
nach euren Wünschen anpassen.

sonst nichts neues, leider auch beim eth Treiber keine neuen Erkenntnisse.

schufti

Moin moin,

auf Deutsch ist es echt einfacher für mich! :)

als erstes hier auch noch mal vielen dank an alle für die Arbeit!

Nun zu meiner Frage:
Ich habe hier eine Pearl Box die zwischndurch schon alles mögliche
war, inklusive einer Spanischen Concepttronicx!?
Naja wie auch immer, mittlerweile ist sie wiede reine Pearl (glaub ich),
allerdings mit telnet frei geschaltet, nachdem ich aus dem macsat forum upgrade v4 geflashed habe.

Naja jetzt würde ich gerne wissen, ob ich einfach http://rapidshare.com/files/57042078...00S03.img.html Drauf bügeln
kann, oder ob ich nochmal von Vorn anfangen soll?


MfG

Karsten

Hi karsten,

die meisten haben die Erfahrung gemacht, dass meine V4 upgrades auf der Pearl FW zu Problemen mit dem Login auf der Weboberfläche führen (Passwort wird nicht akzeptiert) Telnet fuinktioniert aber ???

Bisher konnt eich das Problem nicht lösen, daher 'rebrande' ich meine als LevelOne und mache die FW(400b8) von denen drauf. Auch OvisLink (400c1 achtung: hat nach reset anderes PW) läuft bei mir ok.

schufti

Hi Zusammen,
mal eine Frage von einem Neuling,
Ich hab die PE-4088 von pearl gekauft - hab etwas weiter vorne gelesen das die AirLive WMU-6500FS ziemlich ähnlich ist - hat da schon mal jemand versucht die neuestes Firmware aufzuspielen?
Hat jemand vielleicht eine andere Firmware für die PE-4088?
Bin noch im Zeitraum das ganze zurückschicken zu können - überlege mir lieber die WMU-6500FS zu holen - da gibts wenigstens updates auf der homepage.
Danke für Tipps,
Gruß
Lausbub

Hi Lausbub,

tja, das war genau der entscheidende Grund für mich, nicht das 3,5" Gehäuse zu wählen. Denn ohne GPL Sourcen (auch die bei OvisLink sind unbrauchbar) wird das Ding nie besser.

AB HIER: ALLES AUF EIGENE GEFAHR !!!!!

Falls du experimentierfreudig bist und mit HexEditor umgehen kannst, sieh dir mal die WMU-6500 FW an. Da sollten mehrmals Abschnitte mit

OVS_RUS021...
Queen............

vorkommen. Ersetze das einfach durch

Queen.......
Queen.......

(übrige Zeichen nicht mit Leerzeichen sondern mit 00 überschreiben)

und versuche das mittels recoveryloader/tftp einzuspielen.

schufti

Hi Schufti,
danke für den Hinweis. Ich werds mal versuchen.
Hat noch jemand aus der älteren Firmware-Version a7v3 das Firmware-Upgrade-Utility? Das würd ich zuerst mal ausprobieren bevor ich mit tftp und recoveryloader arbeite ... (äh, wo gabs die noch mal? Sorry wenn ich jetzt etwas such faul bin ...).
Vielen Dank für jede Hilfe,
Lausbub

Hi Lausbub,

was ich zu erwähnen vergaß: da es für das Pearl Teil nichtmal eine aktuelle FW zum Download gibt, ist der Weg zurück dzt. ZU!

Mit einem fremden Upgrade utility geht auch nix...

schufti