Date: Fri, 7 Jan 2000 17:02:27 +0000 (GMT) From: Andrew Gordon <arg@arg1.demon.co.uk> To: Christoph Kukulies <kuku@gilberto.physik.RWTH-Aachen.DE> Cc: freebsd-isdn@freebsd.org Subject: Re: that dropping connection - rendered unusable Message-ID: <Pine.BSF.4.21.0001071600020.3442-100000@server.arg.sj.co.uk> In-Reply-To: <20000107091725.A65969@gil.physik.rwth-aachen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 7 Jan 2000, Christoph Kukulies wrote:
> On Fri, Jan 07, 2000 at 09:00:24AM +0100, Christoph Kukulies wrote:
> >
> > I still have no clue why the connection, once i4b has idle timed out
> > doesn't get awoken again when activity occurs?
> >
> > This is really bugging me and a true loss of quality compared
> > to the previous way of connecting (raw IP,ipr0, fixed IP addresses on
> > both ends).
The "true loss of quality" comes from using dynamic IP addresses, not the
change from ipr0 to isp0. Many people use fixed IP addresses with
PPP. Ascend MAX units are certainly capable of doing it (I think this is
what you said you were connecting to).
> If I'm not totally off target it must have to do with the
> fact that the sockets that are open on both ends still have
> the old IP address associated with them.
Exactly so.
> Would be a technical solution to 'patch/ioctl' the old sockets with
> the new IP address?
Not really. Something like "natd" could fudge up the 'local' end of the
connection (ie. the addresses on packets coming out of the machine with
the ISDN interface), but this still wouldn't work since the remote machine
has no way of knowing when the ISDN machine's address has changed.
However, if you can't get a static address assignment, there are some more
complex solutions to your problem. If you have full control over both
machines, you can use an IP tunnel ("both machines" means the machine
doing the ISDN dialup, and the machine(s) that your xterm sessions connect
to, or at least some machine permanently attached to the Internet).
The way this works is that you create a tunnel interface in each of the
two machines, and assign it a fixed IP address. If you are only
interested in these two machines, you can assign RFC 1918 addresses, so
you might have:
On your 'home' machine:
ifconfig tun0 10.1.1.1 10.1.1.2
On the server that you want to connect into:
ifconfig tun0 10.1.1.2 10.1.1.1
You then run some sort of tunnel daemon to connect these two interfaces
together. When you want to connect to the server machine (eg. with
telnet), instead of using its 'normal' hostname/IP address, you telnet to
10.1.1.2. Similarly, for your xterms you set DISPLAY to
10.1.1.1:0.0. All the applications are now using fixed addresses, and so
will not notice when the IP address of the ISDN interface changes. The
tunnel daemon _will_ notice, but you can restart that each time the ISDN
link comes up (if necessary), and the applications using the tunnel will
not notice.
There are various options for building the tunnel itself. One popular
option is to use /usr/sbin/ppp in conjunction with SSH, which gives you
security as well as the basic tunnel. A snag with this is that SSH uses a
TCP connection, which will therefore need to be restarted each time the
link comes up (you could get isdnd to do this, but it gets complicated).
/usr/sbin/ppp also supports tunneling over UDP, but I think this requires
fixed IP addresses (and would be rather insecure without) so doesn't fix
the problem. ports/net/tund may be worth a look: it apparently does IP
over UDP with security, but may need hacking to cope with changing
addresses (I haven't used it).
[Confusion alert: I am *NOT* talking here about using /usr/sbin/ppp in
conjunction with i4b's rbch as an alternative to isp0: - if you were doing
that, you would have *TWO* copies of usr/sbin/ppp running, one to build
the basic ppp connection, and another to build the tunnel. The tunnel
involves placing your 'useful' IP traffic inside a PPP wrapping, then
placing that PPP in an IP wrapping, and when those packets go across the
ISDN interface there is another layer of PPP on the outside!].
Alternatively, you could write a simple tunnel daemon yourself - I
estimate that this would only be about 200 lines of code if you don't care
too much about security. The tun0: devices are extremely easy to use - I
haven't written exactly the program you need, but to give you an idea of
how easy it is, I recently wrote an IP-over-ATM-over-IP daemon which came
out at 728 lines, including a bunch of features unconnected to the IP
tunneling.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isdn" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0001071600020.3442-100000>