multiple ethernet interfaces, naming

multiple ethernet interfaces, naming

[Lucio]

>
> >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.
>
Score 1 for Microsoft, 0 for Lucent :-(

Surely you should be working on IPv6 or somesuch instead of pampering
to the Win'95 world (sigh!)?  Next thing, you'll all be developing
dynamic DNS too :-(
--
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.

multiple ethernet interfaces, naming

[G.David]

I hate replying to my own messages...

Multiple ethernet interfaces are now working.

>From: "G. David Butler" <gdb@dbSystems.com>
>Subject: re: multiple ethernet interfaces, naming
>
>>From: presotto@plan9.bell-labs.com
>>Date: Mon, 7 Jul 1997 10:53:20 -0400
>>Subject: re: multiple ethernet interfaces, naming
>>
>We?  Our source says local is *always* the address of the first
>interface.  I assume you now use cp->src in iplocalfill()?

This was needed.

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

I had to take another tact with arpd, but I didn't have to put it
in the stack.

>>However, I decided that the udp connection oriented stuff was
>>too much of a pain for things like bootp and added a 'headers'

[snip]

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

The secondary code is to handle multiple interfaces, not aliases;
even though it could do that.

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

Needed.  There were no consequences.

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

Boy was that off base!  "look internet" doesn't help much on a chan
that you are trying to create.  Used #P/ipifc instead.

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

I didn't do this all the way yet.  Right now I use the digits at the
end of ether* to target the interface and ip number.  Works OK if there
is only one ip per interface.

>Can anyone think of any other problems?

How about the big one?  The kernel only will pass arp requests to one
arpd and an arpd will only sit on one interface.  Fixed that.

>David Butler
>gdb@dbSystems.com

dito.

multiple ethernet interfaces, naming

[forsyth]

DHCP is an Internet protocol, not exclusively Microsoft's,
nor was it exclusively designed by them
(although you'd hardly be blamed for thinking so, given the
way it is commonly described as a wonderful new Microsoft invention
by the PC press).  it's actually quite a useful thing to have in
the arsenal if you aim to take over the networking world.

multiple ethernet interfaces, naming

[G.David]

>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

multiple ethernet interfaces, naming

[jmk]

	>/net/gre

	What is this, another brazil thingy?

Generic Routing Encapsulation. RFC1701.

multiple ethernet interfaces, naming

[presotto]

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.

multiple ethernet interfaces, naming

[G.David]

>From: presotto@plan9.bell-labs.com
>Date: Thu, 3 Jul 1997 16:32:20 -0400
>Subject: re: multiple ethernet interfaces, naming
>
>I'ld continue ingnoring fddi myself and hoping that it
>goes away.  The 100baset ether is already easier to work
>with.  The giga ether will make it just plain anchronistic.

I agree.  I just wanted to get the syntax down.

>Up to you if you want to treat it as an ether or something
>else.

I went with #l0, #l1, etc. with assumption that other types
of interfaces (non ethernet) will need different support
for IP (like arp).

Done.  I have multiple interfaces working!  Now to phase II.

>From: beto@ncube.com
>Date: Thu, 3 Jul 97 16:05:13 PDT
>Subject: Re: multiple ethernet interfaces, naming
>
>I got another question about multiple ethernet interfaces.
>
>If I do announce("/tcp/*/0",....) what would be the content of
>/tcp/*/local if I have multiple ethernet/ip interfaces.

At this point, since there is no connection, unknown.

>Normally It would return something like
>
>	My.ip.add.ress!nextport
>
>but if we have multiple interfaces what should it return?

I think after the listen returns, then the local address should be
the address of the interface the packet came from.

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

>Maybe 0.0.0.0!nextport until there is a connection and it
>knows which ip interface?

That may work.

>Any comments would be appreacited?

Lets ask presotto@plan9.bell-labs.com if he can give us the
syntax/semantics of the current implementation so we can
stay consistent.

Dave, can you help?

David Butler
gdb@dbSystems.com

multiple ethernet interfaces, naming

[Rich]

>I'm even changing 9P,

Without knowing the details of your situation, I'll comment that this
is almost definitely a really bad thing to do.  Don't sacrifice
interoperability.

multiple ethernet interfaces, naming

[beto]

I got another question about multiple ethernet interfaces.

If I do announce("/tcp/*/0",....) what would be the content of
/tcp/*/local if I have multiple ethernet/ip interfaces.

Normally It would return something like

	My.ip.add.ress!nextport

but if we have multiple interfaces what should it return?

Some programs (bootp, arpd, ftpfs) use this trick to discover the
local ip address and to generate unique port numbers.

Maybe 0.0.0.0!nextport until there is a connection and it
knows which ip interface?

Any comments would be appreacited?

multiple ethernet interfaces, naming

[presotto]

I'ld continue ingnoring fddi myself and hoping that it
goes away.  The 100baset ether is already easier to work
with.  The giga ether will make it just plain anchronistic.

Up to you if you want to treat it as an ether or something
else.

multiple ethernet interfaces, naming

[David]

> >From: presotto@plan9.bell-labs.com
> >For brazil, jmk got multiple ether interfaces working.
> >You might as well make things compatible since we
> >should eventually release this cruft.

	Brazil...
	Where hearts were entertaining June
	We stood beneath an amber moon
	And softly murmured someday soon.

> I don't think that matters any more.  My Plan9 will be
> sooo different by then that it won't do me any good.

Rule 1: don't split up the party!

> I'm even changing 9P, but more on that later.  I'm
> really tired of hearing about brazil.

Brazil, Brazil, Brazil, Brazil!!!

I'd just like to mention that I've "sort of" got Plug and Play
support working.  There's still a fair bit of work to be done
to get it working properly though, but when it is, I plan to
release it.  This requires some changes to the ethernet drivers...

	Tomorrow was another day
	The morning found me miles away
	With still a million things to say...

multiple ethernet interfaces, naming

[G.David]

>From: presotto@plan9.bell-labs.com
>
>For brazil, jmk got multiple ether interfaces working.
>You might as well make things compatible since we
>should eventually release this cruft.

I don't think that matters any more.  My Plan9 will be
sooo different by then that it won't do me any good.
I'm even changing 9P, but more on that later.  I'm
really tired of hearing about brazil.

>                                       They bind as
>'#l0', '#l1', '#l2', ...  The directory names
>are ether0, ether1, ether2, ...

That is consistent with #w[0-6] for sd[0-6]partition, etc.

Lets say you add FDDI.  Do you do #l3 and ether3 is
really fddi, or does #l3 get fddi0?  Would it not be
better to do #lfddi0?  Or would you do #F0 (whatever
letter you choose for fddi) for fddi0?  See below.

>an ls of /net yields
...
>/net/gre

What is this, another brazil thingy?

>In plan9.ini we have
>
>ether0=type=elnk3 port=0xE000
>ether1=type=elnk3 port=0x0300

So, if you have:

ether0=...
ether1=...
fddi0=...
atm0=...
atm1=...

Should each name have a different #.? scsi0=... does.  Or
do we do:

ether0=type=elnk3 ...
ether1=type=decfddi ...

Then #l[0-9] works.

Thanks.

David Butler
gdb@dbSystems.com

multiple ethernet interfaces, naming

[presotto]

For brazil, jmk got multiple ether interfaces working.
You might as well make things compatible since we
should eventually release this cruft.  They bind as
'#l0', '#l1', '#l2', ...  The directory names
are ether0, ether1, ether2, ...  After we do

bind -a '#l0' /net
bind -a '#l1' /net

an ls of /net yields

/net/arp
/net/cs
/net/dns
/net/ether0
/net/ether1
/net/gre
/net/icmp
/net/il
...

In plan9.ini we have

ether0=type=elnk3 port=0xE000
ether1=type=elnk3 port=0x0300

Our strangest machine has 4 ether cards on it.
This should be the same in inferno since it
shares most of this code with brazil.

multiple ethernet interfaces, naming

[G.David]

I am well on the way to supporting multiple ethernet interfaces
on the PC on Plan9 and I thought I would get some input.

Currently the ether device is #l and the card is called simply
ether.  I think the cards should be ether0, ether1, etc.  This
requires changes in a few programs and files to look for
/net/ether0 instead of /net/ether during the boot of the computer.
This also requires the lance device in other ports to call the card
ether0.  I have done all of these.

The next step is the interesting one.  In the kernel there are two
ways of doing multiple devices off one driver.  Examples are the
serial devices eia[0-?] on #t and the network protocols on #I.
The main difference can be seen by a ls '#t' and ls '#I'.  The
second one comes back with "ls: #I: network protocol not supported".
You must specify which protocol you want by ls '#Itcp', for example.
(This is different in Inferno, you don't have to add the tcp part,
if that makes a difference.)

My work so far is to make the ether devices behave like #I.  So one
must bind #lether0, #lether1, etc. separately.  In addition I also
am forcing the ethernet naming specified in plan9.ini instead of
the current driver's way of assiging to "ether" the first card that
probes successfully.  I think this is important since you don't want
to assign any old IP address to any old network card.  Ether0 is
connected to a specific network and a different address would not work.

This is where I want to start the discussion.  First I would like to
understand the thinking behind the #I semantics, especially since it
changed in Inferno.  Next, should #l behave like #I as I have it now
or like #t and why?  Should the semantics of #I change?  And lastly,
if #I changes, what is the use of strings after the initial character
in devices like #Itcp?

As always, thanks for any input.

David Butler
gdb@dbSystems.com