Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 20 Apr 2002 11:50:21 -0600
From:      Brett Glass <brett@lariat.org>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        chat@freebsd.org
Subject:   Re: How to control address used by INADDR_ANY?
Message-ID:  <4.3.2.7.2.20020420112056.021aaec0@nospam.lariat.org>
In-Reply-To: <3CC12B36.E9DC0040@mindspring.com>
References:  <4.3.2.7.2.20020419144005.0358c610@nospam.lariat.org> <4.3.2.7.2.20020419152309.035a96d0@nospam.lariat.org>

next in thread | previous in thread | raw e-mail | index | archive | help
At 02:47 AM 4/20/2002, Terry Lambert wrote:

>> And few, if any, of the standard apps one is
>> likely to use in administration offer you the option of specifying
>> a source address explicitly. For example, suppose I want to bring
>> in a patch or some code via anonymous FTP. I can't, because the
>> Berkeley FTP client doesn't let you specify a source address.
>
>All FTP servers allow it, and so do "bind" and "sendmail".  The
>code that doesn't allow it could be said to be broken.

I'm talking about "client" programs (e.g. ftp(1)), not servers
like ftpd(8).

>> I'm not sure I follow. There's no bridged network here.
>
>Then I don't understand how the ISP is tunneling packets from
>the assigned published IP addresses out to the real internet,
>or back.  It *must* be doinging bridging for you.  The 10.x
>addresses you are using are, by definition, non-routable.

It's doing hierarchical routing on 10.x. Their internal 10.x.x.x 
network is broken up into /24 subnets, one of which exists here.
(They have a little router here, and a few other routers tie
into it.) Packets for the "real" addresses are to be routed to 
a specific 10.x address which will be owned by the router I'm 
putting up.

>I would have to know how
>your ISP expects things to work, for me to be able to tell
>you how to configure your FreeBSD box to work they way they
>expect things to work (if it's even possible).

See above.

>The problem is that the route code does not distinguish multiple
>default routes, nor does it distinguish aliases from their
>interfaces.

I've looked at the code you mentioned, and the problem seems to
go deeper than that: the routing code is so intertwined with
the rest of the stack that whenever one opens a socket with
INADDR_ANY, the routing table is consulted to figure out how to 
assign a source address! It seems to me that there should be
a bit of separation between the machine's internal "router" and
the code that handles sockets for local processes... as if
the environment where local processes was running were a separate
machine. But things are so intertwingled that this separation
does not exist.

>You could pound on the code, and abuse it in such a way as
>to make it do what you suggest,at the same time putting
>enough special cases into the code path that you bloat the
>normal 94 instructions for the TCP/IP fastpath into some
>huge number that would prevent your suggested changes ever
>being committed back to FreeBSD.

Would it affect the "fastpath?" As I understand it, a socket's source
address is defined when it's opened and stays that way thereafter.
(Correct me if I'm wrong there, but isn't a socket uniquely defined during 
its lifetime by the tuple of {source address, source port, destination 
address, destination port}?) All that would need to be altered would be 
the *initial* decision about the source address used. Right?

--Brett




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.3.2.7.2.20020420112056.021aaec0>