Subject: Re: [netatalk-admins] official version of netatalk

From: Harry Zink <[email-masked]>
Date: Mon, 4 Jan 1999 08:40:29 -0800

>Since the updated version is
>now the only working one, it would be less confusing to end users to make
>it official.

Brilliant suggestion, albeit it's not necessary in this context to have a 
'more' or 'less' official version, as long as it is well communicated 
which version works best.

Furthermore, there might be various political reasons that might preclude 
umich from incorporating asun's work into the 'official' distribution.

So, that makes the 'official' version less official, and the non-official 
more official, by virtue of functionality and actually being able to work.

Weird, sure, and possibly confusing, but, hey, the answers are out there 
(actually, it would be nice if a link to Adrian's version could be 
displayed more prominently on the umich site, and a more noticeable note 
were placed there to indicate the functionality issues with the new 
Kernel, and where to get a working implementation.

Harry

---

From: Yuji Shinozaki <[email-masked]>
Date: Mon, 4 Jan 1999 13:06:00 -0500 (EST)

General questions:

Is there a way to examine netatalk-asun2.1.1's ZIT (zone information
table)? 

What NBP debugging info can I get out of atalkd (and how)?

Is there detailed debugging info one can get to?

Is there a suggested Ethertalk packet analysis program (preferably UNIX
based) to aid in debugging?

Specific problem:

We have recently "isolated" a part of our Ethertalk network from the
campus network using Cabletron SecureFast technology on a central switch,
which is supposed to filter at the network layer (DDP), although I am
suspicious that it is actually filtering at the transport layer
(RTMP,AEP,ATP,NBP). 

In this newly isolated network, we set up netatalk on a Sun to do seed
routing using a net range of 0-5 with two zones.  However, we find that HP
LJ5M's have real trouble "adopting" the new zones, even after a "factory
hard reset".  After a hard reset, the HPLJ5's do not adopt any of one of
the zones: the will printers report their zone as blank, and they will
appear in every zone.  Even more mysteriously, they will eventually
re-adopt their *OLD* zone name (the default zone that they used on the
campus network before we "isolated" ourselves.) and the only way to make
them appear in ANY zone is to create a zone with same name as this old
zone(!).

I am suspicious that there is some incompatibility between the HPLJ5m
appletalk protocol stack and the netatalk atalkd (at least in regard to
ZIP). Otherwise why wouldn't they adopt the new default zones?  If I
switch the same printers to a network behind a cisco router that we have
access to, they immediately adopt the default zone for the port on the
cisco -- no problems.

I am also suspicious that some NBP packets (specifically GetNetInfo and
GetNetInfoReply) are somewhow "leaking" through the SecureFast block on
the central switch that connects us to the rest of the network, but I need
the tools to verify/diagnose this.

Any help welcome.

yuji
----
Yuji Shinozaki		        Systems Administrator
[email-masked]	        Dept of Physics and Astronomy
http://www.physics.unc.edu      Univ. of North Carolina - CH
(919)962-7214 (voice)           CB 3255 Philips Hall
(919)962-0480 (fax)	        Chapel Hill, NC  27599

---

From: Andrew McNabb <[email-masked]>
Date: Mon, 4 Jan 1999 12:06:03 -0600 (CST)

Right now it's a small link in the patches page.  The version that people
see and will try out will not be functional under 2.2.  I think that it
would be important to make this information very noticeable.

> Kernel, and where to get a working implementation.

----------------------------------------------
                Andrew McNabb
             Argus Systems Group
          [email-masked]
----------------------------------------------