Andi Kleen <ak@suse.de> writes: > On Thu, Jan 25, 2001 at 12:17:45AM +0000, John Fremlin wrote: > > > > Suppose a process has an open TCP connection to e.g. a newsserver > > somewhere across the 'net. Suppose that the interface through which > > this connection is made has its IP address changed. Then the process > > can try to send all the data it wants without getting anywhere, but in > > linux-2.4.0, at least, no errors from send(2) are returned. > > It's no bug but a TCP/IP design feature. > > Applying ftp.suse.com:/pub/people/ak/v2.2/iff-dynamic* and setting > the dynamic flag on the network device using ifconfig will kill all > connections bound to it. Currently for 2.2 only. Right. I located the patch and a very brief discussion on linux-kernel. > > Fooling around in the source, I saw that I most probably want to catch > > NETDEV_CHANGEADDR and NETDEV_DOWN as thrown by > > linux/net/ipv4/devinet.c and scan the list of active connections > > somehow or other and kill (tcp_write_err?) the ones that have the old > > local address. Is there any reason not to do this - i.e. should it be > > a sysctl? > > That is more or less what iff-dynamic does. > > There are various reasons not to do it generally because it breaks > in many setups, but when the user knows what he's doing (= sets > dynamic) it's probably fine. How about using a new ioctl, instead of just SIOCSIFADDR - say SIOCRIFADDR for "replace interface address" that would lay waste to all connections the previous address. This is combining two logically orthogonal operations in one, and so something on the lines of SIOCDELRT on an inet af_ipv4 socket to kill all connections from the previous IP - how about SIOCKILLADDR? As you have no doubt noticed this is my first look at the network layer, so please do not hesitate to butt in and point out that I'm barking up completely the wrong tree ;-) Otherwise I could try to do a patch tomorrow, and update pppd for it. -- http://www.penguinpowered.com/~vii - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
