Funktion zusammen mit Gigaset
Added by Alexander Seitz over 3 years ago
Hallo,
Ich mache hier mal das erste Thema auf. Der Adapter gefällt mir sehr gut. Mein Setup ist:
-Nextcloud 16
-Gigaset 670 IP Pro
-l2cpbg-macos-x64 unter Mac OS X
Folgendes Setup im Gigaset:
Folgende config für l2cpbg:
[ldap] host = 0.0.0.0 port = 1389 base = dc=example, dc=com [ldap.bind] dn = cn=pbx pass = *** [dav] server = https://xxx/oc2/remote.php/dav user = xxx pass = xxx ;addressbooks = regular-expression-of-lookup-adressbook syncinterval = 5 ; Minutes ; Cache the given (space separated) dav fields. ; Should be the same fields as defined in your phones 'LDAP Name Filter' ; query. Only fields which get listed here, will be used during search ; requests. ; An enabled cache disables live CardDAV requests. Instead of, ; the CardDAV addressbook(s) get queried on the given syncinterval ; for (cache) updates. cache = fn org nickname ;[dav.map] ; tel = TEL ; fn = FN [location] int = 49 area = 89 maxarealength = 9 country = de
Damit schaffe ich es auch die Einträge in einer Liste im Telefon zu erhalten, sobald ich aber einen Eintrag auswähle um die Telefonnummer zu sehen komme ich nicht weiter. Das Telefon meldet dann: "Keine Einträge gefunden". Da versucht dann die Gigaset den detaillierten Eintrag abzufragen. Hier das Log file mit der Anfrage 1 nach der Liste und der Anfrage 2 nach dem konkreten Eintrag:
2020-01-04 19:54:30.100 info: [3c123ce2] Search request #1 from '192.168.1.231:60894::2' 2020-01-04 19:54:30.100 debug:l2cpbg:ldapSearch: [3c123ce2] authorize() 2020-01-04 19:54:30.100 debug:l2cpbg:ldapSearch: [3c123ce2] checkDn() 2020-01-04 19:54:30.100 debug:l2cpbg:ldapSearch: [3c123ce2] checkContentFilters(), req.filter = OrFilter { filters: [ PresenceFilter { type: [Getter], json: [Getter], attribute: 'fn' }, PresenceFilter { type: [Getter], json: [Getter], attribute: 'org' }, PresenceFilter { type: [Getter], json: [Getter], attribute: 'nickname' } ], type: [Getter], json: [Getter] } 2020-01-04 19:54:30.100 debug:l2cpbg:ldapSearch: [3c123ce2] requestedFields(), req.attributes = [ 'fn', [length]: 1 ] 2020-01-04 19:54:31.00 debug:l2cpbg:ldapSearch: [3c123ce2] req.requestedFields = [ { field: 'fn' } ] 2020-01-04 19:54:31.00 debug:l2cpbg:ldapSearch: [3c123ce2] setIsReverseLookup(), req.filter = OrFilter { filters: [ PresenceFilter { type: [Getter], json: [Getter], attribute: 'fn' }, PresenceFilter { type: [Getter], json: [Getter], attribute: 'org' }, PresenceFilter { type: [Getter], json: [Getter], attribute: 'nickname' } ], type: [Getter], json: [Getter] } 2020-01-04 19:54:31.00 debug:l2cpbg:ldapSearch: [3c123ce2] req.isReserveLookup = false 2020-01-04 19:54:31.00 debug:l2cpbg:ldapSearch: [3c123ce2] stats() 2020-01-04 19:54:31.00 debug:l2cpbg:ldapSearch: [3c123ce2] cache() 2020-01-04 19:54:31.00 debug:l2cpbg:cache: [3c123ce2] search(), req.filter = OrFilter { filters: [ PresenceFilter { type: [Getter], json: [Getter], attribute: 'fn' }, PresenceFilter { type: [Getter], json: [Getter], attribute: 'org' }, PresenceFilter { type: [Getter], json: [Getter], attribute: 'nickname' } ], type: [Getter], json: [Getter] } 2020-01-04 19:54:31.00 debug:l2cpbg:cache: [3c123ce2] search(), req.requestedFields = [ { field: 'fn' }, [length]: 1 ] 2020-01-04 19:54:31.01 debug:l2cpbg:cache: [3c123ce2] Search for type.attribute='fn', type.initial='undefined', req.isReserveLookup=false 2020-01-04 19:54:31.01 debug:l2cpbg:cache: [3c123ce2] Search for type.attribute='org', type.initial='undefined', req.isReserveLookup=false 2020-01-04 19:54:31.01 debug:l2cpbg:cache: [3c123ce2] Search for type.attribute='nickname', type.initial='undefined', req.isReserveLookup=false 2020-01-04 19:54:31.01 verbose: [3c123ce2] New search request for value '' = 93 results 2020-01-04 19:54:31.01 debug:l2cpbg:dav2ldap: [3c123ce2] sendVcf(), vcf = vCard { version: '3.0', data: { version: Property {}, fn: Property {}, tel: [ [Property], [Property], [Property], [Property] ], org: Property { group: 'ITEM1' }, uid: Property {} } } = 'BEGIN:VCARD\nVERSION:3.0\nFN:Alexander Seitz\nTEL;TYPE=work:+4989xxxx\nTEL;TYPE=work:+49xxxx\nTEL;TYPE=home:+49 xxx\nTEL;TYPE=cell:+4917xxx\nITEM1.ORG:xxx\nUID:7fa9d648-014d-4094-bbe7-276815f4db8a\nEND:VCARD' 2020-01-04 19:54:31.01 debug:l2cpbg:dav2ldap: dn 'cn=7fa9d648-014d-4094-bbe7-276815f4db8a, dc=example, dc=com' 2020-01-04 19:54:37.33 info: [c6e931e3] Search request #2 from '192.168.1.231:60896::5' 2020-01-04 19:54:37.33 debug:l2cpbg:ldapSearch: [c6e931e3] authorize() 2020-01-04 19:54:37.33 debug:l2cpbg:ldapSearch: [c6e931e3] checkDn() 2020-01-04 19:54:37.33 warn: [c6e931e3] Search dn 'cn=7fa9d648-014d-4094-bbe7-276815f4db8a, dc=example, dc=com' does not match configured dn 'dc=example, dc=com'
Auch im Wireshark Trace sieht man das:
LDAPMessage searchRequest(2) "dc=example, dc=com" wholeSubtree messageID: 2 protocolOp: searchRequest (3) searchRequest baseObject: dc=example, dc=com scope: wholeSubtree (2) derefAliases: neverDerefAliases (0) sizeLimit: 99 timeLimit: 0 typesOnly: False Filter: (|(|(fn=*)(org=*))(nickname=*)) filter: or (1) or: (|(|(fn=*)(org=*))(nickname=*)) or: 3 items Filter: (fn=*) Filter: (org=*) Filter: (nickname=*) attributes: 1 item [Response In: 11]
Und die Antwort auf die Listensuche:
LDAPMessage searchResEntry(2) "cn=7fa9d648-014d-4094-bbe7-276815f4db8a, dc=example, dc=com" [93 results] messageID: 2 protocolOp: searchResEntry (4) searchResEntry objectName: cn=7fa9d648-014d-4094-bbe7-276815f4db8a, dc=example, dc=com attributes: 1 item PartialAttributeList item fn type: fn vals: 1 item AttributeValue: Alexander Seitz [Response To: 9] [Time: 0.017382000 seconds]
Sobald das Telefon dann bei der Auswahl den detaillierten Eintrag anzeigen will sucht es nach dem cn=7fa9d648-014d-4094-bbe7-276815f4db8a, dc=example, dc=com
LDAPMessage searchRequest(5) "cn=7fa9d648-014d-4094-bbe7-276815f4db8a, dc=example, dc=com" baseObject messageID: 5 protocolOp: searchRequest (3) searchRequest baseObject: cn=7fa9d648-014d-4094-bbe7-276815f4db8a, dc=example, dc=com scope: baseObject (0) derefAliases: neverDerefAliases (0) sizeLimit: 0 timeLimit: 0 typesOnly: False Filter: (objectClass=*) filter: present (7) present: objectClass attributes: 6 items AttributeDescription: fn AttributeDescription: tel-home AttributeDescription: tel-work_voice AttributeDescription: tel-cell AttributeDescription: org AttributeDescription: tel [Response In: 47]
Und wie im Log zu erkennen, ist das erfolglos:
LDAPMessage searchResDone(5) noSuchObject (cn=7fa9d648-014d-4094-bbe7-276815f4db8a, dc=example, dc=com) [0 results] messageID: 5 protocolOp: searchResDone (5) searchResDone resultCode: noSuchObject (32) matchedDN: dc=example, dc=com errorMessage: cn=7fa9d648-014d-4094-bbe7-276815f4db8a, dc=example, dc=com [Response To: 45] [Time: 0.002880000 seconds]
Schaltet man das Caching aus kommt übrigens statt der leicht kryptischen cn der Klarname, also cn=Alexander Seitz, dc=example, dc=com. Das Ergebnis ist aber das selbe....
Leider komme ich hier nicht weiter. Ich vermute, dass der Adapter nur eine suche mit fn=xxx unterstützt, aber einen cn=XXX ausliefert. Ich muss aber auch zugeben, dass ich bei LDAP ein ziemlicher Laie bin...
Danke!
Alexander
gigaset.png (116 KB) gigaset.png |
Replies (4)
RE: Funktion zusammen mit Gigaset
-
Added by Jörg Ebeling over 3 years ago
Moin moin Alexander!!
Herzlichen Dank für Deinen super ausführlichen Report!!
Wie Du sicherlich schon gesehen hast, erfreut sich mein Gateway nicht gerade einer großen Beliebtheit ;-), dementsprechend dünn ist auch meine Erfahrung mit anderen Konfigurationen.
Aber mit Nextcloud und MacOS hatte ich schon 1-2 Konfigurationen... das sollte grundsätzlich kein Problem sein.
Ich finde Du bist auch schon ganz schön weit.
Schalte als erstes mal bitte den Cache in meiner Konfig aus.
Jetzt zu Deinem ausführlichen Log meines Gateways.
Ich hab bisher leider nur Yealink Endgeräte (mit LDAP Anfrage) am Start.
Bei den Yealink's ist es so, das sie bereits bei der ersten Suchanfrage alle benötigten Attribute wie z.B. die Telefonnummern mit anfragen:
2020-01-11 12:34:42.19 debug:l2cpbg:ldapSearch: [6c78f7ed] requestedFields(), req.attributes = [ 'fn', 'org', 'tel-work_voice', 'tel-work_cell', 'tel-work', 'tel-car', 'tel-home_voice', 'tel-home', 'tel-cell', 'tel', [length]: 10 ]
Deine Gigaset scheint in der ersten Anfrage aber nur das Fullname Attribute abzufragen:
2020-01-04 19:54:30.100 debug:l2cpbg:ldapSearch: [3c123ce2] requestedFields(), req.attributes = [ 'fn', [length]: 1 ]
Jetzt müssten wir herausfinden ob die Gigaset grundsätzlich für die Detail-Kontakt-Daten eine zweite Anfrage durchführen will, oder ob sie dies nur macht wenn Ihr Kontakt-Einzeldaten fehlen.
Versuche doch bitte mal in der Gigaset Konfiguration unter "Konfiguration der Telefonbuch-Einträge" nur ein/zwei "tel" und "tel-work" Einträge stehen zu lassen und diese auch unter Anzeigeformat "%fn, %tel, %tel-work" einzutragen.
Ich würde gerne sehen ob er dann in der ersten Anfrage das Attribut mit anfragt, also z.B.:
debug:l2cpbg:ldapSearch: [*] requestedFields(), req.attributes = [ 'fn', 'tel', 'tel-work', [length]: 3 ]
Und ob er dann trotzdem noch eine zweite Anfrage für nötig hält.
Dein Wireshark Trace war hier übrigens suuper!
Denn da sieht man was er in der zweiten Anfrage gern haben wollte.
Wenn sich jetzt rausstellen sollte das er in der zweiten Anfrage keine neuen Attribute abfragt (die er in der ersten Anfrage nicht auch schon bekommen hat), dann macht die Gigaset grundsätzlich zwei Abfragen.
Deiner Vermutung das die fn/cn Abfrage nicht unterstützt wird stimmt glaube ich nicht.
Die cn Abfrage mit der kryptischen Nummer ist lediglich eine Abfrage nach der Nextcloud- Kontakt- UID während die andere nach dem FullName ist.
Ich glaube eher das ich grundsätzlich nur die eine/erste Abfrageart auf dc Basis eingebaut habe (ist schon 'n paar Monate her ;-)).
Ich überlege mir in der Zwischenzeit mal ob/wo ich evtl. günstig an so'ne Gigaset ran komme. So'ne 510 hab ich schonmal iwo bei meinen Kunden gesehen.
Viel Erfolg!!! Und bbbbite geb Feedback (auch wenn Du was anderes gefunden, oder keine Lust mehr hattest) :-)
RE: Funktion zusammen mit Gigaset
-
Added by Jörg Ebeling over 3 years ago
Hi Alexander.
Ich hab mir nun 'ne Gigaset N510 IP Pro besorgt.
Der Workaround den ich beschrieben hatte funktioniert nicht!!
Das Gigaset macht immer eine zweite Abfrage die mein Gateway nicht versteht... aber das kann man ja ändern ;-)
Hast Du noch Interesse an einer Lösung, oder hast Du schon 'ne Alternative gefunden?