Project

General

Profile

Funktion zusammen mit Gigaset

Added by Alexander Seitz about 4 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


Replies (4)

RE: Funktion zusammen mit Gigaset - Added by Jörg Ebeling about 4 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 about 4 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?

RE: Funktion zusammen mit Gigaset - Added by Jörg Ebeling about 4 years ago

In progress. Please see #10 of version 0.7.0

RE: Funktion zusammen mit Gigaset - Added by Jörg Ebeling about 4 years ago

Done.

Please check version 0.7.0 as well as the related readme, because adaption of you phone(s) LDAP attributes is required!

Happy about any feedback! ;-)

    (1-4/4)
    Go to top