WL-HDD Alternative

[schufti]

Hi Tes,

ich denke nicht, dass sich mein v400s02 image da anders verhält, als das Original. Wenn man nicht über die vorgesehene Tastenkombination runterfährt wird m.E. kein vernünftiges sync oder umount gemacht.

Daher habe ich im s02er Image ja auch ein vernünftiges Init/Shutdown vorgesehen, nur im angelegten Shutdownskript fehl(t)en die Befehle. Aber für Verwender des KK-Image sollte das eigentlich egal sein, die müßen dass eh in den eigenen Skripts machen.

schufti

[normancz]

Hi,
hat schon mal jemand ein ipkg upgrade gemacht?

Beim Update der base-files dachte ich mehr an die basis-Binaries, aber irgendwie wurden wohl die ganzen Konfigurationsdateien übergebügelt. WLAN geht nicht, und die alte IP ist auch weg.

Leider geht auch 192.168.2.1 nicht und nun stehe ich da. Hat jemand eine Idee?

[Tes]

Hi,
hat schon mal jemand ein ipkg upgrade gemacht?

Nein, ich trau dem nicht, vor allem weil vieles schliesslich für 2.6 gedacht ist aber unsere Box noch mit 2.4 läuft. Zumindest würde ich es nicht tun ohne vorher ein aktuelles Backup des Autobootfs gemacht zu haben.

Beim Update der base-files dachte ich mehr an die basis-Binaries, aber irgendwie wurden wohl die ganzen Konfigurationsdateien übergebügelt. WLAN geht nicht, und die alte IP ist auch weg.

Leider geht auch 192.168.2.1 nicht und nun stehe ich da. Hat jemand eine Idee?

Ausser ein Backup einzuspielen (ich mache nach jeder grösseren Änderung eine Kopie des Autobootfs) fällt mir nur folgendes ein... Hast du die serielle Schnittstelle rausgeführt? Wenn ja, könntest du darüber zumindest rausfinden welche IP die Kiste jetzt hat (falls das Netz noch startet) oder zumindest diesen Teil reparieren. Wo der Anschluss zu finden ist und was sonst noch fehlt wurde in diesem Thread schon beschrieben.

Alternativ kannst du das Originale 'autobootfs' nach 'autoboot' umbenennen, auf einen USB-Stick kopieren und von dem booten (der Code im Flash sucht zuerst auf USB und dann auf der internen HD). Dann das autobootfs der internen HD ueber loopback mounten und nachsehen was alles im Eimer ist.

Ich hatte allerdings auch schon Probleme mit einer neueren busybox, mit der funktionierte das 'insmod' nicht mehr und damit auch kein WLAN. Updates kritischer Programme sollte man also nur mit aktuellem Backup machen!

Tes

[Tes]

Hi Tes,

ich denke nicht, dass sich mein v400s02 image da anders verhält, als das Original. Wenn man nicht über die vorgesehene Tastenkombination runterfährt wird m.E. kein vernünftiges sync oder umount gemacht.

Daher habe ich im s02er Image ja auch ein vernünftiges Init/Shutdown vorgesehen, nur im angelegten Shutdownskript fehl(t)en die Befehle. Aber für Verwender des KK-Image sollte das eigentlich egal sein, die müßen dass eh in den eigenen Skripts machen.

schufti

Hin und wieder benenne ich das autobootfs um und boote den Code im Flash. Das hat 2 Gründe:

1) Bisher schaffe ich immer noch keinen sauberen umount des FS auf dem das autobootfs liegt. Also ist das FS immer unsauber. Hin und wieder mal ein e2fsck ist anzuraten. Alle anderen FS incl. autobootfs werden sauber auf read-only gesetzt oder schaffen den umount. Die dafür nötigen Einträge hatte ich hier schon gepostet.

2) Nach jeder grösseren Änderung und deren Tests mache ich ein Backup des autobootfs. Das geht nur sauber wenn es nicht gerade in Benutzung ist.

Es wäre also schon gut, wenn das Image im Flash einen sauberen umount aller Filesysteme bei 'halt' oder 'reboot' machen würde. Oder kann die eingebaute busybox keine entsprechenden Einträge in der inittab?

Natürlich könnte ich 1) und 2) auch über einen USB-Stick mit einem autobootfs erschlagen, aber das macht mehr Arbeit. Da müsste ich doch glatt zur Kiste hinlaufen und einen USB-Stick einstecken und nachher wieder abziehen...

Tes

[schufti]

Hi Tes,

natürlich kann die neue BB das (die könnte sogar echte runlevels) und ist (wie ich schon schrieb) auch im s02 Image vorgesehen; schau mal in /etc/init.d/shutdown.rc. Über eine autoexec auf der C Platte kannst du die shutdown.rc ja durch eine angepaßte ersetzen.

das ganze läuft jetzt so ab:

der Kernel startet nach dem Boot /sbin/init wo auf Vorhandensein einer autobootfs oder autoinit getestet wird. Ist nichts davon da, wird BB als echtes Init über linucrc gestartet. Dadurch wird die inittab gelesen und das darin eingetragene Startskript gestartet (standardkonform rcS), weiters restart.rc / shutdown.rc

schufti

[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.

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 !

[Tes]

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...

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

[tobi]

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.

[marobo]

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.

[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.

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.

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

[Tes]

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:

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)

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

[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.

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

[marobo]

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:

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":

root@WHD:~# ifconfig
br0 Link encap:Ethernet HWaddr 00:50:18:488: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:488: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...

[marobo]

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.

[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