Setting up Netatalk
I would recommend that you install the netatalk package and see if it works
with default settings. If it does, you don't need to read this.
This is a transcript of extracts from a thread on the newsgroup
muc.lists.netbsd.port.mac68k
the thread was entitled "netatalk problems still" and appeared around November
1999. I got it from dejanews
The main protagonists were:
Bill Studenmund wrstuden@nas.nasa.gov
Henry B Hotz h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu
Miles Nordin carton@Ivy.NET
-------------------------------------------------------------------------------
On Tue, 16 Nov 1999, Hauke Fath wrote:
> At 5:37 Uhr +0100 16.11.1999, Roger Fischer wrote:
> >Is far as I know, nobody's made a package out of the "netatalk+asun"
> >source.
>
> Although this would be nice to have, netatalk+asun builds out just fine of
> the box on NetBSD 1.4.x. It does so on -current, too, but for whatever
> reason does not work correctly (atalkd fails to start up).
Probably because of the changes made to our netatalk stack. I gather you don't have a seed router? These changes only
matter in that case.
atalkd for phase 2 w/o seed router configuers the interfaces as:
lo0: net 0-0
if0: net 0-0xfffe (I think that's the upper #)
(if0: is the one network interface, be it de0, ne1, etc.)
That no longer works. And it was wrong to begin with. We now set things to:
lo0: net 0-0
if0: net 65280-65534
which is what the spec says, and works quite well.
Take care,
Bill
-------------------------------------------------------------------------------
On Tue, 16 Nov 1999, Hauke Fath wrote:
> Meaning what exactly for my configuration?
>
> With "sn0 -phase 2 -addr 65281" I get
>
> [hauke@q700] /<1>contrib/etc # sh rc.atalk
> starting appletalk daemons: atalkd nbp_rgstr: Connection timed out
> Can't register q700:Workstation@*
> nbp_rgstr: Connection timed out
> Can't register q700:netatalk@*
> nbprgstr papd afpd.
What does ifconfig say?
> -- i.e. atalkd _does_ come up, and with asun2.1.4-35 I can even mount
> volumes over AppleShare/IP. But no DDP based functions.
>
> "nbplkup" from a 1.4.1 machine gives
> espresso:AFPServer 65280.71:128
> espresso:netatalk 65280.71:4
> espresso:Workstation 65280.71:4
> Duo280:AFPServer 42377.64:250
> Duo280:RemoteMouse 42377.64:251
> Duo280:PPCToolBox 42377.64:251
> Duo280: Macintosh PowerBook 42377.64:252
> Duo280:Workstation 42377.64:4
Weird! Something's very wrong here. When you have no router, you are supposed
to have addresses from 65280 to 65534. When you have a router, you are NOT
supposed to have address in this range.
Seeing both types of address on the wire shos something's wrong. Did you used
to be hooked to an appletalk network?
Take care,
Bill
-------------------------------------------------------------------------------
Net and node numbers are saved accross boots. In NetATalk they are written
back to the configuration file. Under MacOS I think they are saved in PRAM,
but I could be wrong.
-------------------------------------------------------------------------------
On Wed, 17 Nov 1999, Henry B. Hotz wrote:
>
> Net and node numbers are saved accross boots. In NetATalk they are written
> back to the configuration file. Under MacOS I think they are saved in
> PRAM, but I could be wrong.
Right. But these numbers (outside of 65280->65534) are invalid if there is not an appletalk router around. Machines are
supposed to re-map in that case..
Maybe that's why netatalk does the otherwise-incorrect route of 1->65534 onto the wire when there's no router around.
Take care,
Bill
-------------------------------------------------------------------------------
Technically the correct net number is the one the administrator assigned to the net. :-) Compliance of other machines to
that scheme is seperate.
:-)
I know in phase 2, router vs no router is a boot time decision. If you bring a
machine up w/o phase 2, it's supposed to stick in routerless config, and so if
you bring up routers later, you have to cycle that machine.
I'm not sure what happens if you want to change the net number range on a live
net, if you have to cycle the machines on it..
Hauke, just to make sure I didn't miss something, the only two machines on
this net are your Duo and the netBSD box, yes?
Take care,
Bill
-------------------------------------------------------------------------------
On Fri, 19 Nov 1999, Hauke Fath wrote:
> Depends. WRT AppleTalk, there's a Q700, my main NetBSD workstation. There's
> a Sun IPX which should eventually serve AppleTalk but currently isn't.
> Then, there's a Dayna EtherPrint adapter (LaserWriter bridge), and the
> occasional SE/30 or IIsi.
I bet the EtherPrint adapter might be acting like a router, which is why the
Duo is acting like there's a router.
The way to tell is to run something like tcpdump set to capture all packets
(i.e. Ethertalk ones) when only the etherprint and the NetBSD box is on.
If you see packets flying, it's playing router. :-)
I'm not sure what to do in that case..
If you adjust asun's atalk to just use 1 -> 65534, it should work fine..
Take care,
Bill
-------------------------------------------------------------------------------
At 10:39 AM -0800 11/19/99, Bill Studenmund wrote:
>On Fri, 19 Nov 1999, Henry B. Hotz wrote:
>> Aren't there supposed to be multicast "I'm here" packets preiodically even
>> without a router? Or was that eliminated in Phase 2?
>
>The multicast bits were new for Phase 2. I wasn't aware of hosts sending
>periodical packets, just routers. ??
I think it's fundamental to AppleTalk that everyone knows who else is on line
at a given time if they want to. In LocalTalk this is handled with periodic
"I'm here" broadcasts and is the reason you can't put more than 20-30 devices
on a LocalTalk segment. EtherTalk does something to handle the same function
which uses broadcast packets in Phase 1 and multicast in phase 2.
What I don't know is any of the details past that. I suspect that they still
send "I'm here" packets but have played with some of the timeouts. If you want
to know that a device has been abruptly unplugged and isn't there anymore then
you have to have *some* kind of background traffic to maintain the state of
the network. I would expect that traffic to maintain the network number
unless something like a router exists to force a change.
On power-up a device tries to use its last node (and network?) number as a
default (at least for LocalTalk). I'm not sure when or how a device would
decide to reset from routed to non-routed mode, but the total absence of any
other devices would seem to be one likely case.
Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu
-------------------------------------------------------------------------------
On Fri, 19 Nov 1999, Henry B. Hotz wrote:
> I think it's fundamental to AppleTalk that everyone knows who else is on
> line at a given time if they want to. In LocalTalk this is handled with
> periodic "I'm here" broadcasts and is the reason you can't put more than
> 20-30 devices on a LocalTalk segment. EtherTalk does something to handle
> the same function which uses broadcast packets in Phase 1 and multicast in
> phase 2.
?? I know routers will do this, but hosts shouldn't.
> What I don't know is any of the details past that. I suspect that they
> still send "I'm here" packets but have played with some of the timeouts.
> If you want to know that a device has been abruptly unplugged and isn't
> there anymore then you have to have *some* kind of background traffic to
> maintain the state of the network. I would expect that traffic to maintain
> the network number unless something like a router exists to force a change.
>
> On power-up a device tries to use its last node (and network?) number as a
> default (at least for LocalTalk). I'm not sure when or how a device would
> decide to reset from routed to non-routed mode, but the total absence of
> any other devices would seem to be one likely case.
Only Ethertalk phase 2 has router & non-router modes. LocalTalk and Phase 1
don't. :-) On powerup, a phase 2 device will check for a router, and if it
times out w/o finding one, assumes there's not one. If the router were just
down, you have to power cycle (or switch to another Appletalk interface and
switch back).
All devices will try the same net & node # they used last time on powerup.
They effectivly ping the device, and if there's no response after a number
of tries, they use that address.
Take care,
Bill
-------------------------------------------------------------------------------
On Fri, 19 Nov 1999, Bill Studenmund wrote:
> I bet the EtherPrint adapter might be acting like a router, which is why
> the Duo is acting like there's a router.
[...]
> I'm not sure what to do in that case..
There is an undocumented atalkd.conf option i've been using as follows:
le0 -router -phase 2 -net 339-342 -addr 339.3 -zone "Ivy"
The deal is normally your atalkd-running box is in router mode if (1) it has
more than one interface, or (2) it notices other routers on the wire. The guys
on the netatalk-admins list were historically incredibly anal about this,
``why do you want to do that,'' and ``this is the way it Should be done,''
u.s.w. Well, thanks to -router, now they can all bite me. This option forces
your box to advertise itself as a router, even if it has one interface and
there aren't any other routers. And I can verify that using it does not cause
the sky to come crashing down in a billion fragments like the netatalk-admins
claimed it would.
IIRC -router and -seed are mutually exclusive.
If your bridge is indeed acting as a router, perhaps this option will knock it back in line and get it to quit routing
without putting out seed information that netatalk can use. Also, having
actual router information on the wire might shove MacOS boxes into the
net-range you define, rather than having them suppose ``oh, the router's just
gone for a little while--i'll use my old address.''
I can confirm that MacOS is odd in this regard. For example, I used to run
with the line shown above for atalkd.conf, and then netatalk stopped working
(for reasons of my laziness--nothing to do with this problem)--so i have a
bunch of Mac's around that ``tasted'' the fake netatalk router, but are now
living without it. One says:
Node: 202
Network: 339
Network range: 0 to 65534
Again, this Mac is running without a router. so, addresses are indeed sticky.
BTW to get this info, you need a sufficiently new Open Transport (the last
7.5.5 compatible release, 1.1.2, is new enough), and you must open the
Appletalk control panel, go to Edit->User Mode, and choose Advanced.
After zapping the PRAM, Appletalk Control Panel reports:
Node: 1
Network: 65280
Network range: 0 to 65534
So, it seems that:
o a Mac in Phase 2 routerless mode does indeed accept any network 0-65534,
not just 65280-65534. It simply uses 65280-65534 as the net range for
choosing it's own address, and only if it hasn't already chosen one.
o last-appletalk-address state is indeed stored in PRAM on the Mac, at
least it is for OT 1.1.2.
I thought command-option-PR at boot was supposed to be a way to zap PRAM, but
it didn't work for me--i used Techtool.
Conclusion:
o To work around your problem, use -router on your netatalk box, or zap the
PRAM on your Mac
o ifconfig'ing 0-65534 may appear incorrect, but it looks like maybe that's
what MacOS does.
--
Miles Nordin / v:1-888-857-2723 fax:+1 530 579-8680
555 Bryant Street PMB 182 / Palo Alto, CA 94301-1700 / US
-------------------------------------------------------------------------------
> o ifconfig'ing 0-65534 may appear incorrect, but it looks like maybe
> that's what MacOS does.
The reason it's incorrect is that we already have a route for net 0. :-)
The present netatalk package (which isn't asun) will route 1 -> 65534 to the
real interface. Nothing should be using 0, but it'd get fed to atalkd anyway.
Take care,
Bill
-------------------------------------------------------------------------------