> Hello!
> > IFF_DYNAMIC doesn't try to change the addresses, it simply knows that the
> > connection is lost because the user gurantees that the IP address is gone
> > and cannot be recovered. Because that fact is known for sure it simply
> > calls tcp_reset on the connection to kill it. The 2.0 RST
> > hack used an indirect scheme, it will send out an packet with wrong
> > source and assumes the other end will RST it.
> If address is deleted it has very good chances to be restored
> couple of seconds later after redialing or something.
> And no flag can grant the opposite statement.
I'm not totally sure I want to get too deep into this debate, since
I have a dedicated connection with static IP addresses and would never
use this option, personally. However... Isn't the whole point here about
dynamic IP addresses? When you dial back in, you get another DIFFERENT
IP address. As a consequence, you can never "close" the old IP address
(I realize that's not literally true - I mean close sessions on the old
address cleanly) or receive resets on them. It's unlikely that you could
recover the old IP address or do much of anything with regard to it.
> I want to stress again: tcp resets may be caused only
> by tcp protocol itself or by user request: they cannot be generated
> because of problem of lower layer of ANY KIND.
> All of such kind of problems are transient by definition.
The unfortunate consequence of dynamic IP address assignments with
dial-in PPP is that transient problems becomes permanent problems.
> Certainly, it does apply only to established state,
> rather than to TCP_SYN_SENT and to pending openreqs.
> > So an sk->userbind flag is the way to go I think.
>
> Excellent. What do you think, if it was sk->autobound flag?
> Set it in inet_autobind(), and reset in bind() or getsockname().
> Seems, it is better or not?
> Alexey
Mike
-- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/