Re: Fatal error writing to client .Exiting child.

  On 10/6/2010 6:02 PM, Simon Horman wrote:
> On Wed, Oct 06, 2010 at 09:23:10AM -0700, Mark Hamilton wrote:
>>    I don't know if this issue has already been discussed but I didn't see
>> it after a quick search.  I installed perdition 1.18 and set it up.
>> Everything worked fantastic including ssl etc...  Then I started seeing
>> some errors like in the subject line above.  After turning on debugging
>> I saw a mention of a temporary failure in dns before the connection
>> failed.  I tested it myself by putting my ipad in an ip block that did
>> not have a dns server resolving the reverse lookup.  It failed.  I added
>> the block to a dns server where it was expected and it worked fine.
>> Since I don't have access to everyone's reverse ip I tried adding one
>> client to the hosts file on the server running perdition and it seemed
>> to fix the issue as well.  I have an older version, 1.17, that does not
>> seem to have a problem with ips that do not have a proper dns server set
>> up.  Is there anyway to stop this from happening?
> Hi Mark,
>
> that is rather curious. I would be interested to see some more of the log
> messages surrounding the error, particularly with the debug configuration
> option enabled. And to know if the same problem occurs in 1.19-rc4.
>
> Although I'm not having much luck reproducing this problem I suspect that
> the no_lookup configuration option can be used as a work-around.

Ok, I spawned a copy of the perdition server in vmware so I could poke 
at it without making users upset.  I then removed the network from the 
dns server again.  This is what I got:

Oct  6 23:05:14 mail perdition[4803]: Connect: xx.xxx.xx.x->xx.xxx.xx.xx
Oct  6 23:05:15 mail perdition[4803]: SSL connection using AES256-SHA
Oct  6 23:05:15 mail perdition[4803]: greeting_str: getnameinfo 
peername: Temporary failure in name resolution
Oct  6 23:05:15 mail perdition[4803]: greeting: greeting_str
Oct  6 23:05:15 mail perdition[4803]: main: greeting
Oct  6 23:05:15 mail perdition[4803]: Fatal error writing to client 
xx.xxx.xx.x->xx.xxx.xx.xx.Exiting child.
Oct  6 23:05:24 mail perdition[4804]: Connect: xx.xxx.xx.x->xx.xxx.xx.xx
Oct  6 23:05:24 mail perdition[4804]: SSL connection using AES256-SHA
Oct  6 23:05:24 mail perdition[4804]: greeting_str: getnameinfo 
peername: Temporary failure in name resolution
Oct  6 23:05:24 mail perdition[4804]: greeting: greeting_str
Oct  6 23:05:24 mail perdition[4804]: main: greeting
Oct  6 23:05:24 mail perdition[4804]: Fatal error writing to client 
xx.xxx.xx.x->xx.xxx.xx.xx.Exiting child.

Then as you suggested I turned on the no_lookup option and the problem 
went away.  If you do a lookup on the ip address that is in a block that 
is not configured in a name server you get:

Host x.xx.xxx.xx.in-addr.arpa not found: 2(SERVFAIL)

I thought that the SERVFAIL may be the key so I put everything back and 
duplicated the failure.  Then I put the net block in the name server but 
did not give the ip a PTR record.  At this point a lookup in the name 
server gives:

Host x.xx.xxx.xx.in-addr.arpa. not found: 3(NXDOMAIN)

Still a not found but no fail.  I tried the connection to perdition and 
everything was happy.  There were no logs about resolution.  It looks 
like things get scared when the see the fail even though it doesn't seem 
to need an answer.

Thank you very much for your time Mr Horman and I have an acceptable 
solution with the no_lookup option.

Mark
______________________________________________
Perdition-users mailing list
[email protected]
http://lists.vergenet.net/listinfo/perdition-users