[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-net
Subject:    Socket destroy delayed, and related problems - details
From:       johannes () titan ! westfalen ! de (Johannes Stille)
Date:       1996-03-31 23:45:00
[Download RAW message or body]

Hello everyone!

Since I upgraded from 1.3.32 to 1.3.79, I too get those 'Socket destroy
delayed' messages, though not randomly, but in very specific,
reproducible situations.

I'll try to describe all details that have a remote chance of being
relevant; if they are not, just skip the following section.

I'm running diald for my link to the Internet; it's a version derived
from 0.10 (compiled with "unsafe forwarding" on) and hacked up to work
together with the isdn driver. This code ran without problems for half
a year with Linux 1.3.32 and the 0.6.6 isdn driver release.
Usually I have one or two tcpdump processes running for controlling the
isdn traffic (connection time is expensive).

Now diald puts the link up and thinks it's connected, only the isdn
driver can't really get an connection (e.g. busy).
The resulting situation is: the kernel routes IP packets directly to
the isdn driver which cannot transmit them. diald also watches the link
using a AF_INET SOCK_PACKET socket. It has another  packet socket open
for sending out buffered packets, this socket is currently idle.
tcpdump also wathces all traffic using another packet socket.

Up to now, everything is as it should be.

Now I do a traceroute to a machine on the other end of the isdn link.
(Nothing gets back, remember the link is not connected.) When
traceroute exits, the raw socket used by traceroute for sending gets
stuck with that infamous message.

I can reproduce the problem every time I try this.

It seems that both traceroute and diald are essential, though I'm not
100% sure that one of them isn't sufficient. traceroute usually can be
replaced with other programs, e.g. ping.

I get a similar effect trying to open a TCP connection in this
situation, but there might be another (TCP) bug involved. The
connection gets stuck in SYN_SENT state, "netstat -t -o" shows:

tcp        0      2 osnabrueck.westfa:1423 muenster.westfale:uucp SYN_SENT
uucp             on (15.34/4)

The timer continuously restarts counting down from 120 seconds while
the second number remains constant (I have seen 1 and 5 as well). The
connection seems to never time out. I don't think this is correct :-).

When I kill the process owning the socket, again this results in:
Socket destroy delayed (r=0 w=236)


I think the problem might be connected with packets that either get
stuck in the isdn driver or are misaccounted when they're delivered to
the packet sockets.



In any case, I assume I'm in a good position to help debugging the
problem. But first I'd like to ask if anybody (Alan?) already has some
ideas where to start?

	Johannes

[prev in list] [next in list] [prev in thread] [next in thread]