Beiträge von kabbenseth

    Das Problem ist wie hardy schon geshen hat, dass der RPM-Key von AlmaLinux nicht in der 7.1 oder 7.0 hinterlegt ist.

    Anschließend habe ich den neuen KEY File für ALMALINUX geholt und installiert:


    curl -f -s -S -o RPM-GPG-KEY-AlmaLinux https://repo.almalinux.org/almalinux/RPM-GPG-KEY-AlmaLinux

    rpm --import RPM-GPG-KEY-AlmaLinux

    Das Problem tritt bei einem update ohne das "Download und Installation trennen" nicht auf, da einer der ersten schritte von dem Updateprozess ist es den RPM key zu installieren.
    Mit dem hacken gesetzt wird beim Download dieser Prozess nicht gemacht, also schlägt die Validierung der AlmaLinux Packete fehl.

    Um den RPM key im System zu hinterlegen haben wir ein Modul gebaut und Hier in der Knowledgebase dokumentiert ist.

    Zufällig haben wir heute das Problem mit den Icons reproduzieren und auch beheben können.

    Leider hat sich ein Schreibfehler in den Templates eingeschlichen eingeschlichen.


    Workaround:
    in /opt/tomcat/webapps/localhost/starface/WEB-INF/filetemplates/yealinkConfig/CP960/CP960-basic-settings.cfg
    die vorletzte Zeile das desskey.icon.url zu einem dsskey.icon.url (also das e löschen) ändern. Speichern und im Anschluss das Telefon neu provisionieren (neustarten).

    Hi,
    dein Fehler 2, dass Funktionstatsten nicht provisioniert werden, ist bekannt und ist in dem neuen Release 7.2.0.5 auch behoben. Siehe Release Notes 7.2.0.5
    "Die Funktionstasten des Yealink CP960 werden nun wieder korrekt provisioniert."


    Bezüglich 1. kann geschaut werden, ob die Bilder überhaupt herunter geladen werden können.
    dafür bitte http://<ip-der-starface>:50080/ap/downloads/yealink/icons/cp960/icons.tar
    bzw. http://<ip-der-starface>:50080/ap/downloads/yealink/logo/yealink-cp960/CP960.png
    im Browser aufrufen um zu schauen, ob das Hintergrundbild, bzw das .tar Archiv mit den icon Bildern herunter geladen werden kann.

    Hi,

    Firmware v2.29.1 (hier wurde ein recht alter Stand gewählt, um sicherzustellen, dass die Version niedriger als die der Starface ist und zu sehen auf welche Version von der Starface upgedatet wird)


    FW update vom VI wird von der STARFACE nicht unterstützt. Also kann gerne auch die aktuelle VI Version genommen werden.


    Was mir der Log Auszug zeigt:
    Der MAC filter ist aktiv.

    Der VI schickt aber eine leere MAC in seinem User-Agent.

    Deshalb wird die Provisionierungsanfrage automatisch abgelehnt.

    Ich glaube der VI benutzt die MAC der ersten verbundenen Basis.

    Mein erster Ansatz wäre, zuerst eine Bais mit dem VI zu verbinden.

    Das Problem (2 Netzwerkkarten in jeweils unterschiedlichen Subnets) ist uns bekannt und wird in der nächsten Version behoben sein.


    Und als Hinweis, Wenn man in der Starface Änderungen am Netzwerk in der Gui macht, muss man die Standard GW wieder in der Shell entfernen, da diese wieder in die Netzwerkschnittstelle eingetragen wird

    Beim speichern im "Leitungen" Tab könnte auch die Netzwerkconfig neu geschrieben werden. Da aber eventuell nur wenn NGN Leitungen involviert sind, was ja bei einer VM eher nicht der Fall ist.


    Das Recht "Module aktivieren" war nicht gesetzt, da auch nicht notwendig. Der User soll auch keine Module aktivieren. Sobald ich aber das Recht gebe, funktionieren die anderen Tasten (Gruppe, ausgehende Rufnummer).


    Ich habe gerade mal im Code geschaut,
    Ich habe keine Einschränkung der beiden genannten Funktionstasten-Typen in Bezug auf "Module aktivieren" gefunden.
    Jedoch habe ich die Einschränkung für die Benutzung im Zusammenhang mit der Berechtigung "Einstellungen" gefunden.


    Kann es sein, dass du gleichzeitig die "Einstellungen" Berechtigung gegeben hast?


    Grüße,
    Kevin


    Da die aktuelle Sicherheitslücke dort nicht funktioniert aber bereits darin enthaltenen Sicherheitslücken nicht ganz so schlimm sind? (noch)
    Die zwei Jahre alte CVE-2019-17571 hat ja "nur" einen Score 9.8 von 10 erhalten.


    ...


    Wir haben natürlich auch nach den anderen bekannten CVEs in log4j geschaut, und die STARFACE PBX ist von keiner davon betroffen.
    Die genannte CVE-2019-17571 betrifft die PBX auch nicht, da diese die SocketServer Klasse betrifft. Da auf der STARFACE PBX nur lokal geloggt wird, wird der SocketServer nicht verwendet.

    Hi,


    Generell glaube ich, dass die Ursache eher beim Telefongerät liegt, als in der Desktop App.


    Das beschriebene Verhalten kommt uns zumindest in Teilen bei Snom D Serien Telefonen bekannt vor.


    Das Problem kam im Zusammenhang mit einer Änderung im Standardverhaltens durch den Hersteller in einem Firmware Update.


    Da für das Telefon das wieder Aufnehmen des Anrufs technische ein Neuer Anruf ist, kann man es mal mit folgender Anleitung versuchen:
    https://knowledge.starface.de/…i+SNOM+funktioniert+nicht


    Sollte es kein Snom Telefon sein, bitte um genaue Beschreibung was für ein Endgerät (+ evtl. Headset) involviert ist. Und dann ggz ein Ticket beim Support mit zugehörigen Logdateien eröffnen.


    Snom hat für das 375 jetzt einen "End of Sales" bekanntgegeben, das heisst aber meines Wissens nach keine Abkündigung des Supports, oder?


    Das D385 haben wir auch gerade erst frisch in Betrieb genommen als aktuelles Modell da es uns letztes Jahr als aktuellstes Snom-Gerät angeboten wurde.


    Können wir zumindest damit rechnen, dass die Geräte weiterhin basierend auf der jetzigen Implementation dann autoprovisioniert werden? Wenns keine Updates gibt ok, muss man als Risiko im Hinterkopf behalten, aber zumindest die Grundfunktionalität, die bereits vorhanden ist, sollte ja vorhanden bleiben. Ich hoffe mal das funktioniert weiterhin so gut wie mit den alten Aastra, da ist eine Autoprovisionierung ja auch weiterhin kein Problem.


    Die Bekanntmachung von Snom bezüglich dem D375 ist schon älter (ich glaube Mitte 2018).
    Hier im Snom Wiki werden die EOS und EOL Zeitpunkte gelistet.
    Dort ist auch beschrieben, was EOL für Snom heißt.


    Über das D385 sind uns bis jetzt noch keine EOS/EOL Pläne von Snom bekannt. (Bzw. es wird sogar als Ersatz für das D375 genannt.)


    Ähnlich wie Aastra oder ältere, schon abgekündigte Geräte (z.B. Snom 360), werden die Geräte weiterhin autoprovisioniert, und die bestehende Funktionalität wird beibehalten, jedoch nicht mehr aktiv verändert, geupdated und auch nicht mehr vor einem Release getestet.

    also ziemlich sicher ein problem in der funktion ... nicht in unseren modulen


    korrekt!
    Der Fehler ist uns bekannt und wird voraussichtlich mit der nächsten Version behoben sein.


    Das Problem ist, dass mit Version 7 in den REST-Funktionen ein veralteter auth-Header gesetzt wurde (Problem 1), der leider nicht mehr ausgewertet wurde (Problem 2).


    Ein Workaround wäre den Header manuell zu setzen:
    (Jedoch nur für den "generischen" StarfaceRestRequest möglich)

    AcquireAuthToken(...) --> _authToken


    CreateMap() --> httpHeaders
    GetObjectProperty(_authToken, 'authToken') -- > authTokenValue
    Add(httpHeaders, 'authToken', authTokenValue) --> _notNeeded


    StarfaceRestRequest(..., ---, httpHeaders) --> ...

    Ja, das Thema hat bei uns eine hohe Priorität und wir arbeiten an einer Lösung.


    Wen die technischen Details interessieren:
    Aus einem TCP Dumps ist zu erkennen, dass das SN4110 die config Daten anragt (und auch bekommt), aber das Gateway die TCP Verbindung nicht korrekt beendet (Kein "Drei-Wege-Handschlag")

    Hi Patrick,


    wir konnten das Problem auch mit einem SN 4118 nachstellen und ein Bug Ticket wurde erstellt.



    Workaround:
    Da die SIP-Accounts erstellt wurden und man in den Starface Logs die provisionierungs Anfrage+Antwort sieht, kann die provisionierung theoretisch "einfach" von Hand gemacht werden.
    Im autoprov.log sollte folgender Eintrag erscheinen:


    Diesen Eintrag ab dem "#-----..." bis zum ende des log Eintrags kopieren und in einer Textdatei speichern.


    Anschließend in die WEB-Oberfläche des SN411x gehen
    "Import/Export" -> "Import Configuration"
    dort die soeben erstellte Datei auswählen und Importieren.
    Anschließend das Gateway neu starten.

    Hi,


    das Problem ist vermutlich, dass UIEFI Secure Boot für die VM aktiv ist. UEFI Secure Boot unterstützen wir aktuell nicht. (Dadurch wird das Timer-Modul nicht geladen und dies verursacht einen segfault)
    Um es auszuschalten, muss die VM heruntergefahren werden, die Einstellung geändert und dann die VM wieder hochgefahren werden.


    Grüße,
    Kevin

    Hi,


    du hast im 7.0.0.2 Beta Post, diesen Thread verlinkt, nehme ich es richtig an dass du es in der 7.0.0.2 getestet hast?
    Ich habe es mit der 7.0.0.8 nochmal nachstellen wollen.
    Mit der 7.0.0.8 wird mir der Gruppenname korrekt angezeigt. Kannst du es nach einem update auf die neuste Beta noch einmal ausprobieren?


    Grüße,
    Kevin