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

On Thu, 4 Jun 1998, David Brownlee wrote:

> 	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 :)

> -				    (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))

> >                            __(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.

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

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

julian