On Fri, 15 Aug 2008, Dâniel Fraga wrote:

On Wed, 13 Aug 2008 21:34:10 +0300 (EEST)
"Ilpo Järvinen" [off-list ref] wrote:

quoted

Ok, thanks for your efforts... These are often hard to reproduce because
some not that likely pattern needs to happen and such things is often not
easily controllable (if it is at all possible to influence the 
likelyhoods).

	Hi Ilpo, I don't know if the dumps are correct, but I did when
the connection was stalled.

I would be better to have tcpdump running at least a bit back (2-3 windows 
back is long enough for me), but obviously that might not be possible 
option because it occurs so rarely. ...It should be possible to have 
tcpdump restarted once in a while to avoid a one huge log if you'd just 
keep running tcpdump from beginning.

The problem is, when I dumped "eth0", the connection suddenly come back 
alive again...

The situation (or some of those I did debug with other people) are such 
that they may indeed resolve themself, though I'm also interested why the 
slow part occurred.

so, I don't know if it's useless or not:

What do you mean by "come back alive"...? ...In eth0 log I found this 
connection 189.38.18.122.995 > 192.168.0.2.35477, the ip matches with 
abusar's. But I'm not sure if the connection in the tunnel is the 
interesting one, since it's going to/from port 119 but the ip addresses 
(10.195.195.2 and 10.195.195.1) don't tell anything to me, I guess you 
know their meaning (ie., if 10.195.195.2 is the one with which the 
connection stalls)? ...You're probably right that this wasn't very useful 
log, the longest "stall" I find is only 1.111328 seconds long (and it 
might be due to some processing that is made by 10.195.195.2).

-- 
 i.