[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: cldap:// on multi-homed machines does correctly set from address (ITS#2326)



You're right, I don't consider this an OpenLDAP bug. If anything, it's a
feature of your OS kernel. In my tests with a UDP listener bound to
INADDR_ANY, the reply packets are all sent from the IP address of the
interface that received the query.

In your case, if a client 192.168.2.2 tries to contact a server at
192.168.1.1, the server's reply will come from 192.168.2.1.

The obvious solution is to use explicit listener addresses with multiple -h
arguments as you have done. Making a change as you suggest would be
counterintuitive since we don't treat TCP sockets this way. I.e., if you
don't care about the listener address, use ldap://. If you *do* care, list
the listener addresses explicitly - ldap://address1 ldap://address2 etc...

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of lukeh@padl.com
> Sent: Friday, February 21, 2003 10:21 PM
> To: openldap-its@OpenLDAP.org
> Subject: cldap:// on multi-homed machines does correctly set from
> address (ITS#2326)
>
>
> Full_Name: Luke Howard
> Version: HEAD
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (165.228.130.12)
>
>
> You may or may not consider this a bug: on a multi-homed
> machine serving CLDAP
> clients on multiple interfaces, I needed to enumerate
> listeners for each
> interface (eg. slapd -h "cldap://192.168.1.1/
> cldap://192.168.2.1";) in order
> that the local address of outgoing UDP packets contained the
> correct interface
> address. Otherwise, the CLDAP client (not OpenLDAP) would ignore them.
>
> It would be nice if this was the behaviour even if the
> interfaces were not
> enumerated (eg. slapd -h "cldap://";). It shouldn't be hard to fix (?).
>
>
>