LOG_NONE/Funny IPs/Linux 2.0.x

From: Jon Zaid <jonz@dont-contact.us>
Date: Thu, 28 Nov 1996 20:40:12 +0100

Folks,
 
I have spent the last few days with Squid 1.1.beta23 (but also same problem
with 1.0.20) and Linux 2.0.18 and 2.0.26.

The problem you are all mentioning are seen in the access.log as a lot of
LOG_NONE errors with "funny" ip numbers. There are also accompanied in the
cache.log by:

96/11/27 12:24:02| commHandleRead: FD 29: read failure: (104) Connection
reset by peer

On a heavily used server we get *quite* a few of these..
First off, a little debugging and you will see that the IP number is screwed
up from the start.. (if you add the remote_port in the commHandleRead trace
you will see the same screwed up IP numbers.)

Going a bit further.

The IP's are wrong for a very good reason.
The reason is that the °accept" went bad on theHttpConnection socket. If the
accept went bad then of course we don't know who the remote address is, and
the IP isn't set.. But, you ask, why are we getting into the "read" on the
client socket if the "accept" returned without error..
Well, it looks as since the HttpConnection is a non-blocking socket, the
accept doesnt properly return the error and you'll get it on the read..

The first change I did was to:
a) in main.c, I removed NONBLOCKING from the open of theHttpConnection socket.
b) in comm.c, after I do the accept, I make the new socket non-blocking.. I
mean in any case we really don't care if the main client socket is blocking
since we do a select with a zero timeout.

After you do these two things, you will now see that you are getting the
connection reset in the accept, and the funny ip numbers will cease and desist.

But, the fun is not over yet. I have spent some time debugging the 2.0
kernel. I believe that there may be some problems there and I am going to
see if we can get some help there (linux-net mailing list).
I have already made one modification to the kernel which drastically reduces
the number of connection resets.

The problem seems to eminate from certain clients who tries to open the
connection with a SYN, linux ACK's the SYN, then the client ACK's linux, but
with a seq number a little bit off followed immediately followed by a
reset. It keeps doing this for quite a few tries until finally the client
acks LINUX "correctly" and does a reset..

Anybody have any ideas?

Did anyone get squid to work on a Linux 2.0 correctly?

jon zaid
Received on Thu Nov 28 1996 - 11:46:15 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:33:40 MST