Subject: Re: netatalk problems still
To: Bill Studenmund <wrstuden@nas.nasa.gov>
From: Miles Nordin <carton@Ivy.NET>
List: port-mac68k
Date: 11/19/1999 19:19:48
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 Opoen 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