Probleme bei der Provisionierung mit w52p Yealink

Support
1

Ich habe tatsächlich Probleme mit der Provisonierung des Yealink w52p. Bisher, (bei anderen Anlagen), war es kein Problem; einfach einstecken und es wurde provisioniert.
In einer neuen Anlage die wir gerade aufsetzen passiert das aber leider nicht.
Ich habe das Yealink DECT Gateway manuell angelegt inkl MAC & IP. Dann wird der Status kurz grün. Die Pascom schafft es dann aber nicht das GW zu provisionieren und wechselt den Staus zu “broken”.
Ich schätze mal der grüne Status spricht dasfür, dass die Geräte miteinander kommunizieren können.

Jetzt ist die Frage woran es liegen kann, dass die Auto-Provisionierung hier nicht funktioniert und wie & wo ich das debuggen kann.
Alternativ, ist es auch möglich das Gerät auch manuell einzufügen? (Das wäre natürlich nur interessant, wenn die Prov. insgesamt nicht funktioniert.)

2

Achso; DHCP funkioniert im Netz meiner Einschätzung nach problemlos.
Der Windwos DHCP gibt aber keine Option 66 mit, muss die für die autoprov. aktiviert sein? Falls ja, was ist Best Practice für den “Zeichnfolgewert” in Option 66?

ISt die Doku an der Stelle noch richtig? http://IP-MD:8880/p/Instanzname

3

Hallo @Warmitrax,

In der Doku steht’s anders (für eine pascom 18):

Yealink, Grandstream, Aastra, Mitel
http://[pascom_Server]:8880/p/[Telefonanlagenname]/

Gruß,
Rapha

4

Hast Recht. Den Port habe ich bei mir auch eingetragen; habe den oben wohl vergessen mit ins Forum zu schreiben.

Ich editiere das jetzt.

5

:slight_smile:

Bei einem Grandstream hatte ich keine Probleme mit der Auto-Prov., bei einem Snom war das selbst signierte Zertifikat der pascom “im Weg”, dies musste am Telefon erst manuell erlaubt werden. Ein Yealink habe ich bisher nocht nicht provisioniert.

Edit: Hier gab es vor kurzem schonmal ein ähnliches Problem: Neuaufbau einer 18.03 / Autoprovisionierung schlägt fehl

Gruß,
Rapha

6

Das Cert habe ich gerade auf Let’s Encrypt gewechselt. Auf den anderen Beitrag habe ich gerade geantwortet.
Danke für deine Unterstützung Rapha :slight_smile:

7

hierdas sys.log auf dem Telefonn:

<131>Mar 22 12:11:47 ATP [826]: ATP <3+error > Get static config url fail
<131>Mar 22 12:11:52 Log [1174]: CMDP<3+error > NOT support response cmd=14
<131>Mar 22 12:11:52 Log [1174]: CMDP<3+error > invalid response cmd=74
<128>Mar 22 12:11:55 Log [1378]: ANY <0+emerg > Log log :sys=1,cons=1,time=0,E=3,W=4,N=5,I=6,D=7
<128>Mar 22 12:11:55 Log [1378]: ANY <0+emerg > ETLL=3
<128>Mar 22 12:11:55 sys [1378]: ANY <0+emerg > sys log :type=1,time=0,E=3,W=4,N=5,I=6,D=7
<128>Mar 22 12:11:55 sys [1378]: ANY <0+emerg > LSYS=3
<128>Mar 22 12:11:55 ATP [1378]: ANY <0+emerg > ATP log :type=1,time=0,E=3,W=4,N=5,I=6,D=7
<128>Mar 22 12:11:55 ATP [1378]: ANY <0+emerg > ANY =3
<128>Mar 22 12:11:56 LIBD[1378]: DANY<0+emerg > LIBD log :type=1,time=0,E=3,W=4,N=5,I=6,D=7
<128>Mar 22 12:11:56 LIBD[1378]: DANY<0+emerg > LIBD log :type=1,time=0,E=3,W=4,N=5,I=6,D=7
<128>Mar 22 12:11:56 LIBD[1378]: DANY<0+emerg > DANY=3
<131>Mar 22 12:11:56 ATP [1378]: ATP <3+error > url with auth parameter fail
<131>Mar 22 12:11:56 ATP [1378]: ATP <3+error > Get static config url is empty
<131>Mar 22 12:11:58 LIBD[1378]: HTTP<3+error > Client error, ret = 404
<131>Mar 22 12:11:58 ATP [1378]: ATP <3+error > http to file failed, code = 404, msg = Unknown Error, retry = 1
<131>Mar 22 12:11:59 LIBD[1378]: HTTP<3+error > Client error, ret = 404
<131>Mar 22 12:11:59 ATP [1378]: ATP <3+error > http to file failed, code = 404, msg = Unknown Error, retry = 1
<131>Mar 22 12:12:00 LIBD[1378]: HTTP<3+error > Client error, ret = 404
<131>Mar 22 12:12:00 ATP [1378]: ATP <3+error > http to file failed, code = 404, msg = Unknown Error, retry = 1
<131>Mar 22 12:12:01 LIBD[1378]: HTTP<3+error > Client error, ret = 404
<131>Mar 22 12:12:01 ATP [1378]: ATP <3+error > http to file failed, code = 404, msg = Unknown Error, retry = 1

8

Eine Option wäre noch mit Wireshark den Traffic mitschneiden und schauen was wirklich abgefragt wird, das Logfile ist ja nicht wirklich hilfreich.

Gruß,
Rapha