Firmware 1.04RC6 für das Conceptronic CH3SNAS ist erschienen

Gestern ist der neue Release Candidate 6 der Firmware 1.04 für das Conceptronic CH3SNAS erschienen. Dieser behebt gegenüber der Firmware 1.03 neben den bisher behobenen Fehlern in RC5 und den vorhergehenden Releases folgende Fehler:

  • Wurde das CH3SNAS mit den folgenden Settings für NTP betrieben, so wurde die Zeit beim Neustart um eine Stunde zurückgestellt:
    • NTP Server: nl.pool.ntp.org
    • Time Zone: GMT +01:00
    • Daylight Saving Time: EU
  • Beim Editieren von Nutzern unter Mozilla Firefox 3.0.1, war der Nutzername plötzlich leer, bei manueller Eingabe gab es einen Timeout.

Zum Download

Nichts lebenswichtiges also, das Zeitproblem ist für fun_plug-Nutzer eher weniger relevant und das zweite Problem war eher kosmetisch…so oft legt man keine Nutzer an.

Veröffentlicht von

72 Gedanken zu „Firmware 1.04RC6 für das Conceptronic CH3SNAS ist erschienen“

  1. Hi Uli,
    ist das aus einer offiziellen Quelle?
    Auf der conceptronic-Seite ist noch nichts von RC6 zu sehen?

    Gruß
    Hans-Jürgen

  2. Mal ne Frage am Rande …zum FTP Server
    ich bekomme auch mit der neuen Firmware nur über Port 21 Zugang zum FTP Server egal ob mit FTP Programm oder per Browser es versuche… obwohl die Ports auch an der FritzBox freigegeben sind (Ja auch direkt für die NAS IP 😉 ).

    Laut Support sollte es egal mit welchem Port gehen aber die FritzBox als eine der besten Boxen … wüssten sie nicht ob es geht weil sie keine haben bzw. mit dem NAS getestet haben.

    Jemand eine Idee oder das selbe Problem.

    MfG

    Max

  3. Bei der Fritz!-Box und anderen Routern mit „Port-Weiterleitung“ funktioniert das so, daß eine Tabelle angelegt wird / ist, nach der die vom Internet aus angesprochenen Ports auf die jeweiligen Netzwerkserver-Ports weitergeleitet werden. Das kann 21 –> NAS-IP Port 21 sein, aber auch z.B. 21 –> NAS-IP Port 4217.
    Im letzteren Fall muß der NAS-FTP-Server Port 4217 verwenden, während er aus dem Internet über den Standard-FTP-Port 21 erreichbar ist.
    Manche Router erlauben auch eine Port-Range-Weiterleitung, d.h. „alle Ports von A bis B werden auf Gerät X weitergeleitet (ggfs. an Port Y)“.

    Vorsicht bei den Fritz!-Boxen: Die Boxen, die einen USB-Host haben, verfügen über einen internen FTP-Server, der Port 21 belegt und angeschlossene Massenspeicher über diesen FTP im Internet freigibt.
    D.h. wenn Du den von der Box aktiviert hast und zusätzlich die NAS als FTP-Server verwenden willst, mußt Du eine Portweiterleitung erstellen:
    Internet-Port (z.B. 25) –> NAS-IP, Port 21 (oder der von Dir verwendete).

    Hoffe Dir geholfen zu haben :).

    Gruß
    HSishi

  4. Danke …

    ist leider nicht so das was ich meinte und auch nicht ganz richtig.

    FritzBoxen wie 7170 etc. die eine USB Schnittelle haben und diese per neuerer Firmware als FTP Server nutzen können (diese Funktion muss extra im Web Menu ausgewählt bzw. aktiviert werden) erst dann sind Sie so beschaltet das sie den 21 Port belegen. Was man glaube icha uch ändern kann.

    So Portweiterleitung ist ja ok … aber laut Web Menü des Nas und auch laut Support sollte es eigentlich so funktionieren das ich im web menu (vom NAS)dem ftp server den port z.B. 8080 gebe und diesen einfach in meinem router für die ip des nas freigebe. Und genau das geht nicht … ja die portweiterleitung geht aber warum soll die kuh zum bauern wenn der bauer frische milch will?

    Aber trotzdem danke vielleicht fällt dir ja noch was ein…

    MfG

    Max

  5. Hoi Max.

    Mit der extra Aktivierung in der FritzBox hast Du natürlich recht. Nicht aktiviert = Port nicht belegt. Den FTP-Port ändern geht in der FritzBox von der Konfigurationsoberfläce aus NICHT.

    Die Port-Weiterleitung MUSS in dem Fall sein, da die NAS nicht direkt am Internet ist, sondern im Intranet (= (W-) LAN), mit dem Router als Sperre. Der Router trennt die beiden Netze nach dem „standardmäßig sperren“-Verfahren, d.h. er läßt zwar Serveranfragen aus dem Intranet in’s Internet zu, aber keine Anfragen aus dem Internet an Server im Intranet.
    Diese müssen gesondert eingerichtet werden. Das kann per UPnP erfolgen (dafür müssen Router und Netzwerkclients das unterstützen und zulassen) oder halt manuell per Portweiterleitungen.

    Um zu dem Vergleich mit dem Bauern zu kommen:
    Nicht der Bauer will die Milch, sondern Du.
    Der Bauer ist der Router.
    Die Kuh ist die NAS.
    Der Bauer läßt nicht jeden an seine Kühe (Firewall).
    Wenn er Vertrauen zu Dir hat, gibt er Dir den Schlüssel zum Stall und sagt Dir, welche Du melken darfst (Port-Weiterleitung).

    Oh, und wir kommen vom Thema ab.

    Gruß
    HSishi

  6. ok also der Verglich hinkt auf allen 4 Beinen der Kuh xD …

    Danke für die Erklärung … sowas ist sogar besser als die sehr komplexen Erklärungen in meinen FIS Büchern von der Schule.

    MfG

    max

  7. Keine Ursache :). Das mit der Kuh hat nach Deiner Steilvorlage sogar irgendwie Spass gemacht zu schreiben und so versteht’s jeder *die Erklärung mal aufheb*.

    Gruß
    HSishi

  8. Bei mir isses Hobby. Der Umgang mit dem CH3SNAS hat sich aus Zufall ergeben … meine alte NAS hat gesuckt (zu langsamer Dateitransfer im LAN) und ich brauchte ein Gerät mit der Möglichkeit, nen echten Webserver aufsetzen zu können, inkl. MySQL und PHP.

    Das CH3SNAS hat sich zwar nicht direkt angeboten, aber als ich über das FunPlug gestolpert bin, hab ich fast nen Sekt aufgemacht 🙂 . Ich bereu‘ die für’s CH3SNAS ausgegeben 230 Euro nicht, dafür aber im Nachhinein die 80 Euro für die alte NAS.

    Gruß
    HSishi

  9. … 230 für den NAS mit HDD´s oder ohne?

    ja bin auch ehr durch Zufall darauf gestoßen aber da hatte ich das teil schon ein Jahr @home … aber muss sagen die Community ist da echt flott was Verbesserungen und Updates angeht.

    Danke an alle bei der Stelle die Helfen das Leben mit dem CH3SNAS einfacher und funktioneller zu gestalten.

    Hoffe das alles so weiter geht

    MfG

    max

  10. ~ 185 Euronen mit der ersten HD (160 GB WD Server-Edition = wenig Wärme aber etwas laut beim Anlaufen) und kürzlich 45 Euro für ne Samsung 320 GB .. leiser aber dafür wesentlich wärmer.

    Gruß
    HSishi

  11. OK … hab 140€ für den NAS und 90 für die 500 GB Samsung bisher dafür Ausgegeben … schluckt der NAS eig. jetzt auch 1TB HDD’s oder nur max. 750 GB

    MfG

    Max

  12. Sind mit der letzten Firmware-Version 1.04RC6 eigentlich die TWSI-Fehler weg?

    Könnte mal einer der mutigen Anwender etwas dazu sagen?

    Danke.

    MfG Thomas

  13. Schließe mich der Frage von Thomas an. ’ne Info zum TWSI-Fehler wäre wirklich sehr wichtig! Bin selbst mit 1.04RC5 davon betroffen.
    Linux hin und her – so „löppt“ es leider nicht so gut.
    Tritt der Fehler auf, geht weder ftp noch samba bei mir und mit einer falschen Temperaturmessung brauchen wir über Lüftersteuerung auch nicht zu reden.
    Wäre toll, wenn jemand was zu diesem Thema sagen könnte.

    Gruß Hans-Jürgen

  14. Mhh also ich würde sagen mit der RC6 „löppt“ es wieder … ich habe keine Probleme und auch keine entsprechenden Meldungen über dmesg

    … aber die Installation von RC6 hat bei manchen Usern Probleme verursacht…

    von daher würde ich funplug deaktivieren bevor ich RC6 installiere,

    nach der Installation factory defaults laden,

    noch einmal neustarten…

    und funplug wieder aktivieren.

    Viel Spaß beim Testen.

    Quellen: http://www.aroundmyroom.com/2008/09/08/ch3snas-104rc6-firmware-release/

    Bugs??? bei RC6: http://www.aroundmyroom.com/2008/09/19/request-for-comments-ch3snas/

    MfG

    Max

  15. OK. Danke Max für Deine Infos.

    Habe es gewagt und seitdem keine TWSI-Errors mehr!
    Mit 1.04RC5 trat der spätestens nach 2 Tagen bei mir auf.

    Das ist doh was und hätte eigentlich eine eigene Meldung verdient, oder Uli?

    Gruß Thomas

  16. @Papaloewe:
    Sorry, einer deiner Kommentare hin in der Warteschleife wegen Spamverdacht 😉

    Also eine eigene Meldung insofern ja, als das ich das an Conceptronic mal weitergegeben habe. Wäre toll, wenn das beseitigt wäre. Warten wir mal die nächste RC bzw das Final-Release ab, dann gibts eine Meldung 😉

    Viele Grüße
    Uli

  17. Hallo Thomas,

    wie bist du beim Update vorgegangen? (fun_plug vorher deaktiviert?) Gab es irgendwelche Besonderheiten?

    Gruß
    Hans-Jürgen

  18. Ich bin zwar nicht Thomas, aber bei mir hab ich einfach die Firmware mittels CH3SNAS-Webinterface eingespielt. Kein Vorspiel, kein Nachspiel (= keine Probleme nach dem Update).

    Gruß
    HSishi

  19. 19:15 mit dmesg log kontrolliert -> übliche Fehler
    fun_plug vorsichtshalber doch umbenannt, reboot -> boot-Schleife
    Netzstecker gezogen
    19:20 mit dmesg log kontrolliert -> alles wieder ok
    Settings (lokal) gesichert,
    19:21 Luft kurz angehalten, FW 1.04 RC6 installiert, Restart, Settings geladen, nochmal Restart und …

    … es geht wieder. 🙂

    Gruß
    Hans-Jürgen

  20. @Hans-Jürgen,

    Sorry, Deine Frage sehe ich erste jetzt.

    Ich bin wie in dem Blog des Holländers beschrieben vorgegangen.
    „…1. rename the fun_plug to disable it
    2. upgrade to RC6
    3. reset to default…“

    Natürlich vorher noch die kompletten Einstellungen gesichert und nach dem Rücksetzen auf „factory defaults“ wieder zurückgespielt.

    Gruß Thomas

  21. Hallo,

    habe soeben RC6 eingespielt:

    1. Backup über Webinterface
    2. Backup von Fun_plug
    3. Rename von Fun_plug
    4. Reboot
    5. Firmwareupdate über Webinterface
    6. Reboot
    7. Fun_plug wieder richtig benannt
    8. Reboot

    Bisher sieht alles gut aus, das Lüfterscript arbeitet.
    Warten wir mal 2 – 3 Tage ab.
    Dann werden wir sehen, ob die TWSI-Meldungen nun nicht mehr protokolliert werden, sondern nur noch stillschweigend geschehen -);

    Gruß

  22. Und heute waren die TWSI-Meldungen wieder da.

    Nach dem Update habe ich nicht die Werkseinstellungen zurückgesetzt. Das könnte eine mögliche Ursache sein.

    Ich habe heute auf jeden Fall das Lüfterscript deaktiviert, und auf fanctl umgestellt.

    Nun warte ich wieder einige Tage…

  23. hat schon jemand infos wann wohl die 1.5er (mit integriertem BT client wie beim dns) erscheint?
    bin weder mit mldonkey noch mit transmission zufrieden, alles zu viel handarbeit und zu wenig komfort.

  24. Hallo,

    die TWSI-Fehlermeldungen sind nach wie vor da.
    Nach einer Woche andauernder Einträge liefert nun auch

    Temperature g 0

    wieder 0 zurück.
    fanctl hat aber scheinbar eine Sicherheitsroutine, die dann den Lüfter automatisch anschmeisst. Gefällt mir soweit sehr gut.

    Ich mache nun einen Reset auf Werkseinstellungen und lade dann meine Einstellungen wieder. Eventuell hilft das ja noch.

    Bis dann….

  25. Hallo HHF,

    wie oben schon einmal beschrieben und auch in der FAQ von Conceptronic solltest du nach dem Update einen Reset der Einstellungen durchführen!
    Andernfalls kann es sein das behobene Probleme der Firmware nicht übernommen werden!!!

    Ich habe keine TWSI Fehler mehr mit der RC6 seit gut 1 Monat.

    MfG

    Max

  26. Hallo,

    ich habe das gleiche Problem mit dem TWSI Fehler wie HHF. Reset to factory defaults nach dem Update zu RC6 hatte auch nichts gebracht. Habe auch alle Einstellungen neu vorgenommen ohne ein restore. Schon nach einem Tag trat dieser Fehler wieder auf. Nun Versuche ich gerade herauszufinden an welchem Dienst es liegt könnte. Aktiviert hatte ich aus dem fun_plug 0.5 nur SSH, NTP und fanctl. Nun habe ich vorerst NTP und fanctl deaktiviert und werde ein paar Tage warten.
    Von der Firmware habe ich die Server UPnP, FTP und ITunes deaktiviert was auch vorher schon der Fall war.
    Sollte ich das Problem irgendwie eingrenzen können, werde ich es hier schreiben.

    @Max: Es wäre interessant welche Dienste du alles aktiviert hast?

    Gruß Sebastian

  27. Hallo Sebastian,

    der Reset hat bei mir auch nichts gebracht.
    TWSI-Fehler ohne Ende.

    Temperature g 0

    gibt wieder nur 0 zurück.
    UPnP, FTP und ITunes ist deaktiviert.
    Ansonsten laufen genau die gleichen Dienste wie bei Dir, zusätzlich nur noch der Cronjob für rsync. Der ist aber wohl auszuschließen.

    Gibt es bei Dir etwas neues?

    Schönes Wochenende

  28. Ich habe die Vermutung das es an dem ntpd Dienst liegt. Ich habe ihn jetzt deaktiviert und nun läuft das NAS. Mir ist aufgefallen, dass der drift (/ffp/etc/ntp.drift) trotz der Korrektur der Ticks im /ffp/etc/fun_plug.local die 500.000 erreicht. Dieses könnte erklären warum der Fehler erst nach ein paar Tagen auftritt. Habe mir nun einen cronjob hinzugefügt der mir stündlich die Zeit mit sntp einstellt. Mal sehen was die nächste Woche ergeben wird. fanctl läuft soweit super.

  29. Nachdem ich jetzt den ntpd Dienst abgeschaltet habe läuft mein NAS ohne Probleme und der TWSI Fehler erscheint nicht mehr. Die Lüftersteuerung fanctl läuft ebenfalls einwandfrei. Damit ich auch ohne ntpd eine korrekte Zeit auf dem NAS habe, habe ich wie weiter oben schon beschrieben /usr/sbin/sntp -r -P no de.pool.ntp.org als cronjob eingefügt.

  30. Danke für das Update.
    Habe ntpd nun auch deaktiviert und crontab erweitert:

    */10 * * * * /usr/sbin/sntp -r de.pool.ntp.org >> /ffp/log/sntp.log

    Damit wird sntp nun zuverlässig alle 10 Minuten gestartet, was über das Log geprüft werden kann.
    Leider ist die Parameterbeschreibung von sntp mit –Help sehr bescheiden.
    So habe ich keine Ahnung, was

    -P

    (Prompt macht ja wohl keine Sinn) und

    no

    bedeuten. Kann das jemand beantworten?

    Wenn ich mir nun Crontab mit -l ansehe, habe ich aber noch 3 Einträge drin:


    32 2 * * * /usr/sbin/rtc -s
    30 2 2 * * /usr/sbin/rtc - c
    59 1 * * * /usr/sbin/daylight &

    Werden die noch benötigt?
    Wenn nein, wie kann ich die loswerden?

    Danke

  31. Habe gerade nochmal recherchiert.
    rtc = Real Time Clock
    Die wird ja wohl sicher nicht mehr benötigt.
    Aber wie kann ich Crontab editieren?
    Mit Crontab -e öffnet sich ein editor. Die vi-Befehle klappen hier aber nicht. Ich schließe daraus, das es sich nicht um vi handelt.
    die Umgebungsvariablen $EDITOR und $VISUAL habe ich aber bereits auf /ffp/bin/vi gesetzt.

  32. Hi HHF,

    das mit der Option -P no kann ich dir auch nicht beantworten da ich es so im Netz gefunden habe.
    Zu deinem Cronjob habe ich noch eine Anmerkung. Das Log was du alle 10 Minuten schreibst geht auf die erste Festplatte, was bedeutet das diese nicht mehr in den Standby gehen kann. Sollte das nicht der Fall sein ignoriere dies einfach.
    Zum hinzufügen und entfernen benutze ich das folgende Skript was bei jedem Bootvorgang ausgeführt wird.


    #!/ffp/bin/sh
    # add jobs for root user

    cronfile=/var/spool/cron/crontabs/root

    # remove cronjobs
    cat $cronfile | grep -vw '/usr/sbin/daylight' | grep -vw '/usr/sbin/rtc' > $cronfile

    # add new cronjobs
    echo "1 * * * * /usr/sbin/sntp -r -P no de.pool.ntp.org" >> $cronfile
    echo "0 5 * * 4 /mnt/HD_a2/.nas_conf/set_rights.sh&" >> $cronfile
    echo "10 5 * * 4 /mnt/HD_a2/.nas_conf/backup.sh&" >> $cronfile
    # force a cronjob update
    echo "root" >> /var/spool/cron/crontabs/cron.update

    Ich hoffe das kann dir weiter helfen.

  33. Hi Seb,

    besten Dank für das Skript.
    Mit anderen Worten fügt die Firmware die 3 Jobs bei jedem Reboot wieder als Cronjob an.

    Zum Standby der Festplatten:
    Ich habe den FunPlug auf einem USB-Stick. Standby funktioniert daher noch wunderbar. Das Log ist sowieso nur zur Erfolgsprüfung. Das werd ich langfristig nicht so lassen, da es den Output immer wieder anfügt. Irgendwann wäre dann auch der Stick voll.

    Schönes Wochenende

  34. @Seb: Danke für die Scripts, ich glaube wir hatten per Mail mal Kontakt, richtig? Kommt mir zumindest bekannt vor 😉

    @HHF: Vor allem hat ein USB-stick nur eine begrenzte Menge an Schreibzugriffen, also vorsichtig 😉

    Ich bin mal gespannt, ob das tatsächlich das Problem umgeht.

  35. Hi Uli, ja wir hatten schon Kontakt per Mail.

    Bis jetzt sind meine Ergebnisse, was den TWSI Fehler angeht, positiv. Ich denke das man diesen Fehler vielleicht auch durch genaues anpassen des Arguments hinter adjtimex in der fun_plug.local beheben kann da der Drift scheinbar zu groß wird. Aber das werde ich nicht testen da ich im Moment zufrieden bin (Never touch a running system!).

    Sollte es doch noch Probleme geben, werde ich es hier wieder schreiben, was ich nicht hoffe.

  36. Irgendwie fehlt mir noch ein kleiner Teil: Wenn ich das korrekt verstehe, hast du ja den NTP-Dienst des CH3SNAS (also den von Firmware-Internen) abgeschalten? Denn den habe ich gar nicht aktiv, bei mir ist der des FFP aktiv und trotzdem tritt der TWSI-Fehler auf. Sehr seltsam….

  37. Sorry das ich das nicht eindeutig beschrieben habe.
    Der Fehler wird höchstwahrscheinlich vom NTPD Dienst des fun_plug 0.5 verursacht (/ffp/start/ntpd.sh) und nicht vom NTP-Dienst der Firmware. Wenn ich den NTPD des fun_plug 0.5 nach deiner Anleitung aktiviere, bekomme ich den TWSI Fehler und die Datei /ffp/etc/ntp.drift zeigt mir immer 500.000 wenn der Fehler auftrat. Ein Zusammenhang zum Firmware eigenen NTP Client konnte ich nicht erkennen. Also einfach

    chmod -x /ffp/start/ntpd.sh

    und der Fehler sollte nicht mehr auftreten.

  38. Ich bestätige ebenfalls das es sich um ntpd.sh vom FunPlug 0.5 handelt.
    Die erste Nacht ist ohne TWSI-Fehler überstanden, der Standby der Festplatten funktioniert wie gewünscht.

    @Uli:
    Danke für den Hinweis mit den Schreibzugriffen auf den USB-Stick. Habe nun das Log ausgebaut.
    Mein rsync-Log habe ich auf die 1. Platte umgeleitet, da diese dann sowieso aktiv ist.

    Frohe Zeitumstellung….

  39. @HHF:

    I disabled ntpd.sh but still get the temperature readout changing to 0/32 after a certain time. Did you also disable the adjtimex setting in fun_plug.local?

  40. Hi Jasper,

    after a week, my temperature is still 32 degrees celsius.
    But, as i did not have installed the script from sebastian, the original crontab jobs have been executed and my time is wrong now (2 hours less).
    I did not made any changes to the adjtimex line in the fun_plug.local.

  41. habe jetzt ebenfalls den ntpd vom FunPlug 0.5 deaktiviert. Ich hoffe, dass ich damit den TWSI-Fehler ebenfalls los bin.

    Gruß
    Hans-Jürgen

  42. Hello Jasper,

    I didn’t disabled the adjtimex in the fun_plug.local file but I had adjusted this value from 9965 to 9960. Until now I didn’t had any problems with the TWSI or the time. It seems that my sntp cronjob runs good.

    Regards
    Sebastian

  43. Hallo,
    nach 2 Wochen Test nun keinen einzigen TWSI-Fehler mehr. Das Deaktivieren von ntpd hat also definitiv das Problem beseitigt. Lüftersteuerung funktioniert prima. Auch das Problem mit der falschen Temperaturanzeige trat nicht mehr auf.

    Gruß
    Hans-Jürgen

  44. Hallo zusammen,

    die Option „-P no“ beim Aufruf sntp bewirkt laut der sntp-manpage, daß bei großen Zeitdifferenzen nicht nach einer Bestätigung der Korrektur gefragt wird, was man ja in der Regel bei cronjobs auch nicht kann ;-). Insofern ist „-P no“ ein sinnvoller Parameter für sntp an dieser Stelle…

    Bzgl. der TWSI-Problematik ist mir jetzt immer noch nicht ganz klar, was genau das Problem auslöst. Der ntpd vom fun_plug, der adjtimex-Aufruf in fun_plug.local, oder die Kombination von beidem? Ich habe auch einen stündlichen sntp-Abgleich per cron eingerichtet, habe aber keinen adjtimex-Aufruf mit dabei, der ist meines Erachtens dann auch gar nicht nötig. Ich habe aber ganz „frisch“ von 1.03 auf 1.04RC6 upgedated, so daß ich noch keine Langzeiterfahrungen vorweisen kann. Was ist denn aktuell Stand der TWSI-Dinge? Dank oben angesprochener Sicherheitsschaltung von fanctl braucht man sich ja wohl keine zu großen Sorgen mehr zu machen.

    Gruß,
    Rocco

    —–

    aus der manpage von sntp:

    -P prompt

    sets the maximum clock change that will be made automatically to maxerr. Acceptable values are from 1 to 3600 or no, and the default is 30. If the program is being run interactively in ordinary client mode, and the system clock is to be changed, larger corrections will prompt the user for confirmation. Specifying no will disable this and the correction will be made regardless.

  45. @Rocco: Als Ursache hat sich wohl der gleichzeitige Zugriff auf das TWSI herausgestellt. Zeitserver & jegliche Fancontroller greifen gleichzeitig auf das TWSI zu und verursachen wohl die bekannten probleme. Das Umstellen des Zeitservers auf Cron macht nur die Wahrscheinlichkeit geringer, sinnvoll wäre aber eine Steuerung von ntp über das fanctl, sodass ein derartiger, gleichzeitiger Zugriff ausgeschlossen werden kann.

  46. Das wäre aber auch nur ein Workaround, denn inhaltlich sind fanctl & ntp ja zweierlei Schuhe. Das ist schon seltsam, daß das TWSI das nicht handeln kann. Vom Gefühl her ein Kernel-Bug – ich meine mich aber auch an ein Post von fonz in irgendeinem Forum zu erinnern, daß dies bei bestimmten 2.6.25er Kerneln nicht auftreten würde.

    Als Workaround würde ich da eher sntp per cron nur einmal pro Tag laufen lassen mit vorherigem Stop und anschließendem Neustart der Lüftersteuerung. Weiß jemand, um wieviel Sekunden die Uhr im Laufe von 24 Stunden driftet?

  47. Ja 2.6.25 soll da laut fonz besser sein:

    I think it’s a kernel bug. While I see the TWSI errors within hours/days on 2.6.12.6, I’ve never seen it (or any of the symptoms) on 2.6.25.

    Problem daran ist, dass wir auf dem CH3SNAS noch keinen ffp-reloaded-kernel starten können und das Conceptronic derzeit 2.6.12.6 mit der Firmware 1.04RC6 ausliefert. Insofern kann man das nur wie von mir oder dir beschrieben umschiffen. Bezüglich des Drifts: Das Problem dabei ist, dass die Geräte unterschiedlich schnell driften (daher der adjtimex-Befehl). Wenn man diesen Drift korrigiert, muss man nicht so oft auf das TWSI zugreifen, um eine neue Zeit zu setzen.

  48. Hallo Uli,

    habe gerade mal wieder einen fehler gehabt der mir schon seit längerem nicht mehr passiert ist.

    Irgendwann wenn mein NAS läuft komme ich nicht mehr ins Internet.
    Firewalls etc. kontrolliert … keine Änderungen
    Router (Fritz!Box 7170) –> Seite kann nicht angezeigt werden
    NAS Webseite –> kann nicht angezeigt werden
    Netzlaufwerke auf dem NAS –> Verbindung nicht möglich

    erst ein Neustart des NAS behebt diesen Fehler.
    NAS hat eine feste IP, DNS und Gateway sind beide korrekt eingetragen.
    Firmware: 1.04RC6
    Lighttpd, MySQL, PHP, FTP, TFTP, fanctl laufen
    dmseg –> keine TWSI Fehler nach dem Neustart.

    Hat jemand zufällig eine Idee?
    Oder diesen Fehler schon einmal gehabt?

    MfG

    Max

  49. Mein NAS läuft jetzt seit 45 Tagen durchgehend auf Firmware 1.04RC6 und ich hatte diesen Fehler noch nicht, sorry…

    Sieht mir aber eher nach einem seeeehr komischen problem aus, denn die Fritzbox hat normalerweise damit nix zu tun (habe hier selbst eine 7170). Probier mal folgendes beim nächsten mal: Schließe das NAS direkt an den Rechner (ohne Umweg über die Fritzbox) und schau, ob du dann nicht drauf kommst. Ich sehe den Fehler eher bei der Fritzbox (Stromspareinstellungen der Ports vielleicht?).

  50. Hi Uli,

    danke mal wieder für die schnelle Antwort.

    Mhh das mit denn Stromsparfunktionen der Fritz!Box kann es eig. nichts zutun haben da das ganze über einen extra Switch angeschlossen ist.
    Und an diesem Switch alle Sachen hängen (PC’s, NAS, Drucker).

    Aber ich werde mal schauen wann der fehler mal wieder kommt, jetzt hat es gut 3 Monate gedauert 😀 … naja mal sehen.

    Ach und noch eine frage wegen dem kernel Update des NAS, ich meine in einem Forum was von fonz gelesen zu haben man könnte das mit einem debian auf dem nas durchführen?!

    Hab ich das noch richtig in Erinnerung?

    MfG

    Max

  51. Okay, dann ist meine Infrastruktur die gleiche wie deine. Probiers aber doch mal. Dann könnte höchstens noch der Switch irgendwas in den falschen hals bekommen haben.
    Wegen dem Kernel-Update habe ich nix gelesen. Wenn ich so drüber nachdenke wüsste ich jetzt auch nicht, wie das gehen sollte. mit einem Reloaded-kernel => JA. Aber Debian? Wüsste nicht wie.

    Prinzipiell könnte ffp-reloaded auch auf dem NAS gehen, aber dazu fehlt noch eine Änderung am Kernel, die man erst probieren muss, da sich die beiden Festplattencontroller des CH3SNAS und der DNS-323 unterscheiden und daher sonst keine Festplatten im ffp-reloaded-kernel verfügbar wären. Momentan habe ich für diese Dinge blöderweise keine Zeit…nach Weihnachten vermutlich wieder.

  52. Hallo Uli,

    ja ich werde mal den Switch tauschen und denn Port von der Fritz!Box von der Energiesparfunktiona ausschließen.

    Das mit den Test hört sich doch gut an. Hat man doch schonmal etwas worauf man sich im neuen Jahr freuen kann.

    Vielleicht ändert ja auch Conceptronic den Kernel, wer weis das schon.

    Zu den Unterschieden des CH3SNAS und dem DNS-323, ich dachte da wäre nur eine andere Firmware drauf und sonst wären das die selben Geräte?!

    MfG

    Max

  53. Hallo Uli,

    der Link für den Forumsbeitrag von fonz hängt bestimmt wieder im Spam.

    War zwar heute schon auf der Seite aber das hab ich wohl übersehen^^.

    Ich danke dir mal wieder.

    MfG

    Max

  54. Gibt es die Möglichkeit Firmwaremäßig einen dns-323 aus dem CH3SNAS zu machen ? Das Ding nimmt eben nicht alles an Platten, was es gibt – meine beiden seagate barracuda 1.5tb werden mit 0gb angezeigt. beim dns-323 soll es angeblich gehen, wenn auch nicht im RAID

  55. Gibt es, aber ich rate davon ab. verkauf lieber das CH3SNAS und kauf ein DNS-323, da hast du langfristig mehr davon. Ob und welche Platten gehen, die oberhalb von 1TB liegen, weiß ich leider nicht. Wenn du wirklich die Firmware tauschen willst, dann suche mal im DNS-323-Forum.

  56. Hallo zusammen,

    ich habe zwar keine wirklich neuen Erkenntnisse, wollte aber mal kurz berichten, wie ich aktuell das TWSI-Thema behandle.

    Einmal täglich mache ich bei gestarteter fonz-Lüftersteuerung in der Nacht per cronjob einen Zeitabgleich per sntp (beim Boot ebenfalls einmal). Zusätzlich zum bereits genannten sntp-Aufruf habe ich als Switch noch „-v“ übergeben, damit gibt sntp unter anderem aus, um wieviel Sekunden die Systemzeit korrigiert werden mußte. Mich interessiert halt, wie groß bei mir der tägliche Drift ist. Der oben angegebene Parameter „-r“ besagt übrigens, daß sntp die Zeit über den settimeofday-Call setzt, alternativ ginge das noch über den adjtime-Call mittels des Parameters „-a“. Ich weiß nun aber nicht, ob beide Calls mit den TWSI-Zugriffen von fanctl kollidieren oder nur einer von beiden. Müsste man mal testen, indem man sntp per cron minütlich aufruft und einfach abwartet.

    Insofern habe ich täglich einen möglichen Parallelzugriff auf das TWSI. Desweiteren greppe ich einmal pro Stunde per cron durch den dmesg-Output und lasse mir Fehlerfall eine Mail schicken, so daß ich halbwegs zeitnah reagieren könnte. Dafür nutze ich das vorhandene email-Binary (zu finden in /sys/crfs/sbin/) mit dem Testparameter „-t“, insofern habe ich den ein wenig „umfunktioniert“, „t“ steht also jetzt bei mir für „TWSI“ ;-).

    Ich tippe mal, daß das so keinerlei Probleme geben wird, denn im Gegensatz zum ntpd setzt sntp nur die Systemzeit, und nicht die der RTC (kann man mit „rtc -r“ gut testen & nachvollziehen). Da ich aber auch beim Boot die Zeit einmal per sntp setze, bin ich stets aktuell dabei und mir sollte eigentlich egal sein, was in der RTC steht…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.