lkml.org 
[lkml]   [1998]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.099 / U:0.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site