Re: IP masquerading - connections persist too long
Paul Slootman wrote:
>On Thu 03 Feb 2000, Oliver Elphick wrote:
>
>> I have recently switched my ISDN card to a firewall machine, running
>> kernel 2.2.13 and slink.
>
>I hope you're running isdnutils 3.0-12slink14 ? It's in
>slink-proposed-updates. There's at least a Y2K buglet in
>isdnlog (not that that has anything to do with your problem).
3.0-9
>> I am now finding that connections remain open for up to 10 minutes.
>> I think that the masquerading part of the kernel has opened them in
>> order to fulfil connection requests, but is not closing them when
>> the original program closes the connection to the firewall. As a
>> result, I am incurring unnecessary call charges.
>>
>> Does anyone know of a way to force the masqueraded connection to shut
>> down at the same time as the original one?
>
>I doubt that the masqueraded connections are the cause of your troubles.
>I often have the same setup as you mention, and even with the
>masqueraded connection still alive (but not active in the sense of
>traffic flowing), the huptimeout hangup takes place. As soon as data has
>to transferred, the autodial connects again and the IP connection
>continues as if nothing's happened.
Part of the trouble may be that I am using diald. The ISP offers
a pseudo-modem attachment, so I am using /dev/ttyI0 as if it were
a normal modem, rather than using ippp.
I have never managed to get any other arrangement working at all; and
once an arrangement is working, I am reluctant to disturb it!
>However, if you're suffering from dynamic IP addresses from wherever
>you connect to, then beware! If not, ignore the rest of this message.
>
>If the line hangs up (timeout for example) while an IP connection still
>exists, the next time you make a connection, you get a new IP address,
>and then you can send out packets for the old IP connection, but you
>never get an answer because the answers go to the _old_ IP address.
>Hence retries, etc.
diald options cope with that (strict-forwarding); if the link has gone
down, it is not brought up again for connections to the old dynamic
address.
>Same thing when the line has hung up and the (masqueraded) client closes
>the connection. The termination packet (I forget the official TCP name
>for it) goes out, triggering a dialout, and then it waits for an ACK.
>That doesn't happen, retransmit, wait (exponential backoff), retransmit,
>goto begin of loop until max. retries.
>
>You can set how long it takes before an inactive masqueraded connection
>stops being masqueraded; you have to echo something into /proc/net/*,
>but I can't find what at the moment...
This isn't the problem; as soon as a masqueraded connection is started, it
begins with a time of 10 minutes (I'm reading this from dctrl's window).
A typical example is fetchmail, which opens a connection on port 143; a
masqueraded connection to port 6xxxx begins. When fetchmail finishes,
this connection does not finish. It remains, making diald hold the line
open, until it expires or I close the connection manually.
>You _do_ have "echo 1 > /proc/sys/net/ipv4/ip_dynaddr" activated in your
>device.ippp0 script?
This is done at startup by the script that sets up masquerading.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"O come, let us worship and bow down; let us kneel
before the LORD our maker." Psalms 95:6
Reply to: