Most user programs make sockets assuming that the dynamic IP number (for the
"local" connection) will not change.
The problem starts when the device associated with that IP number goes down or
changes... and the user program tries to send another byte with an outdated IP
number. People who use diald know what I'm talking about when the PPP
connection goes down and Netscape is still running.
I'd like to suggest a way of trapping the stale (or spoofed) local IP
addresses.
Detailed version:
-----------------
This is often the case with dynamic PPP connections and programs like Netscape
or FTP. If these programs are still running when the connection goes down,
before exitting, they will transmit 1 byte to the remote hosts recently
visited, using the stale IP number... and the socket goes into the FIN_WAIT1
state for 15 minutes before timeout.
Even if a new PPP route is established, the "local" address of the link will
change, and the transmitted packet has an outdated return IP address... Some
other host will receive the ACK your host requested.
As far as I know, this is considered an "open" problem, but I have
suggestions. I should mention that I am not a kernel hacker.
1. In the kernel, when creating a socket, make sure that the "local" IP number
is listed in the network devices. If not, have the bind() or connect()
call fail. This would prevent *new* sockets from using stale (or fake!)
IP numbers.
The problem is more sticky with sockets that were using the stale IP number
but did not close when the dynamic-IP network device went down.
If there were some way of distinguishing between dynamic-IP network devices
(e.g. ppp, slip) from the "normal" network devices (e.g. eth, lo), the kernel
could take "appropriate" actions on sockets using stale IP numbers.
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.
Is this too naive? Over-complicated? Any comments or counterpoints? Is
there a routing or masquerading trick that solves this already?
_____________________________ Stephen M. Benoit _______________________________
~ ~ | benoits@servicepro.com | B.Eng (Computer), M.Eng (Electrical)
('>') | Tel: +(514) 255-3550 | Service Providers of America INC
_ | FAX: +(514) 256-1356 | Web page: http://www.servicepro.com/
_______|________________________|______________________________________________