LDAP auth generates a lot of empty requests, but none authentication request

I am trying to run ejabberd 1.1.3 (with Erlang 5.5.5) built on gentoo box.

I have configured ldap authentication like this:

{auth_method, ldap}.
{ldap_servers, ["ldap.mydomain.com"]}.
{ldap_uidattr, "mail"}.
{ldap_uidattr_format, "%u@mydomain.com"}.
{ldap_base, "ou=People,dc=mydomain,dc=com"}.
{ldap_rootdn, ""}.
{ldap_password, ""}.

I am using Miranda as client.
When trying to connect to server I got only:

=INFO REPORT==== 19-Aug-2007::18:57:33 ===
I(<0.172.0>:ejabberd_listener:90): (#Port<0.281>) Accepted connection {{10,251,0,111},1294} -> {{164,130,59,101},5222}

=INFO REPORT==== 19-Aug-2007::18:57:33 ===
I(<0.182.0>:ejabberd_c2s:417): (#Port<0.281>) Failed legacy authentication for my.name@jabber.mydomain.com/Miranda

No further log from ejabberd. However when I trace ldap communication between ejabberd and ldap server it is quite active:

jabber user # tshark -w ldap.cap -i eth0 -R "ip.addr==164.130.59.101" -f "port 389" -S
Capturing on eth0
1187542784.386764 164.130.59.101 -> 164.130.59.18 TCP 44571 > ldap [SYN] Seq=0 Len=0 MSS=1460 TSV=69981907 TSER=0 WS=5
1187542784.386893 164.130.59.101 -> 164.130.59.18 TCP 59891 > ldap [SYN] Seq=0 Len=0 MSS=1460 TSV=69981907 TSER=0 WS=5
1187542784.387259 164.130.59.18 -> 164.130.59.101 TCP ldap > 44571 [SYN, ACK] Seq=0 Ack=1 Win=24616 Len=0 TSV=470018969 TSER=69981907 WS=0 MSS=1460
1187542784.387272 164.130.59.101 -> 164.130.59.18 TCP 44571 > ldap [ACK] Seq=1 Ack=1 Win=5856 Len=0 TSV=69981907 TSER=470018969
1187542784.387352 164.130.59.18 -> 164.130.59.101 TCP ldap > 59891 [SYN, ACK] Seq=0 Ack=1 Win=24616 Len=0 TSV=470018969 TSER=69981907 WS=0 MSS=1460
1187542784.387356 164.130.59.101 -> 164.130.59.18 TCP 59891 > ldap [ACK] Seq=1 Ack=1 Win=5856 Len=0 TSV=69981907 TSER=470018969
1187542784.401780 164.130.59.101 -> 164.130.59.18 LDAP bindRequest(29) simple
1187542784.401837 164.130.59.101 -> 164.130.59.18 LDAP bindRequest(29) simple
1187542784.402140 164.130.59.18 -> 164.130.59.101 TCP ldap > 44571 [ACK] Seq=1 Ack=15 Win=24616 Len=0 TSV=470018970 TSER=69981911
1187542784.402185 164.130.59.18 -> 164.130.59.101 TCP ldap > 59891 [ACK] Seq=1 Ack=15 Win=24616 Len=0 TSV=470018970 TSER=69981911
1187542784.402843 164.130.59.18 -> 164.130.59.101 LDAP bindResponse(29)
1187542784.402847 164.130.59.101 -> 164.130.59.18 TCP 59891 > ldap [ACK] Seq=15 Ack=15 Win=5856 Len=0 TSV=69981911 TSER=470018970
1187542784.402997 164.130.59.101 -> 164.130.59.18 TCP 59891 > ldap [FIN, ACK] Seq=15 Ack=15 Win=5856 Len=0 TSV=69981911 TSER=470018970
1187542784.403328 164.130.59.18 -> 164.130.59.101 LDAP bindResponse(29)
1187542784.403332 164.130.59.101 -> 164.130.59.18 TCP 44571 > ldap [ACK] Seq=15 Ack=15 Win=5856 Len=0 TSV=69981911 TSER=470018970
1187542784.403432 164.130.59.101 -> 164.130.59.18 TCP 44571 > ldap [FIN, ACK] Seq=15 Ack=15 Win=5856 Len=0 TSV=69981911 TSER=470018970
1187542784.403496 164.130.59.18 -> 164.130.59.101 TCP ldap > 59891 [ACK] Seq=15 Ack=16 Win=24616 Len=0 TSV=470018970 TSER=69981911
1187542784.403888 164.130.59.18 -> 164.130.59.101 TCP ldap > 44571 [ACK] Seq=15 Ack=16 Win=24616 Len=0 TSV=470018970 TSER=69981911
1187542784.404197 164.130.59.18 -> 164.130.59.101 TCP ldap > 59891 [FIN, ACK] Seq=15 Ack=16 Win=24616 Len=0 TSV=470018970 TSER=69981911

This means ejabberd generates continuosly bind requests to ldap server and then terminates them. (In fact it is 2.5 packet/s according to tshark capture.) ejabberd however does not ever generate authentication request.
I am not sure why there are so many void bind request and hope this is a bug, because I am afraid it is not acceptable to load ldap server with such traffic (when ejabberd is otherwise idle - i.e no users).

Also I wonder if anyone can help me to solve the problem with failing authentication?
And finally what does mean "legacy authentication" in this contex?

I am sorry if I am brief, but I did not find any option to extend debugging output, and also searching this forum did not help much.

After rebuilding ejabberd

After rebuilding ejabberd from latest SVN trunk, all problems are solved. So this was definitely bug in 1.1.3.
There is one change in config:
Instead of ldap_uidattr and ldap_uidattr_format the recent version uses ldap_uids which contains list of pairs (uidattr, uidattr_format).

Is the ejabberd guide in SVN up to date

It seems the ejabberd guide in SVN is up to date with the SVN source code, right?

Hmm, thanks for pointing

Hmm, thanks for pointing that out. I have been using old 1.1.3 version doc from ejabbered web site and had to figure that out from sources :(.

I have same errors. Probably

I have same errors. Probably this bug explain why ejabberd can't lookup users from LDAP:
https://bugs.gentoo.org/show_bug.cgi?id=188679
but included patch not work for my gentoo machine :(

I have solved this by using

I have solved this by using lates SVN snapshot. Also it seems the things are mostly solved in devel version (at least to my observation). So if you would want to give it a try, I attach my ebuild, which does build ejabberd on gentoo from SVN. Its basically the copy of the latest tar based ebuild, so nothing much spectacular ;-). Also beware it does not use sasl in run script.

# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

inherit eutils multilib versionator subversion

ESVN_REPO_URI="http://svn.process-one.net/ejabberd/trunk"

JABBER_ETC="/etc/jabber"
JABBER_RUN="/var/run/jabber"
JABBER_SPOOL="/var/spool/jabber"
JABBER_LOG="/var/log/jabber"

DESCRIPTION="The Erlang Jabber Daemon"
HOMEPAGE="http://www.ejabberd.im/"
LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~amd64 ~x86"
IUSE="debug mod_irc mod_muc mod_pubsub ldap odbc ssl web"

DEPEND=">=net-im/jabber-base-0.01
	>=dev-libs/expat-1.95
	odbc? ( dev-db/unixODBC )
	ldap? ( =net-nds/openldap-2* )
	ssl? ( >=dev-libs/openssl-0.9.8 )"

PROVIDE="virtual/jabber-server"

S=${WORKDIR}/src

src_unpack() {
			subversion_src_unpack
			cp -ar ${ESVN_STORE_DIR}/${ESVN_PROJECT}/trunk/* ${WORKDIR}

		}

src_compile() {
	econf ${myconf}							\
		$(use_enable mod_irc)					\
		$(use_enable ldap eldap)				\
		$(use_enable mod_muc)					\
		$(use_enable mod_pubsub)				\
		$(use_enable ssl tls)					\
		$(use_enable web)					\
		$(use_enable odbc)					\
		|| die "econf failed"

	if useq debug; then
		emake ejabberd_debug=true || die "compiling ejabberd core failed"
	else
		emake || die "compiling ejabberd core failed"
	fi
}

src_install() {
	make								\
		DESTDIR=${D}						\
		EJABBERDDIR=${D}/usr/$(get_libdir)/erlang/lib/${P}	\
		ETCDIR=${D}${JABBER_ETC}				\
		LOGDIR=${D}${JABBER_LOG}				\
		install							\
		|| die "install failed"

	chown -R jabber:jabber "${D}${JABBER_ETC}"
	chown -R jabber:jabber "${D}${JABBER_LOG}"
	chown -R jabber:jabber "${D}/usr/$(get_libdir)/erlang/lib/${P}"

	insinto /usr/share/doc/${PF}
	dohtml doc/*.{html,png}

	#
	# Create /usr/bin/ejabberd
	#
	cat < ${T}/ejabberd
#!/bin/bash

erl -pa /usr/$(get_libdir)/erlang/lib/${P}/ebin \\
	${pa} \\
	-sname ejabberd \\
	-s ejabberd \\
	-ejabberd config \"${JABBER_ETC}/ejabberd.cfg\" \\
	log_path \"${JABBER_LOG}/ejabberd.log\" \\
	-kernel inetrc \"${JABBER_ETC}/inetrc\" \\
	-mnesia dir \"${JABBER_SPOOL}\" \\
	\$@
EOF

	#
	# Create /usr/bin/ejabberdctl
	#
	cat < ${T}/ejabberdctl
#!/bin/sh

exec env HOME=${JABBER_RUN} \\
	erl -pa /usr/$(get_libdir)/erlang/lib/${P}/ebin \\
		${pa} \\
		-noinput \\
		-sname ejabberdctl \\
		-s ejabberd_ctl \\
		-extra \$@
EOF

	dobin ${T}/ejabberdctl
	dobin ${T}/ejabberd

	newinitd ${FILESDIR}/ejabberd-1.1.1-r1.initd ${PN}
	newconfd ${FILESDIR}/${P}.confd ${PN}

	insinto ${JABBER_ETC}
	doins ${FILESDIR}/inetrc
	if useq ssl ; then
		doins ${FILESDIR}/ssl.cnf
		newins ${FILESDIR}/self-cert-v2.sh self-cert.sh
	fi
}

pkg_postinst() {
	elog "For configuration instructions, please see /usr/share/doc/${PF}/html/guide.html"
	elog "or the online version at http://www.process-one.net/en/projects/ejabberd/docs/guide_en.html"
	echo
	if useq ssl ; then
		if [ ! -e /etc/jabber/ssl.pem ]; then
			elog "Please edit ${JABBER_ETC}/ssl.cnf and run ${JABBER_ETC}/self-cert.sh"
			elog "Ejabberd may refuse to start without an SSL certificate"
		fi
	fi
	if ! useq web ; then
		elog "The web USE flag is off, this has disabled the web admin interface."
	fi
	if useq odbc ; then
		elog "Please add a column askmessage to the rosterusers table if migrating from 1.1.1"
	fi
}

you should submit this

you should submit this ebuild or a better version to bugs.gentoo.org so gentoo users find it ;-)

Syndicate content