Re: Devices with dynamic IP numbers can be annoying.

Stephen M. Benoit (
Wed, 24 Sep 1997 13:07:56 -0400 (EDT)

On Wed, 24 Sep 1997, Rogier Wolff wrote:

> Stephen M. Benoit wrote:
> >
> > 2. So there would be "first class" network devices that use the traditional
> > code, and "second class" network devices that cause additional cleaning up
> > when they go down. Sending SIG_PIPE to all the processes that own sockets
> > with the stale IP numbers, and purging those sockets from the kernel list.
> My ISDN connection goes down after 5 minutes of inactivity. If I'm
> logged in (telnet) to a site somewhere on the internet, and my link
> goes down, I don't always want to close the connection.
> Now if I reconnect, my Dynamic IP seems to have about a 50% chance
> of being the exact same number. So in about 50% of the cases I'd
> needlessly loose the connection, if your suggestion of taking down
> all sockets using that interface is used.

Good point. It becomes a problem of predicting the future! And I don't think
it can be done correctly all the time ;). In your case, it would be fair to
say that you have a 50%-static, 50%-dynamic IP number. With my service
provider, I am guaranteed a different IP number for each connection: they use
a round-robin assignment.

Perhaps this is best done when bringing the network interface up (e.g. with
ifconfig). An additional field in the kernel network device object could be
set/reset from user space. In your case, you could ignore it and use the
default behaviour (traditional). Thus, when your PPP connection goes down,
any surviving sockets would continue to use the same IP number, with a 50%
chance that everything will work perfectly. On my setup I could set the flag
indicating that once the PPP link goes down, the IP number is stale.

Thanks to Alan Cox for reminding me that the kernel's default behaviour is to
verify that the requested local socket address is available... But disabled
by default. So this took care of half the job I described at first.

But what to do with sockets that remain open even when the local IP is stale
(i.e. gone and never coming back) is still an open question: TCP/IP timeouts
are probably the only mechanisms that cover all possibilities.

_____________________________ Stephen M. Benoit _______________________________
~ ~ | | B.Eng (Computer), M.Eng (Electrical)
('>') | Tel: +(514) 255-3550 | Service Providers of America INC
_ | FAX: +(514) 256-1356 | Web page: