Messages in this thread | | | Date | Sun, 18 Oct 1998 21:51:51 +0200 | From | Andi Kleen <> | Subject | Re: Dynamic IP hack (PR#294) |
| |
On Sun, Oct 18, 1998 at 09:19:23PM +0200, Malware wrote: > Hi Andi, > > you wrote: > > > > > Also, seems, this patch does not guarantee, that socket in established > > > > > state is not mangled. Not good. > > > > > > > > It's not a bug it's the feature. :-) If bit 2 (mask value 4) of > > > > sysctl_ip_dynaddr is set this does mean all packets are rewritten this > > > > does include these belonging to established connections. The goal is to > > > > avoid sending out packets with an invalid source address in order to get > > > > atleast an RST back. > > > > > > I apologize, but this thing is impossible to classify as a feature. > > > > Yes, it is not acceptable. IFF_DYNAMIC is much better @) > > As I allready wrote I accept your idea to be the better way. But it > still needs the help of the old DynIP-hack to serve the purpose. On the > other hand the code I posted does allready work and I experienced no > problem in the daily use. Additionally it can be switched on/off on > runtime so that people who experience problems do not need to hassle > with it. > > > > The IFF_DYNAMIC flag will change a lot for the local sockets but next to > nothing for masqueraded connections. I see three ways for masqueraded > TCP connections in ESTABLISHED state: > > 1. let the retransmits through as it currently happens > => it still needs a RST from the other side to get the socket down > > 2. drop all packets that have masquerading entries with the wrong source > address > => they timeout > > 3. send a faked RST to the source of masquereded connections as soon as > the source address is invalid > => they will disappear fast > > I think 2. is the cleanest solution for this case.
4. Send ICMP_DEST_UNREACH/ICMP_HOST_UNREACH (or _PORT_UNREACH)
I like 4.
-Andi
- 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/
| |