Subject: Re: problems with zones >255 under NetBSD 1.3.1
To: None <netatalk-admins@umich.edu, port-mac68k@NetBSD.ORG,>
From: David Brownlee <abs@anim.dreamworks.com>
List: port-mac68k
Date: 06/04/1998 23:01:04
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 -=-
On Fri, 8 May 1998, David Brownlee wrote:
> 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" -=-
>
>
>
>