Subject: [netatalk-admins] zip ignoring gnireply

From: Danny Rice <[email-masked]>
Date: Thu, 14 Jan 1999 21:37:08 +0100 (CET)

Linux redhat 5.2

I get 100s of these messages each day, usually in clusters like:

Jan 13 09:47:10 siren atalkd[509]: zip gnireply from 44544.252 (eth0 b2)
Jan 13 09:47:10 siren atalkd[509]: zip gnireply from 44544.52 (eth0 b2)
Jan 13 09:47:10 siren atalkd[509]: zip gnireply from 44545.250 (eth0 b2)
Jan 13 09:47:10 siren atalkd[509]: zip gnireply from 44545.253 (eth0 b2)
Jan 13 09:47:10 siren atalkd[509]: zip ignoring gnireply
Jan 13 09:47:10 siren atalkd[509]: zip ignoring gnireply
Jan 13 09:47:10 siren atalkd[509]: zip ignoring gnireply
Jan 13 09:47:10 siren atalkd[509]: zip ignoring gnireply

What does it mean?  Is this a problem? What is zip?  Is 'zip' the zip
compression program?  Is it trying to talk to atalkd (locally?
remotely?).  If I uninstalled zip locally would these messages go away?
Would that hurt anything if I don't use zip for anything else?

Other zip messages I occasionally get are:

Jan 13 09:36:44 siren atalkd[509]: zip gnireply from 44544.252 (eth0 12)
Jan 13 09:36:44 siren atalkd[509]: zip_getnetinfo for eth0
Jan 13 09:36:45 siren atalkd[509]: zip_packet configured eth0 from 44544.252

Jan 13 09:36:53 siren atalkd[509]: zip skip reply 44544-44546 from 44544.52 (no query)
Jan 13 09:36:53 siren atalkd[509]: zip skip reply 44544-44546 from 44545.250 (no query)
Jan 13 09:36:53 siren atalkd[509]: zip skip reply 44544-44546 from 44545.253 (no query)

Thanks, Danny

---

From: Michael Han <[email-masked]>
Date: Thu, 14 Jan 1999 14:17:05 -0800

Previously...
>Would that hurt anything if I don't use zip for anything else?

ZIP is Zone Information Protocol. It's the AppleTalk protocol for
participating in a zoned AppleTalk network. I'm not completely sure,
based on the information and my level of knowledge, but I'd guess that
there's a misconfigured device somewhere that's providing information
that's making netatalk unhappy. Looks like the messages are in the
getnetreply function, and that the devices causing trouble are on
cable ranges 44544 and 44545.
-- 
[email-masked]
I will not trade pants with others
 - The collected wisdom of Bart Simpson

---

From: Yuji Shinozaki <[email-masked]>
Date: Thu, 14 Jan 1999 17:43:37 -0500 (EST)

> Would that hurt anything if I don't use zip for anything else?

ZIP in this context is Zone Information Protocol. And has nothing to do
with zip compression. ZIP (as you might well guess) pertains to
information about zones and available node numbers.  When an appletalk
node comes up it must either get the zone and node address information for
the first time or verify the info it already has.  It does this by sending
out an AARP (Appletalk Address Resoultion Protocol) packet and a ZIP
GetNetInfo (gni) packet to the Appletalk broadcast address, requesting
either information about the zone that it thinks it should be in, or a
request for information about the default zone. An Appletalk router picks
this up and sends a ZIP GetNetInfoReply (gnireply).  The router will
either send it directly to the nodes appletalk address or to the Appletalk
broadcast address (where all appletalk nodes listen) depending on whether
the node sent a ZIP a legitimate node address.  

Usually on a stable Appletalk network with well behaved nodes, you should
only have gni broadcasts (that everyone hears) only occasionally, when a
new host is introduced or somehow needs to change its information. 

I believe the "ignoring zip gnireply" is your netatalk host (a node) 
saying "hey I just got this gnireply on the appletalk broadcast address
and I didn't request one -- I will ignore it". 

The fact that you getting lots of these may be because you have lots of
mac nodes that are changing networks, or just coming online, or losing
their net info, or that are badly behaved (many old appletalk devices
suffer from a problem that can cause GNI storms like this).

Below, it looks like your netatalk host receives a gnireply that was
intended for it and configures itself (adjusts the net node number and
zone multicast address) appropriately.  Although I am not sure what the
"skip reply" means. 

I thought I was going to give you a short answer, but alas I didn't  ;-).

yuji
----

> Jan 13 09:36:53 siren atalkd[509]: zip skip reply 44544-44546 from 44545.253 (no query)

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: Albert Max Lai <[email-masked]>
Date: Thu, 14 Jan 1999 17:58:09 -0500 (EST)

If you are using the eepro100 driver, this is a sign that the multicast
filter is breaking. The multicast filter breaks at a limit greater than 3.
So, in your conf.modules add a line that says: 
      options eepro100 multicast_filter_limit=3
Due to this problem, I generated so much traffic on my network here on
campus to the point that the staff couldn't telnet into the hub to shut my
port down.

--
Albert Lai <[email-masked]>           1018D East Campus
Residential Computer Consultant           411 W. 116th St.
Columbia University                       New York, NY 10027
http://www.columbia.edu/~aml61            (212)853-4854