Autoprovisioning Gigaset de900 ip

  • Hallo,


    ich würde gern ein gigaset de900 ip per Autoprivisioning an meiner Starface 5.0.0.14 betreiben. Das Gerät wird bei der Suche auch gefunden. Leider werden keinerlei Einträge im Telefon durch die Starface vorgenommen, sodass ich das Gerät nur manuell an die Anlage anmelden kann. Leider ist ein Programmieren der Tasten über die Starface so nicht möglich.


    Habt ihr eine Lösung?


    Sebastian

  • Hallo Stefan,


    ich habe das Gigaset mit der Firmware aus deinem Link geupdatet. Die Starface findet das Telefon, trägt aber leider immer noch keine Werte in das Telefon ein.


    LG


    Sebastian

  • Hast du schonmal versucht, das Telefon zurückzusetzen?


    Ansonsten versuche mal, in der Telefon-Weboberfläche unter Einstellungen > System > Firmware > "Daten Server" die folgende URL einzutragen:
    <starfaceIP>:50080/ap/gc , also beispielsweise 192.168.0.1:50080/ap/gc

    Grüße
    Stefan

  • Hallo Stefan,


    habe das Telefon bereits zurückgesetzt, und der Eintrag beim Datenserver scheint auch automatisch eingetragen zu werden, der Rest leider nicht.


    Gruß


    Sebastian

  • Den Gedanke hatte ich auch gerade, es ist eigentlich unmöglich das das nicht klappt. Ich habe auch ein 900 IP im Einsatz und die Konfiguration war völlig problemlos

  • Die Autoprovisionierung ist aktiv und funktioniert bei den sonst verwendeten snom 370 und 870 sowie linksys pap2 problemlos.

  • Zitat

    und der Eintrag beim Datenserver scheint auch automatisch eingetragen zu werden, der Rest leider nicht.


    Noch ne blöde Frage: Der Reset des Endgeräts hat aber geklappt? Die FW 01.01.10 ist installiert?

    Gruß / Regards
    Philipp

  • Habe gerade nochmals die Firmware auf 01.01.10 aktualisiert. Leider wird das Telefon nicht autoprov. wenn ich die manuelle suche starte, wird es gefunden aber auch hierbei wird kein ip account eingerichtet. wenn ich den account manuell einrichte kann ich telefonieren aber keine tasten auf das gerät senden.

  • Du hast nicht irgendwelche Passwörter auf dem Telefon geändert bevor Du startest? Kommt denn überhaupt was auf dem Telefon an oder bleibt es völlig jungfräulich?


    NJ

  • Nichts geändert völlig jungfräuliches telefon. einzige von mir feststellbare änderung nach dem hochfahren ist das korrekte eintragen des updateservers <starfaceIP>:50080/ap/gc.


    sr

  • hmm ok, ich meine es war bei meinem Gerät so das die Starface zuerst ein Softwareupgrade angeschoben hat und nach dem Upgrade und nach Neustart die weiteren Daten eingetragen hat.


    @ Philipp


    kann das so sein?


    NJ

  • Hat wirklich keiner eine Idee wieso das Gigaste nicht funktioniert. Teilweise vollzieht es einen Neustart während des Telefonats.

  • Also ich muss passen, bei mir hat das wie gesagt innerhalb von Minuten geklappt. Es gibt also keinen Grund warum das bei Dir nicht so sein sollte, ausser das Gerät ist defekt oder es ist die falsche Firmware drauf.


    NJ

  • Ich kann das Problem mit einem jungfräulichen Gigaset DE900 IP Pro mit Firmware 01.01.10 bestätigen. Das Gigaset ruft die Autoprovisionierungs-URL http://<starface>/ap/gc/60/1/cgi/ap?mac=<mac> auf und erntet einen HTTP 500 (Internal Server Error).


    Im Log findet sich folgender Fehler:
    ERROR org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/].[hawkingAutoProvisioningServlet] Servlet.service() for servlet hawkingAutoProvisioningServlet threw exception
    javax.servlet.ServletException: No work directory created
    at de.vertico.starface.phonesetup.autoprov.gigaset.GigasetAutoprovServletAbstract.doGet(GigasetAutoprovServletAbstract.java:164)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:627)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
    at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:843)
    at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:679)
    at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1303)
    at java.lang.Thread.run(Thread.java:662)


    Diese Exception stammt, wie die Fehlermeldung ja andeutet, aus GigasetAutoprovServletAbstract, Zeile 164. Dort wird geprüft, ob ein Arbeitsverzeichnis existiert, falls nicht, wird diese Exception geworfen. Das Arbeitsverzeichnis sollte /tmp/starface/autoprov/<gigaset-typ> sein, wobei <gigaset-typ> für das DE900 IP pro "hawking" lautet.


    Nachtrag: In der GigasetAutoprovServletAbstract wird das Arbeitsverzeichnis während der Servlet-Initiierung erstellt und erst gelöscht, wenn die Java VM terminiert. Bei den Anschließenden Anfragen an das Servlet wird in der doGet() nur noch überprüft, ob das Arbeitsverzeichnis existiert und im Fehlerfall die obige Exception geworfen.
    Wenn also das Arbeitsverzeichnis verschwindet, nachdem das Servlet initiiert wurde, klappt die Autoprovisionierung nicht mehr.


    ABHILFE: ... schafft in diesem Fall ein Neustart des Tomcat oder der Appliance -- und siehe da, die Provisionierung funktioniert (zumindest hier bei mir) wieder.



    Frage: Wie kann das Arbeitsverzeichnis verschwinden?


  • ABHILFE: ... schafft in diesem Fall ein Neustart des Tomcat oder der Appliance -- und siehe da, die Provisionierung funktioniert (zumindest hier bei mir) wieder.


    Frage: Wie kann das Arbeitsverzeichnis verschwinden?


    Du hast mit dem Diensteneustart schon die korrekte Abhilfe gefunden :) - wir suchen momentan noch die Ursache.

    Grüße
    Stefan

  • Ich würde den cronjob daily_clean_tmps verdächtigen (/etc/periodic/daily/110.clean-tmps). Müßte es aber noch testen... Speziell, nachdem die 5er STARFACE nicht mehr einen nächtlichen Neustart macht, bei dem das Problem sich automatisch behebt :)


    Nachtrag: Mist.... jetzt war ich in der falschen Konsole, auf nem anderen Rechner -- und nicht auf der Starface. Bei der Starface gibt es etwas ähnliches unter /etc/cron.daily/tmpwatch:



    Die erste Zeile löscht alles unterhalb von /tmp, auf das nicht innerhalb der letzten 240h (10 Tage) zugegriffen wurde -- mit Ausnahme der mit -x angegebenen Verzeichnisse. Eventuell sollte man da das /tmp/starface-Verzeichnis hinzufügen oder alternativ das Servlet dazu veranlassen, bei Nichtvorhandensein des Arbeitsverzeichnisses, dieses zu erstellen, anstatt eine Exception zu werfen.

  • Nachtrag zu Skoenig vom 23.03.12: Wir haben die Ursache bereits seit längerem als mögliche Fehlerquelle auf dem Radar gehabt, konnten das Thema jedoch intern nicht nachstellen. Der komplette Mechanismus der Gigaset Provisionierung ändert sich mit STARFACE 5.1 und wird dadurch extrem robust. Desweiteren wird dann auch die Gigaset N720 Multizelle unterstützt, sowie die neue Firmwares des N510.


    Bis dahin: Im Fall des Falles bitte einen Diensteneustart durchführen, dadurch werden die Verzeichnisse neu initialisiert.


    Viele Grüsse

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!