From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Mon,  7 Jul 1997 10:53:20 -0400
From: presotto@plan9.bell-labs.com presotto@plan9.bell-labs.com
Subject: multiple ethernet interfaces, naming
Topicbox-Message-UUID: 5c41591a-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19970707145320.Nt0HAJd_Y0WvHijoZzFUs9Diab81KjN7y4_o6lxsRTM@z>

First of all, I've changed listen to listen specificly to
each port that's important to it in addition to '*'.  Otherwise
local users could hijack listening on important ports.  In
a friendly communittee it is more likely done as a mistake
than intentional malice.

I'll post that listen.

>>
>>If I do announce("/tcp/*/0",....) what would be the content of
>>/tcp/*/local if I have multiple ethernet/ip interfaces.
>
>I think after the listen returns, then the local address should be
>the address of the interface the packet came from.

I currently just make the listener 'local' the address of the first interface.
For the listener it doesn't matter much.  However when the new call
comes in, the local address should indeed be the address the call came to.
That's what we do.

>>Some programs (bootp, arpd, ftpfs) use this trick to discover the
>>local ip address and to generate unique port numbers.
>
>Yeah, there will be changes here.
>

For ftpfs, the above works fine since it is connection oriented and the
new call has the new local address.

Arpd doesn't matter since it is listening to a specific ethernet.
We actually gave up and moved it into the stack.  It made the
booting checken/egg stuff a lot easier.

However, I decided that the udp connection oriented stuff was
too much of a pain for things like bootp and added a 'headers'
control message for udp that causes every udp packets to/from
user programs to be preceeded by 12 bytes of info:

	uchar	raddr[IPaddrlen];	/* remote address */
	uchar	laddr[IPaddrlen];	/* local address */
	uchar	rport[2];
	uchar	lport[2];

That way, we can reply from the same address the message was sent to.

In case a message is sent to a broadcast address, we make 'laddr'
the local address on the interface the message came in
through.  That way, if it's a bootp from a directly connected
network and the system booting has ndb entries on multiple networks
to which the server is directly connected, it can decide which
'ciaddr' IP address to stick in the reply.

I'm currently rewriting bootp to be a dhcp server.  I'll put the
brazil (brazil, brazil, dee dah, dee dah, ...) version out there
for one of you to plan9 ize if you like.