[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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).

  >> 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

  >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: