9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: presotto@plan9.bell-labs.com presotto@plan9.bell-labs.com
Subject: multiple ethernet interfaces, naming
Date: Mon,  7 Jul 1997 10:53:20 -0400	[thread overview]
Message-ID: <19970707145320.Nt0HAJd_Y0WvHijoZzFUs9Diab81KjN7y4_o6lxsRTM@z> (raw)

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.




             reply	other threads:[~1997-07-07 14:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-07-07 14:53 presotto [this message]
  -- strict thread matches above, loose matches on Subject: below --
1997-07-10  5:17 G.David
1997-07-08 19:03 forsyth
1997-07-08 14:15 Lucio
1997-07-08 13:59 G.David
1997-07-07 15:14 jmk
1997-07-07 13:03 G.David
1997-07-03 23:40 Rich
1997-07-03 23:05 beto
1997-07-03 20:32 presotto
1997-07-03 17:39 David
1997-07-03 16:32 G.David
1997-07-03 14:19 presotto
1997-07-03 13:34 G.David

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19970707145320.Nt0HAJd_Y0WvHijoZzFUs9Diab81KjN7y4_o6lxsRTM@z \
    --to=presotto@plan9.bell-labs.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).