[Exim] a strange hitch in some deliveries

hi,

a kind of woodoo magic is going on here... the setup is: i have a mail
hub which accept mails for a certain domain, then using a lookuphost
router it forwards to its real destination that is on an unrouteable
network.

now, some mails (this is really "some", i have no exact numbers, but
maybe one in every 500 or so) fail to get delivered by the hub to the
destination. looking at -v -M <msgid>, it shows:

Connecting to 192.168.102.1 [192.168.102.1.25] ... connected
SMTP<< 220 lionking.xxxx ESMTP Exim 3.33 #1 Wed, 26 Sep 2001
14:28:43 +0200

<normal smtp session here>

SMTP<< 421 lionking.xxxx SMTP incoming data timeout - closing
connection.
SMTP>> QUIT
LOG: 0 MAIN
== xxxx@??? T=internal_smtp defer (0): SMTP error from remote
mailer after end of data: host 192.168.102.1 [192.168.102.1]: 421
lionking.xxxx SMTP incoming data timeout - closing connection.
LOG: 0 MAIN
End queue run: pid=31785 -qff

the other end shows:

2001-09-26 14:32:34 15mDmm-0004tM-00 SMTP data timeout (message
abandoned) on connection from <hub> [ip]

then it stays on the queue, next queue run tries it, with the same
result, then after every configured retry timed out the message is
being bounced back.

both ends are exim 3.33 runnin on debian linux (potato) (that is, gnu
libc 2.1.3 on an i386, hub being kernel version 2.2.19, destination
being 2.2.17). the exims are compiled by my, with the config being
pretty much the same as the default EDITME with paths and the like
changed, doing only normal delivery to berkeley mboxes, based on
system accounts... what else could matter ?

as for the next logical question, a tcpdump or similar output... well,
i do have it, the problem is that the underlying physical layer is
something that libpcap (thus ethereal and friends) don't understand
(it's being done by a specially patched tcpdump), so... well, i can
compile this patched libpcap then ethereal with that, will do.

any ideas where to start looking ?

it seems to happen with any message, not dependent on any source, any
destination address (inside that particular domain of course), happens
with messages of various sizes (from a 1k message to a 200k message
too, they don't often have any bigger than that), and - i've not seen
this kind of behaviour anywhere else (i have a decent number of
various versions of exims around here). it was observed first with
3.12 or 3.14 maybe (that's when i started using exim) and it didn't go
away with any of the upgrades.

any ideas where could i start hunting this down ?

thanks a lot,

--
[-]