Messages in this thread | | | Date | Sun, 18 Oct 1998 21:32:15 +0200 | From | Malware <> | Subject | Re: Dynamic IP hack (PR#294) |
| |
Hi Alexey,
you wrote: > If I did bind() to a saddr nobody is allowed to rewrite this address. > It is critical: if some appl. did bind, it does not want that connection were > initiated with another address.
Sure, but how to find out a application explicitly did call bind() or it was bound implicitly because the source address was 0 in connect()? - Andi Kleen does have an idea for.
> I still assume, that someone, who enabled this sysctl has no > such applications, so that it is not fatal, but must be commented > and made optional.
Isn't and wasn't it optional? One can switch it on or off on run-time. And now one can switch it off at compile time too while I do not see a sense for.
> > > 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.
Have you read all the questions in the networking newsgroups? Most people can not accept that it is not possible to establish a connection by one shot while using on-demand dialing with a dynamic IP. Most even do not tolerate that they have to wait for a second DNS query to be sent out - which does still happen because UDP does not know retransmits. While it does not cause any problem in the masquerading code which allready thought to change the source address with local sockets it won't work without breaking the rule. Wether we permit the source address to be changed and get the connection running in the first shot. Or we permit packets with a wrong source address to go out and have the application to let timeout and fail. One of the worst problems are TCP connections in LAST_ACK which timeout really slow and do a lot of retransmition trials.
> Just think a bit. Or even better make some experiments to be convinced, > that this trick never results in something useful.
I not only did make some experiments. I use it every day! It's currently the only way to avoid spending lots of money to the phone provider for nothing while using on-demand dialing with a dynamic IP.
Malware
- 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/
| |