Subject: [netatalk-admins] Re: Netatalk works quite transparently:

From: "Justin C. Walker" <[email-masked]>
Date: Mon, 5 Jul 1999 20:44:53 -0700

> From: Heinz Nabielek <[email-masked]>
> Date: 1999-07-05 01:44:23 -0700
> To: [email-masked],
> [email-masked],[email-masked]
> Subject: Netatalk works quite transparently:
> X-Sender: [email-masked]
> X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
> X-MIME-Autoconverted: from quoted-printable to 8bit by
> public.lists.apple.comid BAA12626
>
> Netatalk works quite transparently:
  As does AppleTalk.  The only tricky part is configuring routers.

[snip]

____________________________________________________________________________  

> _____
>
> What puzzles me, are the Appletalk network numbers
> 65280.5=FF00/05hex
> 41201.173=A0F1/ADhex
  Apple represents AppleTalk network addresses as decimal: 16 bits  
(unsigned) for network number and 8-bit (unsigned) for node number.

> Linux tcpdump shows
> "aarp probe 160.241.173 tell 160.241.173"
> and I note
> 160x16^2+241=41201.
>
> On Linux, /etc/atalk/afpd.conf is
> server1 -port 12000
> server2 -port 12001
> server3 -port 12003
>
> and /etc/atalk/atalkd.conf
> eth0 -phase 2 -net 0-65534 65280.5
> whereby the last item fixes the Appletalk
> network address on the linux box.
>
> But- how do I fix the Appletalk address
> on the MacOS side?
  I'm not sure what you mean by "fix".  Looks like there's a bit of  
inconsistency in network number representation on non-Mac boxes:  
sometimes it's 16-bit unsigned decimal, sometimes, it's a pair of  
8-bit unsigned decimal numbers (e.g. "tell 160.241.173": the first  
number is the "high" byte of the network number; the second, the  
"low" byte; and the third is the node number).

> 65280.5 was the linux box' address under MacOS.
>
> Who dishes out these numbers in the first place?

Unlike the IP world, the AppleTalk world is "self-defined".  There  
is no IANA/ICANN to assign network numbers, and there's no  
presumption that network numbers are unique world-wide.  That's why  
joining previously separate AppleTalk internets is such a joy.

Starting from the simple case: no routers means that each system  
decides for itself what its network number and node number is.  There  
is a predefined range of network numbers called the startup range.   
Check Inside AppleTalk (which I don't have with me right now) or the  
code for the exact range.  Something in the high 16-bits.  Without a  
router present, a newly booted AppleTalk node selects a network  
number from this range.  Then it sends out a probe (AARP) with its  
chosen network number and node number, asking if anyone's seen this  
one.  If yes, it chooses another node number and proceeds.  If no,  
that's its address.

Life is similar in the presence of routers, except that after a  
successful "defense of address", a packet is sent out asking for  
network information.  No router means no response; if there's a  
router, it responds with the "cable range" of network numbers, and  
the address defense begins again, as above, but with a new network  
number.  Eventually this converges, or all addresses are taken (and  
the cooperative node won't partake in AppleTalk).

Network number assignment, outside the startup range, is in the  
hands of the sysadmins who administer the routers.  So-called  
seed-routers distribute network numbers to attached network segments.

It gets really complex at this point, but the effective answer to  
your question is:
   - no routers -> each node decides its address and defends it
   - routers -> a more complex environment, and network number  
assignment is in their hands (although the effect on individual nodes  
is just another round of defense; typical nodes cache their address  
in NVRAM/PRAM to simplify life, but the cache is really only a hint:  
between reboots, another node could end up with your address).

Hope this helps, and wasn't too involved.

Regards,

Justin

--
Justin C. Walker, Curmudgeon-At-Large *
Institute for General Semantics       |
Manager, CoreOS Networking            | When crypto is outlawed,
Apple Computer, Inc.                  | Only outlaws will have crypto.
2 Infinite Loop                       |
Cupertino, CA 95014                   |
*-------------------------------------*-------------------------------*

---

From: Konstantin Reznitsky <[email-masked]>
Date: Tue, 6 Jul 1999 11:44:20 -0400 (EWT)

>   I'm not sure what you mean by "fix".  

I think this is about forcing network address (zone, cable-range and node
address to be fixed and not discovered every time from the network. Here
65280.5 is the node address of the linux box. This address might change
after reboot. This may happen if you are not using -seed. You can't use
seed here (only one interface). On the mac side you can "fix" it in the
AppleTalk configuration in the advanced mode and lock it in the
administrator mode. But how to "fix" it on the linux side on the machine
with only one interface (where you can't use seed) is still a question.

Konstantin.

---

From: "Justin C. Walker" <[email-masked]>
Date: Tue, 6 Jul 1999 09:12:14 -0700

> From: Konstantin Reznitsky <[email-masked]>
> Date: 1999-07-06 08:41:57 -0700
> To: "Justin C. Walker" <[email-masked]>
> Subject: Re: [netatalk-admins] Re: Netatalk works quite transparently: 
> Cc: Heinz Nabielek <[email-masked]>,  
[email-masked]
> In-reply-to: <[email-masked]>
>
>
>

You can always "force" the network address, even in Macs.  The  
individual nodes can usually recover from a collision of "forced  
addresses".

Even with a single interface, you should be able to seed.  I don't  
know precisely how netatalk works, but for systems like the Apple  
Network Server and Mac OS X Server, this is legal.

The network number and node number are always subject to change upon  
reboot.  Normally, sytems cache addresses and use these as hints on  
reboot.  Seeding (of network numbers) is orthogonal to the reuse of  
addresses.

Regards,

Justin

---

From: a sun <[email-masked]>
Date: Tue, 6 Jul 1999 13:13:48 -0700 (PDT)

my patches to netatalk allow the seeding of a single interface. they
just use a different option (-router) so that people using -seed with
a single interface don't suddenly get different behaviour.

netatalk does that as well. for my next patchset, i've added bits so
that you can multihome. it's currently called -dontroute right now as
you can't run such devices in router mode. if i have time, i'll change
the logic so that single interface routing works with multihoming as
well as supporting virtual appletalk routing domains. in addition, i
had to change stuff so that you can specify the actual appletalk
address to use for any particular service.

unfortunately, netatalk still sends nbp info for all devices that it
knows about. my simple attempt to bind nbp entries to devices seems to
have failed, but i'll try to come up with something so that it doesn't
do that.

-a