Re: [TCLUG:15155] Netatalk issues

["Brian Ackermann" <brian_ackermann@bbros.com>]

----------
>From: "Kevin R. Bullock" <kbullock@ringworld.org>
>To: tclug <tclug-list@mn-linux.org>
>Subject: Re: [TCLUG:15155] Netatalk issues
>Date: Sat, Mar 25, 2000, 9:35 PM
>

> On Fri, 24 Mar 2000, Brian Ackermann wrote:
>
>> My understanding is, that appletalk is a UDP based protocol.
>
> As has already been said, AppleTalk uses its own datagram protocol, known
> as DDP. Has nothing to do with UDP (or even IP, IIRC).
>
>> Now, if the firewall is configured to ACCEPT all packets from the eth1
>> subnet, to the eth2 subnet, and vise versa then it seems to me that
>> appletalk should flow freely between the subnets..
>
> I'm not sure that the firewall would have any effect on AppleTalk, since
> it's unrelated to IP (unless you're running appletalk-over-ip). AppleTalk
> packets may be flowing freely over the entire system, but that's a matter
> for a different discussion.

The above was written assuming AppleTalk was based on UDP...As its not, it
can be safely ignored...And, its not appletalk over IP, so...
>
>> This did not appear to be happening, so I installed netatalk to force
>> routing across the subnets, and everything has been SORTOF working ever
>> since.  The problem is, that appletalk is totally unreliable for anything,
>> like a file transfer, server connect, printspooling, etc....The service just
>> vanishes...it 'ghosts' in and out, if you will....
>
> How did you "force routing"?
Again, I wrote the above with a few assumptions, which were wrong.  I
'forced' it by configuring netatalk, nothing more.
>
>> I've posted this question to the netatalk group several times, but nobody
>> deigned to answer me, so perhaps a benevolent sould hereabouts will have at
>> least some insight...My boss is getting cranky with me, and wants to blame
>> linux for the problem...I'm sure its some kind of configuration issue or
>> something, but I don't know.  Also, I'm curious why my original premise that
>> ATALK should just route automatically was wrong....
>
> This may have something to do with the AppleTalk zones -- maybe the
> clients on eth1 can't see the zone for the clients on eth2? Play around
> with atalkd.conf (if you haven't already). Put eth1 and eth2 in there,
> possibly with some extra options to shove them into the same zone. (eth1
> and eth2 should probably be in there anyway, since in the default
> configuration, with no interfaces specified, is to open up appletalk to
> all interfaces. That could make life interesting since the firewall
> probably doesn't stop appletalk requests.)

Well, the thing is, that the service is mostly there, but will vanish
randomly for 1 second out of a hundred(or some like scenario), outside of
that, everything works peachy...following is the atalkd.conf..

========
#eth2 is the interface with the AppleTalk Seeding Router, so just
#get the settings from that network
eth2 -phase 2 -net 1-199 -addr 96.171 -zone "EtherTalk"

#eth1 will have to be set up better when I actually know whats going on
eth1 -seed -phase 2 -net 200-299 -addr 200.171 -zone "EtherTalk"
========

I'm sure the issue is a configuration one, so once I learn a certain amount
of the issues involved, I should have little difficulty, but right now I'm
at the bottom of the learning curve...

Thanks in advance for your help...


>
> I hope this makes some kind of sense. I'm going off of empirical data, so
> some of this may not be quite accurate.
>
> Pacem in Terris / Mir / Shanti / Salaam / Heiwa
> Kevin R. Bullock
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tclug-list-unsubscribe@mn-linux.org
> For additional commands, e-mail: tclug-list-help@mn-linux.org
>
>