Subject: Re: netatalk problems still
To: Miles Nordin <carton@Ivy.NET>
From: Bill Studenmund <wrstuden@nas.nasa.gov>
List: port-mac68k
Date: 11/19/1999 18:32:06
On Fri, 19 Nov 1999, Miles Nordin wrote:

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

Yeah, this has bugged me for quite a while. Is this in asun's netatalk?

> IIRC -router and -seed are mutually exclusive.
> 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.

Right. I just re-read Inside Appletalk, and found I'd been mistaken.

>  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