9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: G. David Butler gdb@dbSystems.com
Subject: multiple ethernet interfaces, naming
Date: Tue,  8 Jul 1997 08:59:36 -0500	[thread overview]
Message-ID: <19970708135936.dDTx45eni4gCHTqLpRZoYuf2xkRzf1XdfIXy3uG1unA@z> (raw)

>From: presotto@plan9.bell-labs.com
>Date: Mon, 7 Jul 1997 10:53:20 -0400
>Subject: re: multiple ethernet interfaces, naming
>
>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.

Thanks

>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.

We?  Our source says local is *always* the address of the first
interface.  I assume you now use cp->src in iplocalfill()?

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

With the above change.

>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.

Whoa!  That is a faily big change.  Isn't there another way to fix
arpd's problems?  (See below)

>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.

I see that code.  I also see the code in ipconfig that adds a secondary
address by pushing internet again.  So the headers allow you to
handle secondary addresses correctly, since c->src would be the first
address on an interface.  Of course, it would help if arpd worked
correctly. (See below)

>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.

Thanks again (for dhcp, not br*zil... :-)

So far the changes I'm planning look like:

    Change devip.c and make iplocalfill use c->src and deal with the
    consequences (i.e. the problems that crop up).

    Change ipconfig to use "look internet" to see if the interface has
    ever been configured instead of looking for a local address on the
    ip stack.

    Work on arpd (a lot) to use #P/ipifc data to do the right things.

Can anyone think of any other problems?

David Butler
gdb@dbSystems.com




             reply	other threads:[~1997-07-08 13:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-07-08 13:59 G.David [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-07 15:14 jmk
1997-07-07 14:53 presotto
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=19970708135936.dDTx45eni4gCHTqLpRZoYuf2xkRzf1XdfIXy3uG1unA@z \
    --to=9fans@9fans.net \
    /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).