BitSwitcher - neue Firmware für Speedport W500V

[Duplomonster]

Mit "logread" (nicht getestet, das wäre aber der Normalfall) ?!?

Das hatte ich auch gedacht, aber scheinbar ist der Befehl auf dem Router nicht vorhanden...

 

[Lippton]

@Lippton

Es wurde mehrfach berichtet, das der Router bei aktivierter Zwangstrennung manchmal nicht richtig reconnected. Bei der nächsten Version wird da sicher was dran geändert, bis dahin würde ich bei aktivierter Zwangstrennung einfach einen Reboot anstatt einen Reconnect einstellen.

Zwangstrennung gibt es bei mir aber nur von Providerseite, ich habe da nichts aktiviert.
Werde es aber mal mit "reboot" aktivieren.

Lippton

 

[IP-Meister]

@Duplomonster

'logread' wird ab der nächsten Version in der busybox drin sein. Wenn du es sofort brauchst, dann kannst du dir ja ein eigenes Image kompilieren.

 

[Lippton]

@Lippton...bis dahin würde ich bei aktivierter Zwangstrennung einfach einen Reboot anstatt einen Reconnect einstellen.

So das scheint wirklich erfolgreich zu sein. Zur Zeit keine Probleme von meiner Seite!

Lippton

 

[Duplomonster]

@IP-Meister
Nee, so dringend brauch ich es dann doch nicht. Außerdem fehlt mir da auch das Know-How für das Rumkompiliere und an der Busybox rumgebastele. Wollte nur mal wissen, was der Router so ausspuckt an Systemmitteilungen. Hab es mit diversen Hilfeseiten nun hinbekommen, dass syslogd das Ganze übers LAN an nen anderen PC verschickt, was erstmal reichen dürfte. Muss der PC zwar an sein, aber bis zum nächsten Image von euch geht das.
Noch ne andere Frage: Wie oft bzw. wann wird die interne Uhr des W500V per NTP abgeglichen? Mir ist aufgefallen, dass wenn der W500V im Modem-Betrieb läuft, die Uhr richtig gestellt wird, jedoch als WLAN-Client zwecks VoIP stellt sich die Uhr nicht, sondern läuft unverändert vom "Reboot-Datum" aus. Der NTP-Server ist aber per PING zu erreichen vom W500V aus.

 

[rannseier]

Ich habe zur Zeit kein Netzwerkkabel an dem Targa mit aktuellem BS, nun rebootet das Teil gelegentlich.

Hat dass einen bestimmten Grund?

 

[IP-Meister]

@Duplomonster
Ja ist mir auch schon aufgefallen, das liegt daran das das NTP-Skript nur beim Starten einmal gerufen wird und ansonsten immer nur bei DSL-Reconnects. Das ist im WLAN-Client Fall natürlich quatsch, deshalb müsste da noch eine Option rein das er automatisch alle paar Minuten/Stunden aktualisiert.
Bis dahin würd ich an deiner Stelle einfach ins custom_script nochmal unten reinschreiben: /etc/start_scripts/date.sh
Das sollte eigentlich reichen....

@rannseier
Na entweder du hast einen geplanten Reboot eingestellt oder es kommt ab und zu zur Kernel-Panic, dann rebootet er auch nach einer gewissen Zeit. Das passiert aber im Normalbetrieb wirklich so gut wie nie.

 

[rannseier]

Da tippe ich eher auf Kernelpanik.

 

[Duplomonster]

@IP-Meister
Das mit der Ergänzung im custom_script funktioniert wunderbar.
Aber kann es sein, dass der thttpd-Server mit der Zeitaktualisierung nicht richtig klarkommt? Weil wenn ich den W500V starte, kommt ja das "Anfangsdatum mit Zeit" und alles bootet hoch, mach ich dann aber manuell zur Aktualisierung das date-Script oder im WebInterface NTP aus und wieder an, fängt der thttpd-Server an, ständig irgendwelche Meldungen an den syslogd zu schicken. Bis zur Aktualisierung kommt immer dieses "spawned cgi...", wenn man auf dem WebInterface "rumklickt", aber danach erscheinen verschiedene Statusmeldungen und "bombardieren" das Logfile sekündlich (wenn man auf dem WebInterface rumklickt) zu. Das komische ist, sobald man dann den thttpd killt, wird er automatisch neugestartet und zeigt dann wieder wie vorher diese "spawned cgi..." Meldung. Kann man das auch anders irgendwie umgehen und warum passiert das?? (Hab mal ein Logfile zur Verdeutlichung angefügt).

2008-11-05 18:15:28	Daemon.Info	192.168.2.250	Jan  1 00:01:36 thttpd[730]: spawned CGI process 738 for file 'cgi-bin/index.cgi'
2008-11-05 18:15:32	Daemon.Info	192.168.2.250	Jan  1 00:01:40 thttpd[730]: spawned CGI process 866 for file 'cgi-bin/svg_bar.cgi'
2008-11-05 18:15:32	Daemon.Info	192.168.2.250	Jan  1 00:01:40 thttpd[730]: spawned CGI process 868 for file 'cgi-bin/svg_bar.cgi'
2008-11-05 18:15:32	Daemon.Info	192.168.2.250	Jan  1 00:01:40 thttpd[730]: spawned CGI process 870 for file 'cgi-bin/svg_bar.cgi'
2008-11-05 18:15:32	Daemon.Info	192.168.2.250	Jan  1 00:01:40 thttpd[730]: spawned CGI process 872 for file 'cgi-bin/svg_bar.cgi'
2008-11-05 18:15:32	Daemon.Info	192.168.2.250	Jan  1 00:01:40 thttpd[730]: spawned CGI process 874 for file 'cgi-bin/svg_bar.cgi'
2008-11-05 18:15:32	Daemon.Info	192.168.2.250	Jan  1 00:01:40 thttpd[730]: spawned CGI process 879 for file 'cgi-bin/svg_bar.cgi'
2008-11-05 18:15:33	Daemon.Info	192.168.2.250	Jan  1 00:01:41 thttpd[730]: spawned CGI process 908 for file 'cgi-bin/index.cgi'
2008-11-05 18:15:37	Daemon.Info	192.168.2.250	Jan  1 00:01:45 thttpd[730]: spawned CGI process 1036 for file 'cgi-bin/svg_bar.cgi'
2008-11-05 18:15:37	Daemon.Info	192.168.2.250	Jan  1 00:01:45 thttpd[730]: spawned CGI process 1038 for file 'cgi-bin/svg_bar.cgi'
2008-11-05 18:15:37	Daemon.Info	192.168.2.250	Jan  1 00:01:45 thttpd[730]: spawned CGI process 1040 for file 'cgi-bin/svg_bar.cgi'
2008-11-05 18:15:37	Daemon.Info	192.168.2.250	Jan  1 00:01:45 thttpd[730]: spawned CGI process 1042 for file 'cgi-bin/svg_bar.cgi'
2008-11-05 18:15:37	Daemon.Info	192.168.2.250	Jan  1 00:01:45 thttpd[730]: spawned CGI process 1047 for file 'cgi-bin/svg_bar.cgi'
2008-11-05 18:15:38	Daemon.Info	192.168.2.250	Jan  1 00:01:47 thttpd[730]: spawned CGI process 1071 for file 'cgi-bin/svg_bar.cgi'
2008-11-05 18:15:41	Daemon.Info	192.168.2.250	Jan  1 00:01:49 thttpd[730]: spawned CGI process 1078 for file 'cgi-bin/admin_index.cgi'
2008-11-05 18:15:44	Daemon.Info	192.168.2.250	Jan  1 00:01:52 thttpd[730]: spawned CGI process 1088 for file 'cgi-bin/date_time.cgi'
2008-11-05 18:15:48	Daemon.Info	192.168.2.250	Jan  1 00:01:56 thttpd[730]: spawned CGI process 1102 for file 'cgi-bin/date_time.cgi'
2008-11-05 18:15:56	Daemon.Info	192.168.2.250	Jan  1 00:02:04 thttpd[730]: spawned CGI process 1156 for file 'cgi-bin/date_time.cgi'

----- Zeitaktualisierung

2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]: up 279224117 seconds, stats for 279224117 seconds:
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   thttpd - 25 connections (8.95338e-08/sec), 6 max simultaneous, 450000 bytes (0.00161161/sec), 7 httpd_conns allocated
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   libhttpd - 99 strings allocated, 23400 bytes (236.364 bytes/str)
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   map cache - 0 allocated, 0 active (0 bytes), 0 free; hash size: 0; expire age: 750
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   fdwatch - 85 polls (3.04415e-07/sec)
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   timers - 12 allocated, 5 active, 7 free
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]: up 279224117 seconds, stats for 1 seconds:
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   thttpd - 0 connections (0/sec), 0 max simultaneous, 0 bytes (0/sec), 7 httpd_conns allocated
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   libhttpd - 99 strings allocated, 23400 bytes (236.364 bytes/str)
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   map cache - 0 allocated, 0 active (0 bytes), 0 free; hash size: 0; expire age: 750
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   fdwatch - 0 polls (0/sec)
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   timers - 12 allocated, 4 active, 8 free
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]: up 279224117 seconds, stats for 1 seconds:
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   thttpd - 0 connections (0/sec), 0 max simultaneous, 0 bytes (0/sec), 7 httpd_conns allocated
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   libhttpd - 99 strings allocated, 23400 bytes (236.364 bytes/str)
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   map cache - 0 allocated, 0 active (0 bytes), 0 free; hash size: 0; expire age: 750
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   fdwatch - 1 polls (1/sec)
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   timers - 12 allocated, 3 active, 9 free
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]: up 279224117 seconds, stats for 1 seconds:
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   thttpd - 0 connections (0/sec), 0 max simultaneous, 0 bytes (0/sec), 7 httpd_conns allocated
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   libhttpd - 99 strings allocated, 23400 bytes (236.364 bytes/str)
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   map cache - 0 allocated, 0 active (0 bytes), 0 free; hash size: 0; expire age: 750
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   fdwatch - 0 polls (0/sec)
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   timers - 12 allocated, 3 active, 9 free
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]: up 279224117 seconds, stats for 1 seconds:
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   thttpd - 0 connections (0/sec), 0 max simultaneous, 0 bytes (0/sec), 7 httpd_conns allocated
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   libhttpd - 99 strings allocated, 23400 bytes (236.364 bytes/str)
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   map cache - 0 allocated, 0 active (0 bytes), 0 free; hash size: 0; expire age: 937
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   fdwatch - 0 polls (0/sec)
2008-11-05 18:16:02	Daemon.Info	192.168.2.250	Nov  5 18:16:05 thttpd[730]:   timers - 3 allocated, 3 active, 0 free

 

[IP-Meister]

Hmm komisches Logfile, aber da lässt sich wohl leider nix dran ändern. Also ein paar Erklärungen:

1. Der thttpd wird nicht direkt gerufen sondern durch das Skript http.sh. Wenn du da rein schaust, wirst du sehen das dort der thttpd in einer blockierenden Schleife gestartet wird. D.h. wenn du ihn killst, wird er durch das Skript, welches im Hintergrund läuft, wieder neu gestartet.
Das war nötig, weil es recht oft vorkam das der thttpd aus unerfindlichen Gründen terminierte und so das Webinterface nicht mehr erreichbar war.
Willst du ihn wirklich beenden, dann:

killall -9 http.sh
killall -9 thttpd

2. Das Logging des thttpd ist zwar durch die Option '-l /dev/null' eigentlich deaktiviert, aber laut man page:

But note that error messages still go to syslog.

Wirst du also mit leben müssen.

 

[Duplomonster]

@IP-Meister
Aha, danke für die ausführliche Erläuterung. Dass der thttpd-Server abstürzt, war wohl auch scheinbar der Grund dafür, dass dieses erweiterte WebInterface bei den älteren Versionen öfter nach einer gewissen Zeit nicht mehr erreichbar war. Hatte mich schon gewundert...
Hmmm, ist ja blöd, weil das Logfile dann ja ständig zugemüllt ist, sofern der thttpd nicht selber mal abstürzt... Beim Einsatz als DSL-Router bootet der W500V ja erst komplett inklusive thttpd hoch und die DSL-Verbindung steht ja erst später, so dass das ja immer so ist. Wäre es denn möglich, in das Script zum Uhrzeit-aktualisieren am Ende nach der Aktualisierung einen kill für den thttpd einzufügen bzw. evtl. eine Option dort einzufügen, die das macht, sofern im NVRAM eine Variable gesetzt wird?
(Ist es denn eigentlich schädlich, wenn das syslogd ständig in den shared mem buffer schreibt, welches sich ja im Flash befindet? Dachte mal gelesen zu haben, dass der Flash auch nur eine bestimmt Anzahl von Schreibzugriffen erlaubt. Und wenn der syslogd da ständig nur "Blödsinn" reinschreibt, täte das ja auch nicht so gut auf die Dauer.)

 

[IP-Meister]

Den thttpd zu killen ist nicht immer so die gute Idee. Beispielsweise beim Speichern von bestimmten Sachen im Webinterface würdest du die Ausführung der cgi-Skripte abbrechen. Möglicherweise werden dann Werte nicht gespeichert.
Das Logging in den shared memory hat mit dem Flash nix zu tun. Der Log-Buffer ist natürlich im RAM des Routers,das würde sonst gar nicht gehen weil der Flash viel zu langsam ist.
Wenn dich das Logging stört kannst den thttpd doch per custom-Skript nochmal beenden und dann das Skript neu starten.

 

[Duplomonster]

Achso.
Das Problem mit dem custom_script ist aber, dass das längst beendet ist, bevor der Router ne DSL-Verbindung aufgebaut hat. Und erst wenn die DSL-Verbindung steht, kommt ja der NTP zum Einsatz (Hatte das auch schon spaßhalber ausprobiert, hatte aber nix gebracht). Deswegen ja auch die Idee, dass in dem NTP-Script zu integrieren.
Das mit dem Abbrechen der Scripte ist natürlich nicht ohne, deswegen war ja auch die Idee von mir, dass per NVRAM-Variable für diejenigen zu ermöglichen, die das log "nicht zugemüllt" haben wollen und das killen nur dann ausgeführt wird, wenn bspw. die Variable "ntp-thttpd-kill" oder so ähnlich auf 1 gesetzt wird. Wobei mir gerade auffällt, dass das in ungünstigen Fällen (wenn die Zeit automatisch aktualisiert wird und man gerade im WebInterface was speichert) wirklich problematisch ist, wenn ihr ja den NTP wegen der Aktualisierung im WLAN-Client-Modus öfter aktualisieren lassen wollt. Ist es denn möglich, dass man das Datum (ohne Uhrzeit) vor der Aktualisierung mit dem danach vergleicht und nur bei Differenz ggf. den thttpd killen lässt, was ja dann eigentlich immer nur im Falle des Reboots des Routers auftreten sollte (da ja bei späterer NTP-Aktualisierung eigentlich nur die Uhrzeit, aber nicht mehr das Datum differieren sollten - das Log-Problem tritt nur auf, wenn der Monat und das Jahr abweicht, soweit ich das ausprobiert hab)?
(Da es wahrscheinlich eh nicht so viele Leute brauchen, würde ich mir ja auch ein eigenes Image kompilieren, nur hab ich leider nicht so die Ahnung vom Kompilieren, bin noch open-source-Anfänger und mein Studium lässt mir momentan auch nicht so die Zeit, mich intensiv damit zu beschäftigen, deswegen wäre es schön, wenn ihr es auf Basis per NVRAM-Variable einbauen könntet und auch mit dem Datumsvergleich, wenn das möglich ist, aber wenn nicht, ist auch nicht so schlimm, werde es wohl überleben -> mangelndes Fachwissen ist manchmal echt furchtbar... )

 

[IP-Meister]

@Duplomonster
Das Problem mit dem Logging hat sich übrigens geklärt.

Siehe dazu folgendes Forum: http://sourceforge.net/forum/forum.php?thread_id=2527418&forum_id=799261

und folgendes Zitat aus diesem:

Das war wirklich mal ein guter Hinweis und ich konnte das Problem auch bei mir nachvollziehen.
Nach Überprüfung der thttpd-Sourcen hab ich auch ein Flag gefunden was das ganze ausschaltet.
Mit dem nächsten Release werden sowohl die Timer-Meldungen als auch die hohe CPU-Last
durch das sekündliche Stats-Logging behoben sein.

Danke nochmal an alle die sich damit beschäftigt haben!

 

[woprr]

Es wurde mehrfach berichtet, das der Router bei aktivierter Zwangstrennung manchmal nicht richtig reconnected.

Kann ich bestätigen. und der SIP client geht weder an sip.qsc.de noch direkt an meinem CallWeaver registriert auch nicht mit nur alaw/ulaw.
Gibt critical responses/requests die RTP-brücke wird nicht aufgebaut.
Wie ertragt Ihr alle bloss diese Kaufboxen? Meine Kleine macht mich alle wenn das nicht bald geht! :keule:
In der gleichen Zeit hätt ich ihr auf ihrem alten PII nen SIP-Server mit allem Luxus inklusive T.38 Fax aufgesetzt.
Ich probier noch die Targa version von BS wenns dann auch versagt dann fliegt das verdammte Ding zurück in die E-Schrottbucht wos herkam.

 

[Mirokoo]

Neues Problemchen

Hallo

am Samstag kam die Rechnung von der Telekom. Was mich verwundert ist die Tatsache, dass die Gespräche die über VoIP geführt wurden, und schon auf der Rechnung des VoIP Anbieters aufgelistet sind, bei der Telekom Rechnung noch mal auftauchen.

Habe den Targa W500V mit der Firmware 0.3.2 TARGA.

Kann es sein, dass 2 Gesprächsleitungen gleichzeitig geöffnet werden?? Oder wie kann es sein das diese Gespräche auf beiden Rechnungen auftauchen?? Während des Gesprächs leuchtete immer die Grüne LED für Internet, die Gelbe für Festnetz war immer aus.


Gruss

Mirokoo

PS: Gut das ich kein Vieltelefonierer bin somit fallen die 13,00¤ nicht so ins Gewicht.

 

[Novize]

Da musst Du ein paar Positionen durcheinander gewürfelt haben:
Wenn das Gespräch per VoIP (=per Internet!) raus ging, dann kann die Telekom davon gar nichts wissen, denn die Verbindung ging an denen vorbei nach draußen. Ergo kann ein solches Gespräch auch nicht auf deren Rechnung gestanden haben.

 

[Mirokoo]

Ja genau so hab ich das auch gedacht, aber leider steht es. Aufgefallen ist es mir nur dadurch, das auf der Telekom-Rechnung gespräche ins Ausland berechnet wurden. Die Auslandsgespräche werden aber von mir über VoIP gefürt.

192 Minuten auf der Rechnung von Voipdiscount und 192 Minuten auf der Telekom-Rechnung.

Das erscheint mir doch sehr merkwürdig. Ist es überhaupt möglich den Router so falsch einzustellen das er zwei Leitungen wehrend des Gesprächs offen hält??

Gruss

 

[Duplomonster]

Will dem IP-Meister ja nicht vorgreifen, aber:
Danke für das neue Release (0.3.3). Mein Abend ist gerettet

:groesste:

 

[wazzup]

Also rein technisch gesehen ist es nicht möglich 2 verbindungen gleichzeitig mit einem partner zu führen. du würdest dann besetzt erhalten oder müsstest expizit ne konferenz schalten...
vielleicht ne art rufumleitung von voip zur festnetznummer und von da aus dann weiter?
Wäre aber schon ein ziemlich harter bug.