Neuaufbau einer 18.03 / Autoprovisionierung schlägt fehl

Hallo zusammen,

bin aktuell auf der Suche nach einer VOIP TK-Anlage und bei PASCOM 18.03 gefällt bis jetzt alles.

Leider scheitere ich noch an bestimmten Geräten mit der Autoprovisionierung. Folgende Geräte sollen später zum Einsatz kommen:

4x SNOM D785 - Auotoprovisionierung funktioniert Firmware: 10.1.19.0
2x Yealink W52P - Autoprovisionierung schlägt fehl Firmware: 25.01.81.30 - DECT Gateway wird gefunden kann aber kann nicht provisioniert werden. Habe in der WebGUI die URL eingetragen aber nichts funktioniert.
2x Grandstream GXP2170 - Autoprovisionierung schlägt fehl Firmware: 1.0.9.127 - Leider lässt es sich nicht provisionieren. Ebenfalls über die WebGUI URL eingetragen. Nichts funktioniert.

4x PASCOM Softphone - Funktioniert einwandfrei. Geniales Feature - Weiter SO !

Zur Zeit läuft die 18.03 als VM auf einem Server.

Was mache ich da falsch, hänge da irgendwie fest. Alle Geräte sind gezielt gewählt worden, da sie in der Kompatibilitätsliste von PASCOM auftauchen.

Danke Euch schon mal vorab.

1 Like

Hallo @blackhawk76,
tauchen die Anfragen des Gerätes in der Schnittstelle bzw. in der Instanz mit einem 200 auf? Um das zu prüfen kannst du, nachdem du dich via ssh auf den Host verbunden hast, mit “lxc-attach -n $containername” auf den jeweiligen Container wechseln und die Logs unter /var/log/apache2/provisioning-access.log (bzw. nur access.log in der Instanz) kontrollieren.
Hast du (noch) ein self signed Zertifikat? Ggf. musst du den Geräten beibringen, dass sie dieses auch akzeptieren.

Besten Gruß
Sebastian

Hallo Sebastian,
ich habe ein ganz ähnliches Problem.
Der access.log in der Instanz ist allerdings leer. das access.log.1 enthält auf den ersten blick keine Daten zum Yealink. Das Log ist aber auch riesig groß, also schwer zu sagen.

Auf dem Host selbst (ohne lxc-attach) gibt es bei mir kein prvisionign-access.log

Hallo @Warmitrax,

hast du ein Self Signed Cert und dieses auf dem Gerät schon legitimiert (Security -> Trusted Certificates)?
Ich schlage vor die siehst dich auf dem Interface um, über das die Provisionierung laufen soll.
Dazu gelangst du vom Host aus mit “lxc-attach -n ifens*” auf die Schnittstelle. Falls dort im /var/log/apache2/provisioning-access.log (oder -error.log) nichts auftaucht, kannst du mit ssldump nachsehen ob das Yealink Probleme mit dem Cert hat.
Ich nehme an du nutzt die Provisionierungs-URL und hast keinen DHCP der (zusätzlich?) noch Option 66 verteilt?

Besten Gruß
Sebastian

Ich habe Option 66 jetzt doch verteilt. (Habe vorher versehentlichd en falschen DCHP konfiguriert, dann kann das ja nx werden)

Das Yealink taucht jetzt sogar von selbst in den Gateways auf. Wird also zum teil konfiguriert.

er äändert auch das Passwort des geräts, allerdings wird die config an sich nicht übertragen und in der MD kommt oben immernoch die Meldung Provisionierung fehlgeschlagen. Das Access.log dazu:

10.0.3.1 - - [22/Mar/2019:14:39:13 +0100] “GET /provisioning/y000000000000.boot?LDAP_PROXY=secure&VOIP_MEDIA=srtp&VOIP_SIP=tls HTTP/1.1” 404 194 “-” “Yealink W52P 25.81.0.10 00:15:65:fb:52:5b”
10.0.3.1 - - [22/Mar/2019:14:39:14 +0100] “GET /provisioning/y000000000025.cfg?LDAP_PROXY=secure&VOIP_MEDIA=srtp&VOIP_SIP=tls HTTP/1.1” 200 2171 “-” “Yealink W52P 25.81.0.10 00:15:65:fb:52:5b”
10.0.3.1 - - [22/Mar/2019:14:39:25 +0100] “GET /provisioning/001565fb525b.cfg?LDAP_PROXY=secure&VOIP_MEDIA=srtp&VOIP_SIP=tls HTTP/1.1” 404 194 “-” “Yealink W52P 25.81.0.10 00:15:65:fb:52:5b”
10.0.3.1 - - [22/Mar/2019:14:39:32 +0100] “GET /provisioning/001565fb525b.boot?LDAP_PROXY=secure&VOIP_MEDIA=srtp&VOIP_SIP=tls HTTP/1.1” 404 194 “-” “Yealink W52P 25.81.0.10 00:15:65:fb:52:5b”
10.0.3.1 - - [22/Mar/2019:14:39:32 +0100] “GET /provisioning/y000000000000.boot?LDAP_PROXY=secure&VOIP_MEDIA=srtp&VOIP_SIP=tls HTTP/1.1” 404 194 “-” “Yealink W52P 25.81.0.10 00:15:65:fb:52:5b”
10.0.3.1 - - [22/Mar/2019:14:39:33 +0100] “GET /provisioning/y000000000025.cfg?LDAP_PROXY=secure&VOIP_MEDIA=srtp&VOIP_SIP=tls HTTP/1.1” 200 2171 “-” “Yealink W52P 25.81.0.10 00:15:65:fb:52:5b”
10.0.3.1 - - [22/Mar/2019:14:39:34 +0100] “GET /provisioning/001565fb525b.cfg?LDAP_PROXY=secure&VOIP_MEDIA=srtp&VOIP_SIP=tls HTTP/1.1” 404 194 “-” “Yealink W52P 25.81.0.10 00:15:65:fb:52:5b”

Das entsprechende Log (001565fb525b.log) schreibt nur

2019-03-22 14:17:13 deviceHandler notice : The device with the mac-address 001565fb525b does no exist in the database yet
2019-03-22 14:28:52 deviceHandler notice : The device with the mac-address 001565fb525b does no exist in the database yet

bevor er das Gerät “versucht” zu provisionieren.

Der Status wechselt dann auch recht schnell von “active” zu “broken”.

Zur Cert. frage:

Das Cert landet gar nciht auf dem Gerät. Also leider gibts da auch nichts zu legitimieren.

Zum provisioning-access.log auf dem Interface:

Hier kommt außer 3x die 200 sehr viele 404 zurück

Zum provisioning-access-error.log auf dem Interface:

hier wird nichts geloggt

Das sieht eigentlich gar nicht so schlecht aus. Es ist normal, dass nur ein paar Anfragen des Yealinks von uns beantwortet (200) werden.
Sind auf dem Gerät schon ein SIP-Peer (unter “Account”) und ein Handset (unter “Status” -> “Handset&VoIP”) angekommen?

Besten Gruß
Sebastian

Hallo @Sebastian_F,
es läuft mittlerweile :slight_smile: Vielen Dank für deine Hilfe.
Ich musste den Provisionierungslink manuell ins Yealink eintragen. Das scheint sich geändert zu haben seit Pascom 17.

Um deine Fragen trotzdem zu beantworten:
Nein, es wurde miener einschätzung nach NUR das PW geändert sonst nichts. Die Telefoniedaten wurden gar nicht verändert. :smiley: