Subject: [netatalk-admins] Routing between LocalTalk and EtherTalk

From: Patrik Schindler <[email-masked]>
Date: Fri, 10 Jul 1998 21:03:36 +0200

Hi,

am I the only one who let Linux in conjunction with Netatalk 1.4b2 do routing between EtherTalk and LocalTalk?
Please write me, I'd like to verify some odd routing behaviour in this case, which I posted two times here but never got any answer.

:wq! PoC

---

From: Patrik Schindler <[email-masked]>
Date: Sun, 12 Jul 1998 14:42:50 +0200

At 13:07 Uhr -0400 11.07.1998, Thompson Freeman wrote:
>Well - I haven't done routing between EtherTalk and LocalTalk at all so
>I'm absolutely no help at all. OTOH, I'm most curious about how you
>accomplished such a thing at all, since it is nonobvious to me.

Oh, it's fairly easy: As soon as you have more than one interface in atalkd.conf , you'll have a router. Okay, there are some more points to care for, for example if you are the only router in one or both of the nets, you'll have to do seeding (provide network numbering and zone information) for the net(s).
With only one interface, atalkd never does seeding, but you can force it to do so, if you configure the dummy interface for this:

eth0 -seed -phase 2 -net 10-20 -address 10.1 -zone "MyZone"
dummy0 -seed phase 2 -net 21-22 -address 21.1 -zone "MyZone"

In either case, as with any other existing internetworking protocol, both interfaces, attached cables and there attached devices MUST have unique network numbers!

I hope, I could clear some things for you. :-)

:wq! PoC

---

From: Patrik Schindler <[email-masked]>
Date: Sun, 12 Jul 1998 22:00:32 +0200

At 2:02 Uhr +0200 11.07.1998, Michael Zuelsdorff wrote:
>Hmmm..., I haven't got your other postings ?!?

I posted them some time ago, a few months or so...

>what I do is some minimal routing via an Apple "LocalTalk bridge",
>installed on a Performa 5100. I can print from my Linux server
>to a HP-Deskwriter connected to the Mac. That's what I do most
>often. From time to time I connect a Notebook to the Localtalk
>net and this works, too.

Jup, I see.

>What is your problem ?

I've got an Apple LocalTalk PC Card and -hey!- there's a driver out there! Thanks to Bradford W. Johnson <[email-masked]> for finding and eliminating a routing-related bug in his driver!!
Some information to my configuration, I use netatalk 1.4b2 with asuns afpd, Kernel 2.0.34 and libc 5.4.23.

This is my net:

          +-------+               +-------+
----------+ leela +---------------+ tycho +-----------
eth1      +-------+ eth0     eth0 +---+---+ eth1
                                      |
                                      | ltalk0
                                      |

Anything missed?
My atalkd.conf's looks like this:

[hostname: tycho]
ltalk0 -seed -phase 1 -net 125 -addr 125.1 -zone "Local"
eth0 -seed -phase 2 -net 100-120 -addr 100.1 -zone "Ether"
eth1 -seed -phase 2 -net 130-140 -addr 130.1 -zone "Ether"

[hostname: leela]
eth0 -seed -phase 2 -net 100-120 -addr 101.1 -zone "Ether"
eth1 -seed -phase 2 -net 150-160 -addr 150.1 -zone "Ether"

Some Output of nbplkup and aecho:

tycho:/root # nbplkup @Ether
                          leela:AFPServer                          150.1:130
                      QMS-Spool:LaserWriter                        150.1:128
                          leela:netatalk                           150.1:4
                          leela:Workstation                        150.1:4
                          tycho:AFPServer                          130.1:128
                          tycho:netatalk                           130.1:4
                          tycho:Workstation                        130.1:4
tycho:/root # nbplkup @Local
                          tycho:AFPServer                          130.1:128
                     QMS-PS 410:LaserWriter                        125.176:128
leela:/root # nbplkup @Ether
                          leela:AFPServer                          150.1:130
                      QMS-Spool:LaserWriter                        150.1:128
                          leela:netatalk                           150.1:4
                          leela:Workstation                        150.1:4
                         PM7500:  Power Macintosh                  159.130:252
                         PM7500:Workstation                        159.130:4
                          tycho:AFPServer                          130.1:128
                          tycho:netatalk                           130.1:4
                          tycho:Workstation                        130.1:4
leela:/root # nbplkup @Local
[Shows nothing]

tycho:/root # aecho 125.176
14 bytes from 125.176: aep_seq=0. time=24. ms
14 bytes from 125.176: aep_seq=1. time=15. ms
14 bytes from 125.176: aep_seq=2. time=19. ms

----125.176 AEP Statistics----
3 packets sent, 3 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 15/19/24

leela:/root # aecho 125.176

----125.176 AEP Statistics----
8 packets sent, 0 packets received, 100% packet los

tycho:/root # aecho 159.130
14 bytes from 159.130: aep_seq=0. time=4. ms
14 bytes from 159.130: aep_seq=1. time=2. ms
14 bytes from 159.130: aep_seq=2. time=5. ms

----159.130 AEP Statistics----
3 packets sent, 3 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 2/3/5

My Questions:

- Why can't I reach LocalTalk devices from any other part of the net?
  (Neither with nbplkup nor with aecho)
- Why does PM7500 not show up in nbplkup from tycho?
- Are there any fixes for this?

Thank you for taking the time to read this, but I think, this maybe serious...

:wq! PoC

---

From: Patrik Schindler <[email-masked]>
Date: Mon, 13 Jul 1998 18:54:12 +0200

At 18:04 Uhr +0300 13.07.1998, Hannu Krosing wrote:

>AFAIK you should have only one seed router per network, so remove the 
>-seed from either tycho:eth0 or leela:eth0. I'm not sure if it removes 
>all your problems, but it's a start ;)

It doesn't work. I spent my leela an 100MBit card to connect my Mac a bit faster, but in the past without a seeding leela, the LocalTalk issue hasn't worked either.
So I don't think, it's a seeding-related problem.
In another net, there were two seeding-routers, too, and it worked. This net had one netware-server acting as seeder and an Apple Internet Router for connecting LocalTalk Devices running on a Mac.

Why two seeding routers? If I halt tycho and reboot leela for some reason, I cannot find devices on the net between leela and tycho, there's no seeder, this net is undefined. Netatalk shows the same behaviour as the AIR and I consider this okay. If I fire up tycho again after leela is running, I had some strange problems not seeing leela in the chooser. I first had to shut down atalk on leela, ifconfig down all netdevices and fire all up again. But I haven't yet analyzed this behaviour further. I'm happy if it runs, and it does. :-)

>Also (I am not very sure about it either ;), but I may be right),  
>the net ranges should be inclusive, ie the following should work
>
>
>  net:150  +-------+    net:140    +-------+  net:130
>                               net:125 | ltalk0
>eth0 -seed -phase 2 -net 140-150 -addr 140.1 -zone "Ether"
>eth1 -seed -phase 2 -net 130-130 -addr 130.1 -zone "Ether"
>
>[hostname: leela]
>eth0       -phase 2 -net 100-140 -addr 140.2 -zone "Ether"
>eth1 -seed -phase 2 -net 150-150 -addr 150.1 -zone "Ether"
>
>notice that 140-150 includes both nets 140 and 150, as doea 100-140 
>for nets 125,130,and 140

No this could not work:

- The net ranges for eth0 from both tycho and leela are inconsistent but this is not important. leela's atalkd rewrites the config, 'cause tycho seeds (leela not) and tells leela the right net range.

- leela's eth0 and localtalk networks overlap, but this is not important, 'cause leela won't seed, tycho seeds the right range, which won't touch localtalk anyway.

- The net range for leela's eth1 and tycho's eth0 overlap, they aren't unique.

It's most important in networking business, whatever protocol(s) like IP, IPX, AppleTalk and such you are running, that

- in an internetwork, ALL network numbers MUST be unique in the whole internetwork and

- for one "cable" the attached networking devices MUST have an unique address in the network number(s) declared for this "cable".

Sorry, I don't know the technical right word for "cable", but I hope anyone knows what I mean, if one imagines a cheapernet. :-)

Anyway, running the same net with a Mac IIcx and AIR acting as replacement for tycho works fine! With the same net range and zone settings.

:wq! PoC

---

From: Hannu Krosing <[email-masked]>
Date: Tue, 14 Jul 1998 14:15:34 +0300

> >notice that 140-150 includes both nets 140 and 150, as doea 100-140

Did you actually try it ?
 
> - The net ranges for eth0 from both tycho and leela are inconsistent but this is not important. leela's atalkd rewrites the config, 'cause tycho seeds (leela not) and tells leela the right net rang…

or perhaps the _wrong_ net range ;)

IMHO net range is what appletalk uses for deciding where to find a net
with certain number.

> - leela's eth0 and localtalk networks overlap, but this is not important, 'cause leela won't seed, tycho seeds the right range, which won't touch localtalk anyway.

They overlap on purpose - so leela can know that going through eth0 it
can get to nets 125 and 130 as well

> - The net range for leela's eth1 and tycho's eth0 overlap, they aren't unique.

again on purpose, but the _nets_ are unique and looking from tycho, they
are within the net range of eth0

> - in an internetwork, ALL network numbers MUST be unique in the whole internetwork and

they are ,just net _ranges_ are'nt

> - for one "cable" the attached networking devices MUST have an unique address in the network number(s) declared for this "cable".

ditto

> Anyway, running the same net with a Mac IIcx and AIR acting as replacement for tycho works fine! With the same net range and zone settings.

what are the _actual_ (versus _configured_) nets and net ranges seeded
by the AIR router ?

Hannu

---

From: Patrik Schindler <[email-masked]>
Date: Tue, 14 Jul 1998 19:37:49 +0200

>Did you actually try it ?

No, I think of it as lost time. It won't work. For sure. Read on ;-)

>or perhaps the _wrong_ net range ;)

Why?

>IMHO net range is what appletalk uses for deciding where to find a net

No. AppleTalk is different from other known protocols. AppleTalk won't use the range parameter to pick one number for a net. Instead, a net consists of more numbers, the net range. AppleTalk nodes choose an unique number from within this range, which lie within the defined range.

To explain some statements further, AppleTalk knows two two kinds of network numbering

- Nonextended numbering (no range but single, unique number for the net and only one assigned zone), found on ARCnet and EtherTalk Phase 1 Networks. Phase 1 networks use the Ethernet II frame which is the same as used with IP. One can have a maximum of 254 nodes on such a network and must choose the net number between 1 65279. A valid zone name consists of up to 32 chars including spaces.
"All AppleTalk routers connected to a network must use the same number for that network, and no other network can use that number." [1]

- Extended Numbering (an unique network numbering range and up to 255 zones assigned per network), found on TokenTalk and EtherTalk Phase 2 networks. Phase 2 networks use the 802.2 Type 1 packet frame, also known as SNAP frame. A net range allows range times 253 nodes in it's net. A one-numer-range is acceptable (net=2-2).
"All AppleTalk routers connected to that network must use the same range for that network, and no other network can use that range or any number contained within it." [2]

>can get to nets 125 and 130 as well

But this breaks with the unique-numbering-law. I think I get the point you want to tell, you try to adapt IP numbering with the different classes and netmask parameters to AppleTalk.
You need to take care of "splitting" a class C net into smaller pieces in IP. With AppleTalk, you do not need this, AppleTalk's Routing Table Maintenance Protocol keeps all routers informed about all network numbers and how to reach them in an internet network, this is a bit like RIP in the IP world.
That's why the Internet speaks IP, no RIP and no AppleTalk, all routers were busy with broadcasting their configuration out ;-)

>are within the net range of eth0

Jup, but you'll have to see the whole range, not only single numbers. As of your point of view, this is okay, but if you see the whole range, it's invalid.

>they are ,just net _ranges_ are'nt

Eh? Right, they are ranges, the net is configured as range and NOT as a bunch of cluttered numbers.

>what are the _actual_ (versus _configured_) nets and net ranges seeded

 121-130  +----------+    131-140    +------+
----------+ nwserver +---------------+ p475 |
          +-----+----+               +--+---+
                |                       |
        141-150 |                   151 | LocalTalk
                |                       |

Okay, the config is a little bit different. I kept unique ranges on ethernet and an unique number on LocalTalk. It works.

I hope, I could state the whole routing problematic a bit clearer.

As far as I can see I've no configuration errors. Perhaps it may help the coders around, changing the line ordering in atalkd.conf from tycho, I get errors like this:

Jun 22 13:35:40 tycho atalkd[97]: rtmp_request for ltalk0
Jun 22 13:35:40 tycho atalkd[97]: rtmp_packet gateway 100.2 up
Jun 22 13:35:41 tycho atalkd[97]: rtmp_request for ltalk0
Jun 22 13:35:45 tycho atalkd[97]: rtmp_config net mismatch 100 != 0

just after trying to configure ltalk0.

I must configure ltalk0 before eth0, than it works without errors. Of course, networks of eth0 and ltalk0 are different.

[1] Netware for Macintosh 3.12 Installation and Maintenance Manual, Page 17
[2] Netware for Macintosh 3.12 Installation and Maintenance Manual, Page 18

:wq! PoC

---

From: Patrik Schindler <[email-masked]>
Date: Tue, 14 Jul 1998 23:27:09 +0200

At 19:37 Uhr +0200 14.07.1998, Patrik Schindler wrote:

Oops, an error has occured ;-)

>- Nonextended numbering (no range but single, unique number for the net and only one assigned zone), found on ARCnet and EtherTalk Phase 1 Networks.

I forgot LocalTalk.

>Phase 1 networks use the Ethernet II frame which is the same as used with IP.

This is only true for EtherTalk.

:wq! PoC

---

From: Patrik Schindler <[email-masked]>
Date: Tue, 14 Jul 1998 23:33:13 +0200

At 22:33 Uhr +0200 13.07.1998, Michael Zuelsdorff wrote:

>1. Although I think, Phase I is correct for Localtalk, give it a try:
>   ltalk0 -seed -phase 2 -net 125-126 -addr 125.1 -zone "Local" 

I tried, won't work. I saw no printer anymore, even from tycho's view. This is 'cause LocalTalk only dows Phase 1.

>2. Try different zone names for the eth1 segments of leela and tycho

My "red book" says, it's okay to have a zone name spread over multiple networks. But I'll give it a try. Be patient ;-)

>3. Try a net with one router only:
>   Remove eth1 from leela and change leela's atalkd.conf to a simple "eth0"

But I need eth1 to connect my Mac to the net. ;-)

This was the situation before I got my 100MBit Card for my Mac. LocalTalk hasn't worked anyway.
My "red book" says, having more than one seed router is okay as long as they are consistently configured.

:wq! PoC

---

From: Bill Studenmund <[email-masked]>
Date: Wed, 15 Jul 1998 22:17:29 -0700 (PDT)

> I tried, won't work. I saw no printer anymore, even from tycho's view.
> This is 'cause LocalTalk only dows Phase 1. 

Well, LocalTalk is the definition of a non-extended network, which was
called phase 1 when EtherTalk came out.

> My "red book" says, it's okay to have a zone name spread over multiple
> networks. But I'll give it a try. Be patient ;-) 

Right. We have that setup here at Stanford. We have many zone names shared
between a LocalTalk segment and an EtherTalk segment. Usually it's where
the group started w/ LocalTalk, grew to Ether, and kept the printers on
LocalTalk. We also have a few zone names shared between buildings!

When you go to do a zone lookup, the broadcast routine looks for all the
network numbers which have that zone name on them, and broadcasts the
lookup (looking for laserWriters, etc) to them all.

> they are consistently configured. 

Right. Some places use it as a backup. If things go down, you don't rely
on the "right" router coming back up. Whichever one comes up will set
things correctly.

Take care,

Bill

---

From: "Brad G. Parks" <[email-masked]>
Date: Wed, 29 Jul 98 14:56:06 -0500

I've got a dozen zones (and i'm not the seed).  I want to place a
server "Experimental" in a zone that isn't the default.  Putting the
following in my afpd.conf:
	"Experimental@ACC" -port 12001 -noguest
works just fine to put it in the ACC zone, but when I go into the
chooser to connect it says the following:
	Connect to the the file server "Experimental@ACC" as:
		o Guest
		o Registered User... etc.
I'm able to connect to it just fine, but here's the rub --
other volumes *don't* put the zone name in that spot!  So, I'd like
it to say:
	Connect to the the file server "Experimental" as:

Y'see what I mean?  Anyone else run into this?  Anyone know how to
fix this?

-brad
bparks@@bethel..edu