Hi Matt,

your problem has been discussed only a few weeks ago. Therefore I'll insert the
last answer to me from Erik Corry (many thanks to him for his helpful replies!)
at the relevant position in your query.

[EMAIL PROTECTED] wrote:
> 
> My IP is dynamically each time I connect with PPP, so any open TCP
> connections at the time the PPP link goes down are basically useless.
> 
> Still, diald tries to reconnect if I, say, continue typing into an
> xterm that was logged into another machine.
> 
> Is there any way to close these "dangling" TCP connections when my
> ppp0 interface goes down?

Yes, there is one, see below in the insertion of the former discussion:

--------------------------------------------------------------------------------
On Tue, Sep 08, 1998 at 05:32:25PM +0200, Thomas Michalka wrote:
> Hi Erik,
> 
> many thanks for enlightening the end of the tunnel!
> 
> Erik Corry wrote:
> > 
> > On Fri, Aug 07, 1998 at 08:04:52PM +0200, Thomas Michalka wrote:
> > > the link was hold/brought up caused by packets which came from an IP
> > > address outside of my system, moreover, the IP number is one of my
> > > provider's pool!  The destination also is anywhere in the world.
> > 
> > The IP number is an old one which your machine used to have, but
> > doesn't have any more.  The problem is caused by stuck sockets
> > which cannot close because they have an old address, and so never
> > get any answers from the remote end, which would let them close.
> 
> Sounds like a basic problem with demand diallers, and why didn't I have it
> with diald 0.14 (a lot of others with this version ?-P ), but now with 0.16?
> But what causes the socket to still remain after diald has disconnected?

This happens if you have a very slow or idle socket so that diald
closes down before the socket has closed.  It could also happen
if diald is not set up right, so it doesn't extend the timeout
while sockets are open.

> > Solve this with
> > 
> > echo 5 > /proc/sys/net/ipv4/ip_dynaddr
> 
> And why do I have to manually clear the socket? I want diald to do this or

You do this once after booting!

> anyway to be done automatically!
> How can I solve this problem in an elegant way?
> Can't diald close the socket when it brings a link down?

Would be nice.  At the moment the diald connection
will come up once, then the sockets will be killed.
Not optimal, but much better than the connection going up
and down for ages.

Basically, this would involve reading netstat output (or
the /proc info behind it) and identifying the sockets that
need to die.  Then you force RST packets and send them to
those sockets to kill them.  To do that, you need to know
the sequence numbers of the open sockets, which I don't
know how to find out from user space.

You can also play tricks with ipfwadm, but it's tricky to
get right.  You set it to reject on the old source address,
then the socket will be closed down next time it tries to
send something.  But after the diald interface comes up
again, you must remove the reject rule (replace it with a
deny rule), since rejects will go to your old IP address
ie they will go out to the ISP and keep the link up!
You need to delete deny rules after a few hours to avoid
getting a too large set of old ipfwadm rules, and when the
interface comes up you need to delete all deny or reject
rules that might still be on the address from last time you
were given that address.  In practice this is too fiddly,
and RST-provoking works well enough for most people.

> > See /usr/src/linux/Documentation/networking/ip_dynaddr.txt
> > for details.  You need at least 2.0.34 for this to work
> > (slightly older if you have a SuSE kernel rather than
> > straight Alan/Linus).
> 
> I have SuSE system with kernel 2.0.33, young enough?

Sorry, I am not sure.  There were SuSE 2.0.33s that had it
in, there may have been some that didn't.  If you installed
an official Linus/Alan kernel, then 2.0.33 is not new enough.
With 2.0.34+ you are sure.  If you have the source look in
the doc file above and check whether it mentions RST-provoking.

You can also test it.  Telnet into a server, and leave
the connection alone until the diald link goes down.
Then press return.  If RST-provoking is working (remember
to switch it on first with the echo line above) then the
telnet connection will be closed as soon as diald has
reestablished the connection.  If RST-provoking is not
working, then the telnet connection will hang and will
cause diald to keep dialling.

-- 
Erik Corry
----------------------------------------------------------------------------------

> This way, diald won't go and try to
> reconnect with my ISP in a futile attempt to reestablish the TCP
> connection.
> 
> --
> Matt


Hope this helps!

Regards, Thomas Michalka



-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]

Reply via email to