Posts by ermanno

    Nach einem mehrtägigen K(r)ampf ist das Yealink T46s wieder aktiv. Des Rätsels Lösung war bei mir das selbstsignierte Zertifikat auf der VM. Nachdem ich es gemäß Selbstsigniertes Zertifikat löschen? gelöscht hatte, tauchte die IP des Telefons in der Blacklist auf. Nach manuellem Whitelisting der IP und Entfernen des Zertifikats in der Weboberfläche des Yealink-Telefons gelang letztlich die Autoprovisionierung. Ein Reset auf Werkseinstellungen hätte wahrscheinlich auch gereicht, wurde remote aber immer mit der Meldung "Autop busy, please retry after autop done!" quittiert.

    Vielen Dank! Habe die Datei MigratedTomcatCertificate.crt jetzt mal in MigratedTomcatCertificate.crt.off umbenannt und die Anlage neu gestartet. Daraufhin ist das hinterlegte selbstsignierte Zertifikat aus der Anlage verschwunden. Nachdem ich auch im Yealink-Telefon über die Weboberfläche die von der Starface übermittelten Zertifikate gelöscht hatte, ist auch wieder eine Autoprovisionierung möglich.

    Ich bin auf STARFACE 8.1.1.1. Das Sectigo-Zertifikat enthält bezüglich des Inhabers nur den Hostname des Servers (cn), das selbstsignierte Zertifikat den gleichen Hostname des Servers (cn) und zusätzliche Angaben zu Organisation (O), Ort (L), Staat (ST) und Land (C). Da in der Spalte "Webserver" weiterhin das selbstsignierte Zertifikat steht, scheint es nicht überschrieben/gelöscht worden zu sein.

    Das Telefon war auf Firmware 66.86.150.2, Werksreset wurde vielfach über Menü und auch die OK-Taste versucht.

    Soeben habe ich die Starface-Autoprovisionierung deaktiviert und ein Downgrade auf die Version 66.81.0.25 vorgenommen. Nach erneuter Aktivierung der Autoprovisionierung und einem Reboot waren im Logfile wiederholte Provisionierungsanfragen zu sehen und das Telefon bootet alle paar MInuten neu, ohne jedoch die aktuelle Firmware anzunehmen. Mit der URL aus dem Logfile habe ich dann die aktuelle Firmware von der Starface heruntergeladen und über das Webinterface wieder erfolgreich auf 66.86.150.2 upgedatet.

    Leider gelingt seither keinerlei weitere Autoprovisionierung, egal ob mit oder ohne eingetragene Server-URL (http://192.168.0.10:50080/ap/yealink/legacy3/). Während vorher wenigstens noch die Anmeldeinformationen der Weboberfläche übernommen wurden, gibt sich das Telefon nun gänzlich unbeeindruckt:

    Im autoprov-Logfile wird fälschlicherweise "have already been provisioned" behauptet:

    [2023-12-23T23:30:04,644] [TRACE] [] [Autoprovisioning] Created temporary output file "/tmp/starface/autoprov/yealink/1703370604643"

    [2023-12-23T23:30:04,950] [DEBUG] [] [YealinkLegacy3AutoProvisioningServlet]

    The T46S with IP 192.168.0.136 and mac "805EC00XXXXX" requested /ap/yealink/legacy3/805EC003EE8F.cfg via http

    UserAgent: Yealink SIP-T46S 66.86.150.2 80:5e:c0:XX:XX:XX

    [2023-12-23T23:30:04,956] [WARN ] [] [YealinkLegacy3T46SAutoprovHandler] Not providing Credentials to 4517.ylnkt46s because they have already been provisioned.

    [2023-12-23T23:30:04,969] [DEBUG] [] [YealinkLegacy3AutoProvisioningServlet]

    #!version:1.0.0.1

    ##File header "#!version:1.0.0.1" can not be edited or deleted.##

    #####Specific Settings file for Yealink T46S #####

    account.1.enable = 1

    account.1.label = 4517.ylnkt46s

    account.1.display_name = 4517.ylnkt46s

    account.1.auth_name = 4517.ylnkt46s

    account.1.user_name = 4517.ylnkt46s

    features.xml_browser.user_name = 4517.ylnkt46s

    #SIP and XML-Browser password have already been provisioned.

    #Specify the web language, the valid values are: English, Chinese_S, Turkish, Portuguese, Spanish, Italian, French, Russian, Deutsch and Czech.

    lang.wui = German

    #Specify the LCD language, the valid values are: English (default), Chinese_S, Chinese_T, German, French, Turkish, Italian, Polish, Spanish and Portuguese.

    gui_lang.url = http://192.168.0.10:50080/ap/downloads/y…GUI.German.lang

    lang.gui = German

    #Serverside forwards:(Currently deactivated)

    #features.fwd_mode = 1

    #account.1.always_fwd.enable = #CFU#

    #forward.always.enable = #CFU#

    #account.1.always_fwd.target = #CFU_T#

    #forward.always.target = #CFU_T#

    features.fwd_mode = 1

    account.1.always_fwd.enable = 0

    forward.always.enable = 0

    account.1.always_fwd.target =

    forward.always.target =

    #Serverside DND:

    features.dnd_mode = 1

    features.dnd.enable = 0

    account.1.dnd.enable = 0

    features.blf_key_state_display.enable = 0


    #Configure Soft Key 1

    programablekey.1.type = 27

    programablekey.1.line = 0

    programablekey.1.value = http://192.168.0.10:50080/xmlInterface/m…P/4517.ylnkt46s

    programablekey.1.history_type = %NULL%

    programablekey.1.label = Ruflisten

    […]

    expansion_module.3.key.40.type = 0

    expansion_module.3.key.40.line = 0

    expansion_module.3.key.40.value =

    expansion_module.3.key.40.pickup_value = %NULL%

    expansion_module.3.key.40.label =


    [2023-12-23T23:30:04,971] [TRACE] [] [Autoprovisioning] Created temporary output file "/tmp/starface/autoprov/yealink/1703370604970"

    Vor einigen Monaten hatte ich eine Starface-VM ohne Zusatzmodule mit einem selbst signierten Zertifikat ausgestattet:

    pasted-from-clipboard.png

    Zwischenzeitlich habe ich über den neuen Trust-Store ein offizielles Sectigo-SSL-Zertifikat hochgeladen, das nun für problemlosen https-Zugriff auf die Weboberfläche sorgt. Da die Starface-Clients sowohl auf macOS als auch Windows verschiedene SSL-Fehler melden, vermute ich eine Unverträglichkeit mit dem immer noch bestehenden SSL-Zertifikat. Der HTTPS-Dienst ist in der Starface übrigens gar nicht aktiviert, sondern wird nur für externen Zugriff über einen Reverse Proxy ermöglicht. Eine testweise Aktivierung hatte auch zu keiner Verbesserung geführt.

    In der Weboberfläche habe ich keine Funktion zum Löschen des Zertifikats gefunden. Eine UI-Grundregel ist ja eigentlich, dass alle Ergänzungen reversibel sein sollten. Kann mir jemand einen Weg über die Shell verraten?

    Im Voraus vielen Dank!

    Vielen Dank für die Infos! An anderer Stelle schreibt Starface zu Legacy: "werden wie gehabt funktionieren, aber in Zukunft keine weiteren Updates mehr bekommen":

    support.starface.de/forum/thread/?postID=73718#post73718

    Bei allem Verständnis, dass die Liste der Supported Devices nicht unendlich wachsen kann, sollte bei einem der ehemaligen Bestseller wie dem Yealink T46S zumindest die Autoprovisionierung weiterhin funktionieren.

    Mit großem Interesse habe ich diese Anleitung verfolgt.

    Die Konvertierung der .ovf in .ova ist mir auf dem Mac mit dem VMware-Tool gelungen.

    Nach langwierigen Versuchen habe ich festgestellt, dass die in VMM importierte Starface-Version 8.1.1.1 nur startet, nachdem der virtuelle Festplattencontroller auf IDE und die Firmware auf UEFI geändert ist.