Subject: [netatalk-admins] problems with zones >255 under NetBSD 1.3.1

From: David Brownlee <[email-masked]>
Date: Fri, 8 May 1998 17:05:36 -0700 (PDT)

We have a NetBSD/i386 1.3.1 box running the netatalk code from
        NetBSD.org (1.4b2) as a router between two groups here.

        We are seeing a problem where nbplkup (and the mac chooser) on
	zones with cable ranges >255 fail to pass through the netatalk
	box.

	GroupA						GroupB
	^^^^^^						^^^^^^
        Zones 200-250              +--------+           Zones 2-199
                           __(de0)_|netatalk|_(de1)__         251-64000
                                   | router |
                                   +--------+

            de0 -phase 2 -net 202 -addr 202.147 -zone "LKS_Anim_DC"
            de1 -phase 2 -net 93 -addr 93.151 -zone "Animation"
   
	All machines can see all zones and cable ranges, but machines
	in GroupA cannot see the contents of any zones in GroupB with
	a cable range of >255. Machines in GroupB can see the contents
	of all zones. netatalk router can see contents of all zones.

	From running tcpdump on the netatalk router it appears that the
	lookups for zones >255 (where the first octect is non-zero) are
	not passed through.

	The impact to the users is that GroupA cannot see most of the
	resources in GroupB, and tell us so, loudly :)

	It looks pretty much like a problem in the kernel netatalk code
	(atalkd is not involved in the nbplkup lookups).

	Does anyone have any idea of where to start looking on this, or
	even a fix? 

		Thanks
----------------------------------------

Trace from successful lookup:

de0 (client side)
^^^^^^^^^^^^^^^^^
0.202.198.nis > 0.104.0.nis: nbp-0x41  0 (23)
0.104.32.nis > 0.202.198.128: nbp-reply 0: "Router/DW/ANIMATIO[|atalk] 4
0.105.40.nis > 0.202.198.128: nbp-reply 0: "Admin:TB2Pro.402[|atalk](0)
0.104.69.nis > 0.202.198.128: nbp-reply 0: "DreamWorks Server[|atalk](0) 247
0.104.78.nis > 0.202.198.128: nbp-reply 0: "Greg:NU[|atalk](0) 250
0.104.130.nis > 0.202.198.128: nbp-reply 0: "Victor:Fil[|atalk](0) 251

de0 (remote side)
^^^^^^^^^^^^^^^^^
0.202.198.nis > 0.104.0.nis: nbp-0x41  0 (15)
0.104.32.nis > 0.202.198.128: nbp-reply 0: "Router/DW/ANIMATIO[|atalk] 4
0.105.40.nis > 0.202.198.128: nbp-reply 0: "Admin:TB2Pro.402[|atalk](0)
0.104.69.nis > 0.202.198.128: nbp-reply 0: "DreamWorks Server[|atalk](0) 247
0.104.78.nis > 0.202.198.128: nbp-reply 0: "Greg:NU[|atalk](0) 250
0.104.130.nis > 0.202.198.128: nbp-reply 0: "Victor:Fil[|atalk](0) 251

Trace from failed lookup:

de0 (client side)
^^^^^^^^^^^^^^^^^
00:34:50.565912 0.202.198.nis > 117.69.0.nis: nbp-0x41  0 (23)
00:34:50.565939 0.202.198.nis > 1.45.0.nis: nbp-0x41  0 (23)

de1 (remote side)
^^^^^^^^^^^^^^^^^
(nothing)

                David/absolute

         -=-  "There will not be a send-off, a funeral or mass"  -=-

---

From: David Brownlee <[email-masked]>
Date: Thu, 4 Jun 1998 23:01:04 -0700 (PDT)

Following up on my previous post on this. I don't know if this
	problem is present in other netatalk implementations - if so, then
	hopefully this patch will be of use to other people. I'm
	submitting it as a PR against NetBSD now, so it should be in
	-current RSN.

	(The problem was two unnecessary ntohs() calls - it would have
	worked fine on a big-endian CPU, but not on the pentium we had to
	use here... tsk, give me a mac :)

--- ddp_input.c.orig	Thu Jun  4 19:00:27 1998
+++ ddp_input.c	Thu Jun  4 22:41:23 1998
@@ -52,6 +52,11 @@
 void            ddp_input __P((struct mbuf *, struct ifnet *,
     struct elaphdr *, int));
 
+#if 0
+static void	m_printm __P((struct mbuf *));
+static void	bprint __P((char *data, int len));
+#endif
+
 /*
  * Could probably merge these two code segments a little better...
  */
@@ -224,8 +229,8 @@
 				     ntohs(aa->aa_firstnet) ||
 				     ntohs(to.sat_addr.s_net) >
 				     ntohs(aa->aa_lastnet)) &&
-				    (ntohs(to.sat_addr.s_net) < ntohs(0xff00) ||
-				     ntohs(to.sat_addr.s_net) > ntohs(0xfffe)))
+				    (ntohs(to.sat_addr.s_net) < 0xff00 ||
+				     ntohs(to.sat_addr.s_net) > 0xfffe))
 					continue;
 
 				if (to.sat_addr.s_node !=
@@ -333,7 +338,6 @@
 
 #define BPXLEN	48
 #define BPALEN	16
-#include <ctype.h>
 char            hexdig[] = "0123456789ABCDEF";
 
 static void

		David/absolute

                  -=-  Trust is a non-renewable resource  -=-

---

From: Julian Elischer <[email-masked]>
Date: Thu, 4 Jun 1998 23:38:43 -0700 (PDT)

I think this came from my FreeBSD implementation.
I just looked. It's wrong there..
I'll commit th e fix there right now

julian

> >                            __(de0)_|netatalk|_(de1)__         251-64000

You are badly confusing net-ranges and zones..
The two concepts are othogonal, like IP addresses and DNS names.

> > 	lookups for zones >255 (where the first octect is non-zero) are

julian

---

From: [email-masked]
Date: Fri, 05 Jun 1998 10:25:27 -0400

> From:    David Brownlee <[email-masked]>

> submitting it as a PR against NetBSD now, so it should be in

The problem was present in the SunOS 4.x version, which is the basis of
all BSD implementations.  I've included your fix for SunOS 4, Julian's
handled FreeBSD, you're handling NetBSD.  The only one missing is
OpenBSD.

:wes