Sorry for the late reply. Yes, I agree. There are these
two theories. My experience seems to be that you
are more likely (in practice) to hit the first method
(in which the new SYN is actually a new one and
not an old SYN hanging out in the network somewhere).
There could be scenarios in which that might happen
though, ofcourse. Perhaps, this behaviour should
be configurable/sysctable ??
Rajeev
----- Original Message -----
From: "Andi Kleen" <[EMAIL PROTECTED]>
To: "Rajeev Bector" <[EMAIL PROTECTED]>
Cc: "Andi Kleen" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Tuesday, July 11, 2000 3:19 AM
Subject: Re: multiple TCP sockets with same (srcip,dstip,sport,dport)
| On Mon, Jul 10, 2000 at 01:02:21PM -0700, Rajeev Bector wrote:
| > Hi Andi,
| > Thanks for your patch. If I am not wrong, it seems to have two
| > problems:
| >
| > [1] If the new SYN is out of window, we do send an ACK back but
| > we dont update the open_req's rcv_isn.
| >
| > [2] If its in the window, we decide to send a RST which is fine,
| > but we need to free the open_req structure.
| >
| > Does that seem right ?
|
| You can have two theories about the origin of the different SYNs.
| Either the host has been rebooted/the address has been redialed
| and the new SYN is from the new owner of the address, or it is an
| old duplicated segment in the network that is not from the owner
| of the source address. You seem to prefer the first way. I and the
| RFC consider it the second way. If you believe in the new owner
| fully you wouldn't send RST but silently rewrite the open_request.
| I think it is more clean to not let new SYNs rewrite open_requests.
|
|
|
| -Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
