Pascom Client 76.R1942 keine Anmeldung mehr möglich

Das kann ich ebenfalls nicht. Das ist ja der Grund für den HAProxy, es müssen meher Server/Dienste unter 443 erreicht werden.

Ich habe gerade mal testweise die Version “75.R1785” installiert. Gleiche Meldung

In der Portübersicht für die Firewalls ist aber auch nicht ersichtlich, dass es da Änderungen gab. in den Release Notes zu der Version stand auch nichts in der Liste der Änerungen.

Ich habe die 75.R1785 mal auf der Konsole gestartet. Da erhalte ich:

[2021-09-10 12:15:35.668] [T12917] [Warning] [service.store] SQL Query failed. Code: ""  Message: "Die Anzahl der Parameter ist falsch"
[2021-09-10 12:15:35.668] [T12917] [Warning] [default] QSqlDatabasePrivate::removeDatabase: connection 'qt_sql_default_connection' is still in use, all queries will cease to work.
[2021-09-10 12:15:36.160] [T12955] [Warning] [default] QSqlDatabasePrivate::removeDatabase: connection 'qt_sql_default_connection' is still in use, all queries will cease to work.
[2021-09-10 12:15:36.996] [T12917] [Warning] [service.XmppConnectionTransportCompat19] "XmppStreamError"
[2021-09-10 12:15:36.998] [T12917] [Warning] [proto.xmpp] "Authentication failure"

Noch ein Nachtrag. Am HAProxy kann es ja fast nicht liegen. Ich habe Anfang der Woche im Büro auch versucht den Desktop-Client direkt an den lokalen Hostnamen:

pbx01.intern.local anstatt pbx01.externedomain.de

im LAN anzubinden und da verhielt es sich gleich. Und da war ja keine Firewall im Spiel.

Bei mir Bringen auch manche Desktop - Client, die nicht über den RP gehen, hin und wieder eine solche Meldung. Diese bekommt man dann allerdings (teils nur temporär) mit zurücksetzen des Client wieder zum laufen. Andere wiederum müssen den Client seit Update auf 76 jeden morgen einmal zurücksetzen.

Ich habe diese Probleme auch seit ein paar Wochen. Clients können sich nicht mehr anmelden: “Anmeldung fehlgeschlagen”

Mal kommt die Meldung, dass die Anmeldedaten sich geändert haben und man diese zurücksetzen solle. Das klappt aber auch nicht.

Beim 3. bis 10. Versuch klappt es dann sporadisch mit dem Anmelden.

Die Firewall ist nach Doku eingestellt und es wurde nichts verändert.
Es trifft auch nur auf einige wenige Clients im Netzwerk zu.

Was kann ich beitragen, dass wir zu einer Lösung kommen?

Ein Kunde meldete mir heute, dass mit V77 die Meldung “Anmeldung fehlgeschlagen” kommt. Ich konnte mir das jedoch noch nicht näher ansehen.

Hallo zusammen,

v78 bringt nochmal einige Anpassungen im Zusammenspiel mit der Anmeldung und Proxies. Testet das nochmal bitte.

Grüße,
Jan

Einige unserer Clients am Terminal Server v78 (mit --rdp parameter), als auch manche Softphones auf den lokalen PCs haben immer noch Verbindungsprobleme und man muss morgens beim anmelden 1x auf zurücksetzen klicken und sich neu anmelden.

Das lässt sich aber nicht mit jedem Benutzer reproduzieren.

Diese internen Clients verbinden sich nicht über einen Reverseproxy, sondern gehen direkt auf das interne Interface der Pascom.

Die Mobilclients (Android, iOS), welche auf das externe Interface mit Reverseproxy gehen, machen keine Probleme mehr. Allerdings haben hier auch noch einige kein Update auf eine Version über 75 bekommen.

@dst Wäre es möglich mir Logs von einem betroffenen Client via PN zukommen zu lassen, dann können wir uns das genauer anschauen?
Am besten dazu bitte den Client schon mit dem Parameter
--debugMode starten und dann nach dem Zurücksetzen und Anmelden die Support-Info speichern und mir schicken.

Hallo @jurica.bacurin,

ich habe soeben einen Client mit dem Debugging Parameter gestartet, dem Pascom Server wurden aber keine Logs zugeschickt. (Client: v78, Server v19.18)

Vermutlich werden die Logs erst nach erfolgreichem Login an den Server übermittelt. Vorher beim Zurücksetzen aber verworfen…?

Die Logs bekommst du ja auch direkt im Client: Einstellungen → relativ weit unten auf Erweiterte Einstellungen anzeigen → Supportinfo speichern

Ich habe @jurica.bacurin grade die Logs eines Clients geschickt und bin gespannt.

Momentan ist weniger das Problem, dass die Meldung “Anmeldung fehlgeschlagen” kommt. Es kommt nun vermehrt die Meldung, dass die Anmeldedaten sich geändert haben sollen und man zurücksetzen muss. Da viel mit URL-Aktionen gearbeitet wird ist es nervig, da alles neu eingespeichert werden muss (Feature request: Aktionen Serverseitig speichern! :wink: )

Hallo @deto,

über den Weg hatte ich schon mal versucht im Thema Absturz der Remotesteuerung, Logs zu sammeln. (hatte die auch per PN an @jlorenz versendet). Allerdings war in den Logs kein Hinweis auf dieses und das Verhalten des Absturz bei Copy - Paste Aktionen zu finden.

Der Genaue Wortlaut bei uns in der Meldung lautet:

Anmeldung fehlgeschlagen

Ihre Zugangsdaten haben sich anscheinend geändert. Bitte geben Sie sie erneut ein oder setzen Sie diesen Client zurück und melden Sie sich erneut an.

Passwort für “Benutzer” auf “Server URL”

Wenn hier das richtige Passwort eingegeben wird, kann der Client sich nicht mehr verbinden.
Erst mit zurücksetzen und Neuanmeldung funktioniert es.

Ich vermute also, die gleiche Meldung, wie bei Dir.

Gruß
dst

Ich habe mal die Standard Log ausgaben diverser Clients verglichen.

Vorab: wir haben ein gültiges, gekauftes Zertifikat in unserer Anlage, inklusive Intermediate. Domain Namen usw. passen definitiv.

Logauszug aus Client, der keine Probleme bereitet (einmalige Zertifikatswarnung):

[2021-10-01 7:12:31.054] [T9076] [Debug] [account] New store state: data::Account::StoreCreating
[2021-10-01 7:12:31.070] [T9076] [Debug] [service.StoreService] Check versions, clientVersion: 78.1.1965 , dbVersion: 78.1.1965
[2021-10-01 7:12:31.070] [T9076] [Debug] [account] New store state: data::Account::StoreMigrating
[2021-10-01 7:12:31.070] [T9076] [Debug] [service.StoreService] MigrationManager finished migration database with result: pc::migration::MigrationManager::AlreadyMigrated resync: false
[2021-10-01 7:13:01.369] [T9076] [Warning] [service.IqDispatcher] “Failed to send command: iqId: cmd: location::Find”
[2021-10-01 7:13:09.190] [T9076] [Warning] [proto.xmpp] “SSL errors”
[2021-10-01 7:13:09.190] [T9076] [Warning] [proto.xmpp] “The host name did not match any of the valid hosts for this certificate”
[2021-10-01 7:13:09.842] [T9076] [Warning] [service.MdSoftphone] Network Environment. TLS: true IPv6: false SRTP: true NAT64: false
[2021-10-01 7:13:13.296] [T9076] [Warning] [controller.ToastController] Warning “Mikrofon (Jabra PRO 935) als Mikrofon und Lautsprecher (Jabra PRO 935) als Lautsprecher verwenden”
[2021-10-01 9:32:40.617] [T9076] [Critical] [util.MdCall] Exception on get call state: “INVITE session already terminated (PJSIP_ESESSIONTERMINATED)”
[2021-10-01 9:32:40.618] [T9076] [Critical] [util.MdCall] Exception on get call state: “INVITE session already terminated (PJSIP_ESESSIONTERMINATED)”

Logauszug aus Client, der Probleme bereitet (mehrfache Zertifikatswarnung und SQL Query error):

[2021-10-01 8:44:10.287] [T52120] [Debug] [account] New store state: data::Account::StoreCreating
[2021-10-01 8:44:10.294] [T52120] [Debug] [service.StoreService] Check versions, clientVersion: 78.1.1965 , dbVersion: 78.1.1965
[2021-10-01 8:44:10.295] [T52120] [Debug] [account] New store state: data::Account::StoreMigrating
[2021-10-01 8:44:10.295] [T52120] [Debug] [service.StoreService] MigrationManager finished migration database with result: pc::migration::MigrationManager::AlreadyMigrated resync: false
[2021-10-01 8:44:11.710] [T52120] [Warning] [service.IqDispatcher] “Failed to send command: iqId: cmd: location::Find”
[2021-10-01 8:44:13.909] [T52120] [Warning] [proto.xmpp] “SSL errors”
[2021-10-01 8:44:13.910] [T52120] [Warning] [proto.xmpp] “The host name did not match any of the valid hosts for this certificate”
[2021-10-01 8:44:14.063] [T52120] [Warning] [service.XmppConnectionTransportCompat19] Xmpp error: “XmppStreamError”
[2021-10-01 8:44:14.101] [T52120] [Warning] [proto.xmpp] “Authentication failure”
[2021-10-01 8:44:24.649] [T52120] [Warning] [proto.xmpp] “SSL errors”
[2021-10-01 8:44:24.650] [T52120] [Warning] [proto.xmpp] “The host name did not match any of the valid hosts for this certificate”
[2021-10-01 8:44:24.687] [T52120] [Warning] [service.XmppConnectionTransportCompat19] Xmpp error: “XmppStreamError”
[2021-10-01 8:44:24.688] [T52120] [Warning] [proto.xmpp] “Authentication failure”
[2021-10-01 8:44:26.242] [T52120] [Warning] [proto.xmpp] “SSL errors”
[2021-10-01 8:44:26.243] [T52120] [Warning] [proto.xmpp] “The host name did not match any of the valid hosts for this certificate”
[2021-10-01 8:44:26.268] [T52120] [Warning] [service.XmppConnectionTransportCompat19] Xmpp error: “XmppStreamError”
[2021-10-01 8:44:26.269] [T52120] [Warning] [proto.xmpp] “Authentication failure”
[2021-10-01 8:44:33.450] [T52120] [Warning] [proto.xmpp] “SSL errors”
[2021-10-01 8:44:33.451] [T52120] [Warning] [proto.xmpp] “The host name did not match any of the valid hosts for this certificate”
[2021-10-01 8:44:33.492] [T52120] [Warning] [service.XmppConnectionTransportCompat19] Xmpp error: “XmppStreamError”
[2021-10-01 8:44:33.493] [T52120] [Warning] [proto.xmpp] “Authentication failure”
[2021-10-01 8:44:33.697] [T52120] [Warning] [service.store] SQL Query failed. Code: “” Message: “Parameter count mismatch”
[2021-10-01 8:44:33.698] [T52120] [Warning] [service.store] SQL Query failed. Code: “” Message: “Parameter count mismatch”
[2021-10-01 8:44:33.699] [T52120] [Critical] [service.SettingsStore] Can’t query value for key “client~version” , error: “Parameter count mismatch”
[2021-10-01 8:44:41.982] [T52120] [Warning] [proto.xmpp] “SSL errors”
[2021-10-01 8:44:41.983] [T52120] [Warning] [proto.xmpp] “The host name did not match any of the valid hosts for this certificate”
[2021-10-01 8:44:47.319] [T52120] [Warning] [service.MdSoftphone] Network Environment. TLS: true IPv6: false SRTP: true NAT64: false
[2021-10-01 8:44:55.783] [T52120] [Warning] [controller.updateController] Auto update can’t be changed when appDir is readonly, or when it’s diabled via flag!
[2021-10-01 8:45:01.453] [T52120] [Warning] [controller.ToastController] Warning “Wave mapper als Mikrofon und Wave mapper als Lautsprecher verwenden”

@deto: Vielen Dank für die Logs, ich werde diese anschauen und melde mich dann wieder.

@dst: Da das Debuglog vom Client sehr ausführlich ist und Meldungen aller Subsysteme enthält, sind die von dir geposteten Logauszüge leider etwas aus dem Kontext gerissen und helfen so nicht zur Fehleranalyse. Wenn du einfach nach dem Zurücksetzen die Support-Info speicherst und mir zusendest, sind die Logs auch von dorm Zurücksetzen enthalten. Zwar beschreiben du und @deto das gleiche Problem, falls möglich schicke mir trotzdem noch deine Support-Info, dann können wir checken ob es wirklich die gleiche Ursache ist.

@deto & @dst: Vielen Dank für die Unterstützung bei der Fehlersuche.
Das Problem ist, dass der Client den per --user Parameter oder PC_USER Umgebungsvariable angegebenen Usernamen genau wie angegeben (Groß-Klein-Schreibung) an den Server sendet. Der Server erwartet allerdings Usernamen ausschliesslich mit Kleinbuchstaben.
Wir werden hierfür in einer kommenden Client Version einen Fix einbauen.
So lange müsste sichergestellt werden, dass Usernamen in Kleinbuchstaben per --user bzw. PC_USER angegeben werden.

@jurica.bacurin
Vielen Dank für die Info! Ich habe mir grade die Umgebungsvariablen angeschaut und muss sagen, dass diese immer kleingeschrieben sind.
Ich baue den PC_USER aus %username%@instanz zusammen. sowohl %username% als auch der komplette PC_USER ist laut Windows-Ausgabe kleingeschrieben. Auch im AD ist der Benutzer kleingeschrieben. Aber ja, in Pascom ist der Benutzer dann plötzlich großgeschrieben

@jurica.bacurin
Der Kunde gleicht per AD Connector die Benutzer ab. Alle Benutzer sind kleingeschrieben abgelegt, kommen auch kleingeschrieben in Pascom an. Was auffällt: Wenn der Fehler im Client kommt, wird der Benutzer großgeschrieben, sobald man auf “zurücksetzen” klickt, wird er wieder kleingeschrieben dargestellt.

@deto Danke für die Info, das hört sich schlüssig an, da der Auslöser des Problems der Username im Client mit Großbuchstaben ist.
Der kann allerdings nur über besagten CLI Parameter oder Umgebungsvariable “in den Client kommen”.
Wir werden hier Clientseitig in Zukunft sicherstellen, dass Usernamen nur aus Kleinbuchstaben an den Server gesendet werden, dann ist es egal wenn über CLI-/Umgebungsvariable doch Großbuchstaben an den Client übergeben werden.
Bis diese Änderung allerdings released ist, hilft es leider nur in den Scripten sicherzustellen, dass der Username in Kleinbuchstaben konvertiert wird, oder Zwischenzeitlich den Usernamen aus den Scripten zu entfernen.