Hello,
Thanks for your reply.
>It doesn't happen all the time, but occasionally I'll notice that
>diald is being "held up", frequently with more than one packet from a
>given site. I sometimes look up the name of the site, and find that
>not all are named, and the ones that are I don't always recognize. A
>recent case turned out to be from Scientific American's (magazine)
>web site, which I had linked to to read an article. That link stayed
>up even after I killed netscape (I think so, anyway).
That is right not all of them are named.
>My guess is that these persistent connections have to do with some
>sort of time-to-live setting in the packets. Using the diald monitor,
>dctrl (or one that I wrote in Perl/Tk), I can watch each connection
>timeout; typically, the persistent ones start at something like 2
>minutes, count down to (near?) zero, then reset to 2 minutes.
I have also noticed that these packets count down to near zero or zero and
then reset itself to 2 minutes.
I have dctrl to monitor the connections and used other tools like netstat
and lsof and found the following results.
1. Netscape is running but idle and I can see the CLOSE_WAIT status in
netstat and I can also see that netscape responsible for the connection in
lsof. Now I close netscape properly and check netstat and I still see those
CLOSE_WAIT connections but now I can no longer see them in lsof. The
packets still continue to go out and come in and they keep my link up.
2. When netscape or any other internet s/w is not running and nothing is
shown by netstat or lsof. I get packets from a web site that I didnt visit
and my machine sends a response back. This time the communication was
started from outside not from my end. This started to happen even before i
did anything after dialing in. My guess to this is that since i am using
dynamic IP, the IP I got in this connection must have been owned by someone
else and that person has visited this web site, but now I have his IP so
the web site is communicating with me instead and keeping my link up.
3. Say my IP was 202.85.99.111 and I was browsing a web site. I then
stopped but diald wasnt disconnecting because of the CLOSE_WAIT problem and
so I disconnected manually. Then reconnected and got an IP of
202.85.99.222. Now my computer still send packets using the IP
202.85.99.111 as the source but doesnt get a reply back because that is no
longer my IP and it just keeps sending it out thus keeping my link up.
I have monitored these packets for upto 30 minutes and sometimes they all
clear and diald will disconnect but sometimes they continue for longer. The
addition of ignore tcp tcp.fin in standard.filters also did not help.
Now I have reach a point where I dont know what else to do. I am quite fed
up of it. I have managed to iron out all the other bugs with diald but this
one I cannot understand.
If this is a bug then where is the bug and in which package?
I have tried using diald 0.99.1 and 0.16.5 and I have tried pppd version
2.3.7, 2.3.7 and 2.3.10. The problem is persistent in all these versions.
I am using Mandrake Linux 6.0 which is claimed to be 100% Red Hat 6.0
compatible. Kernel version 2.2.9-27mdk.
I would really appreciate all the help i can get.
Thanks in advance.
Vikash.
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
