Re: connection reset mystery

I apologize, for this is a follow up to an olde thread, but perhaps
not so old to truly warrant the extra e. It's regarding the
"connection with server was reset" problem I've been having since the
end of November.

If anybody wants a refresher of the problem context, you might visit
(http://squid.nlanr.net/mail-archive/squid-users/199911/0726.html)

Duane Wessels <wessels@ircache.net> wrote:

>It might be helpful to run tcpdump on the cache.

I've managed to use tcpdump to snapshot several sessions that take
place over modem connection (because slower bandwidth seems heighten
the chance of a reset). Most of them reset, but a few of them manage
complete the transaction normally, comparing them has been fruitful.

There seems to one defining difference between a "good" (normal, no
reset) and "bad" (connection reset) session each time. There is
always a line that says "truncated-ip - 530 bytes". I don't really
understand what this line means. But I can see that if the client
immediately sends an ack to the server after this line, then a reset
occurs. If the server manages to get a PUSH in before this happens,
then things go smoothly:

"bad"

13:13:14.215319 sputnik.halfbrain.com.www > dialup-166.90.45.124.SanFrancisco1.Level3.net.1204: P 1:537(536) ack 32952 win 32696 (DF)
13:13:14.215372 sputnik.halfbrain.com.www > dialup-166.90.45.124.SanFrancisco1.Level3.net.1204: P 537:1073(536) ack 32952 win 32696 (DF)
13:13:14.288963 truncated-ip - 530 bytes missing!sputnik.halfbrain.com.www > dialup-166.90.45.124.SanFrancisco1.Level3.net.1204: P 537:1073(536) ack 32952 win 32696 (DF)
13:13:14.477906 dialup-166.90.45.124.SanFrancisco1.Level3.net.1204 > sputnik.halfbrain.com.www: . ack 1073 win 8576 (DF)
13:13:14.478017 sputnik.halfbrain.com.www > dialup-166.90.45.124.SanFrancisco1.Level3.net.1204: R 3160985660:3160985660(0) win 0
... session stops here

"good"

13:11:43.081723 sputnik.halfbrain.com.www > dialup-166.90.45.124.SanFrancisco1.Level3.net.1151: P 1:537(536) ack 32952 win 32696 (DF)
13:11:43.081776 sputnik.halfbrain.com.www > dialup-166.90.45.124.SanFrancisco1.Level3.net.1151: P 537:1073(536) ack 32952 win 32696 (DF)
13:11:43.344846 truncated-ip - 530 bytes missing!sputnik.halfbrain.com.www > dialup-166.90.45.124.SanFrancisco1.Level3.net.1151: P 1:537(536) ack 32952 win 32696 (DF)
13:11:46.078490 sputnik.halfbrain.com.www > dialup-166.90.45.124.SanFrancisco1.Level3.net.1151: P 1:537(536) ack 32952 win 32696 (DF)
13:11:46.263612 dialup-166.90.45.124.SanFrancisco1.Level3.net.1151 > sputnik.halfbrain.com.www: . ack 1073 win 8576 (DF)
13:11:46.263703 sputnik.halfbrain.com.www > dialup-166.90.45.124.SanFrancisco1.Level3.net.1151: P 1073:1609(536) ack 32952 win 32696 (DF)
13:11:46.263730 sputnik.halfbrain.com.www > dialup-166.90.45.124.SanFrancisco1.Level3.net.1151: FP 1609:1811(202) ack 32952 win 32696 (DF)
... session continues and completes fine

I've also run tcpdumps on the apache server for which squid is acting
as an accelerator. But I can spot no salient differences between
"good" and "bad" sessions there. I can also see no differences in a
the squid store logs between "good" and "bad" sessions, they both look
like:

945724394.215 RELEASE FFFFFFFF 0 -1 -1 -1 unknown -1/32147 POST http://stage.halfbrain.com/cgi-bin/savebraincell.cgi|Pump
945724394.215 RELEASE FFFFFFFF 200 945724391 -1 945724394 text/html -1/1488 POST http://stage.halfbrain.com/cgi-bin/savebraincell.cgi

So I'm still wondering if anyone has advice on what I might do to
overcome this problem. A particular squid.conf setting I might try?
I've been playing haphazardly with this setting and that, but with no
clear effects.

Meantime I'm continuing to use my bandage - port forwarding just the
saves directly to a apache server (everything else continues to go
through squid and seems to do just fine), which works right and thus
gives me conviction that this reset problem has something to do with
my reverse proxy architecture - either squid itself or something more
subtle that I've missed. But I'm eager to find a fix - the situation
sure makes logging awkward and mucks up the beautiful (distributed
performance)/(fault tolerance) a squid reverse proxy running in
acceleration mode otherwise gives me.

/iain
Received on Mon Dec 20 1999 - 22:31:33 MST