Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!newsfeed.direct.ca!op.net!news.mathworks.com!newsfeed.internetmci.com!in2.uu.net!shemesh.hq.tis.com!dira.rv.tis.com!not-for-mail From: mark@dira.rv.tis.com (Mark Sienkiewicz) Newsgroups: comp.unix.bsd.bsdi.misc Subject: Re: how to increase socket timeout Date: 5 Sep 1996 15:05:09 -0400 Organization: Trusted Information Systems Lines: 49 Message-ID: <50n895$t34@dira.rv.tis.com> References: <50k99v$53p@crl.crl.com> NNTP-Posting-Host: dira.rv.tis.com In article <50k99v$53p@crl.crl.com>, Stephen J. Kimmel <skimmel@crl.com> wrote: > >How can I increase the length of time a socket will wait for response from >a remote host before timing out? We are running a Gauntlet firewall on a >bsdi 2.1 pentium system and are having a problem with connections timing >out after about 1 minute. If the remote host comes back after that timeout >the packet filtering code on the firewall says that "host xyz connecting on >port 53 - unused port." In other words, the process on the bsdi system >is no longer listening (blocking?) on the port expecting a return packet from >the remote system, and when the packet finally does come back the system >treats it like an unsolicited / invalid packet. I've asked the firewall >vendor but they maintain it isn't their code that controls things like >whether or not the resolver waits for x amount of time for a DNS query to >be answered. > >Is there a kernel parameter that controls this? [You've probably been through some of this with our support line, but let me further describe the problem for other readers.] The particular problem you are seeing is not controlled by the kernel. Here is what happens: A process wants to resolve a name. It creates a socket and sends a UDP packet to a name server listed in /etc/resolv.conf. It then waits for the name server to send a response. Remember though that it is UDP and there is no connection. Sometimes the name server is slow and your process times out. Note that this timeout is implemented in the resolver library, not in the kernel. It is waiting for a UDP packet in reply to it's request. When it times out, it makes a second request. You may get an answer to one or both. If you get an answer to both, your process accepts the first one and closes the socket. The second response generates that warning message. By increasing the timeout period, you could reduce the number of warnings you recieve -- presumably if you waited longer, you would recieve the first answer before sending the second query. You would also wait longer to retry if the packet was lost somehere in the network. My firewall gives me the messages you described all the time. I just ignore them. In fact, I have a script that deletes selected lines from the mail the firewall sends me -- I have quite a few classes of messages that I know to be harmless.