Okay, so, per my last thread, Courier on FreeBSD seems to have trouble
doing ident to local IPs. Remote IPs are fine.
I've got a box with about 12 VIPs on it. esmptd(8) binds to one via
LISTEN=. The same IP seems to be honored for outbound ESMTP mail
deliveries (fine) as the source addres
Brian A. Seklecki wrote:
However this is all irrelevant. The problem here is that couriertcpd(8)
is disqualifying the TCP connection and not passing it to esmptd(8) on
some condition related to the presence or lack of presence of
"-noidentlookup".
I'm not aware of any code which will drop
I don't have a FreeBSD box around to test. Can you attach "strace" or gdb to
couriertcpd and see what happens when you connect from localhost?
FreeBSD has ktrace and kdump. But I don't think it's dumping. It's not
core'ing out or anything (the kernel would pick that up and the NOC would
b
On Tue, 2006-02-28 at 14:10, Gordon Messmer wrote:
> Brian A. Seklecki wrote:
> >
> > However this is all irrelevant. The problem here is that couriertcpd(8)
> > is disqualifying the TCP connection and not passing it to esmptd(8) on
> > some condition related to the presence or lack of presence
Brian A. Seklecki wrote:
Attached in private mail the last couple thousand lines with ktrace -d
-and -i. I appreciate you looking at it.
Not private, but it didn't contain any private data, and it wasn't
terribly huge... :)
It looks like it's simply failing to fork.
Actually, it looks
On Wed, 2006-03-01 at 02:17, Gordon Messmer wrote:
> Brian A. Seklecki wrote:
> >
> > Attached in private mail the last couple thousand lines with ktrace -d
> > -and -i. I appreciate you looking at it.
>
> Not private, but it didn't contain any private data, and it wasn't
> terribly huge... :
Brian A. Seklecki wrote:
That's very strange. I would think that perhaps something has changed
in s_sonnect() between the 5.x and 6.x branches. I can check CVS if you
can tell me which underlying functions in /usr/include/netinet might
have changed?
I'm sorry, I don't think I stated that well
Yes, this patch works nicely.
I'd like to say that this was a bug in something new with FreeBSD 6.x,
but Thomas Neumann <[EMAIL PROTECTED]> reported the problem with
FreeBSD 4.9.
My new hypothesis (the distinguishing factor between my previous test in
the lab and my production environment), whi
On Wed, 2006-03-01 at 04:29, Gordon Messmer wrote:
> nderlying functions in /usr/include/netinet might
> > have changed?
>
Yea I was thinking s_connect() in OpenSSL.
> I'm sorry, I don't think I stated that well...
>
> s_connect() is a function in Courier's code, which looks like it's buggy
Brian A. Seklecki wrote:
If you think then check wont adversely affect behavior on other
platforms, then there's no need to make it *BSD specific?
That's what I think... This check should always be the right thing to do.
---
This SF.Net em
On Wed, 2006-03-01 at 11:14, Gordon Messmer wrote:
> Brian A. Seklecki wrote:
> >
> > If you think then check wont adversely affect behavior on other
> > platforms, then there's no need to make it *BSD specific?
>
> That's what I think... This check should always be the right thing to do.
What a
Brian A. Seklecki wrote:
What about just getting general debugging support out of / into
couriertcpd(8) ? Certainly, if you can run it in the F.G. by killing
off --pid= , then certainly a "-D" flag is in order. Something other
than a compile-time option.
couriertcpd writes what debugging it
I see this made it into CVS. Thanks to all (Gordon, MrSam)
http://cvs.sourceforge.net/viewcvs.py/courier/libs/soxwrap/sconnect.c?r1=1.4&r2=1.5
On Wed, 1 Mar 2006, Brian A. Seklecki wrote:
Yes, this patch works nicely.
I'd like to say that this was a bug in something new with FreeBSD 6.x,
b
13 matches
Mail list logo
