Date: Sat, 20 Apr 2002 19:35:09 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Brett Glass <brett@lariat.org> Cc: chat@freebsd.org Subject: Re: How to control address used by INADDR_ANY? Message-ID: <3CC2255D.6C9B4453@mindspring.com> References: <4.3.2.7.2.20020419144005.0358c610@nospam.lariat.org> <4.3.2.7.2.20020419152309.035a96d0@nospam.lariat.org> <4.3.2.7.2.20020420112056.021aaec0@nospam.lariat.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Brett Glass wrote:
> 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).
No, you are talking about a program that operates as a proxy;
for the rest of the Internet, it looks like a client, but is
in fact a server.
I know that it's convenient to ignore it's server nature, in
order to be able to complain about the address binding, but
it's not really accurate to do that.
How about this: if you can come up with an algorithm that will
"do what I want" for you for all cases, without crippling the
fast path, how about you tell us, and we can think about
implementing it?
> >> 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.
So you are trying to make the FreeBSD box act like a Cisco router.
OK, now we are back to the fact that Cisco routers treat route
endpoints as IP addresses instead of interfaces, and it's the
FreeBSD routing code ... or rather, the route selection for the
inpcb, on connection time.
As I said before, FreeBSD only considers the destination address
when deciding on a route, and this is technically the wrong thing
to do for this particualr weird setup you have.
If you want to actually disclose the information, it's not a
problem.
Another thing that would likely work is to not try to run the
proxy services on the same machine that's acting as the router.
> >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.
Your information is insufficient. A block diagram, with a dotted
line around the blocks you expect to jam into a single FreeBSD
box would be useful.
It really feels like you want something to work that we will all
say "you can't expect that to work!", so rather than giving us
the opportunity to say that, you are parcelling out the information
about the configuration in small chunks, so as to optimize the
chances that we will give you the answer you want to hear.
I have to say: we are not trying to put one over on you, and "hide"
information from you about how to do what you want, so it's really
not necessary.
Why don't you tell us what an already working system looks like? A
system like that already has to exist, if the ISP has more than one
customer.
> >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!
Yes. This is how it works. That's what I said.
> 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.
Arrrrrrrrgh! Why don't you just post what I post back at
me, instead of saying the same thing, and spin-doctoring it?
Yes, this is what is happening: the route is via the interface,
rather than via the IP address, on the way out.
> >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?
Not as such. It's uniquely identified at the host by the IP/port
destination tuple, *NOT* by *both* the source and destination
tuples.
The problem is in the route assignment lookup, and the selection of
the outbound IP address *based on half the information*.
I told you: the FreeBSD TCP stack is not like the Cisco TCP stack.
In order to hack this properly, you would have to put two more
compares in the tcp_output and ip_output code, or you would have
to hack up the "clone" route to have different precedence ordering
of the IP addresses associated with the interface. The new SYN
cache code complicates this type of hack considerably.
The differences are obvious when you try to consider how you
would switch traffic in the context of the FreeBSD stack, without
doing an assignment of an IP address to the downlink port(s) on
the FreeBSD based switch.
-- Terry
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?3CC2255D.6C9B4453>