Subject: Re: Some Minor Troubles w/netatalk 1.5pre3

From: "Tom Watson" <[email-masked]>
Date: Sat, 06 Jan 2001 05:15:53 -0800

On Fri, 5 Jan 2001 20:06:30 -0500 (EST), [email-masked] wrote:
> on 1/3/01 8:26 AM, Chris G. Sellers at [email-masked] wrote:
> 

<<<deletia>>>

> 
> Is the message, "eth0: multicast may not work correctly." a standard message
> or is the daemon identifying a situation that is specific to a problemmatic
> environment?
> 
> > The mulicast thing may be your culprit.
> 
> That's what I think, too, though I haven't been able to definitively
> conclude this. Similarly, I haven't found a workaround.
> 

Having hacked a EtherNet driver (the SEEQ8005 one to be exact), I noted a
few things.  Some drivers do not implement multicast (at the MAC - Machine
Access, Level 2) correctly.  Some do not implement it at all.  AppleTalk
uses multicast address (ethernet) of 09:00:07:FF:FF:FF.  These addresses have
a '1' in the LOW order bit of the first byte of the ethernet address.
AppleTalk uses this multicast address to broadcast packets (name lookups
are but just one) to all other AppleTalk nodes.  This allows non-AppleTalk
nodes to simply ignore the packets.  In AppleTalk phase 1, the ethernet
broadcast address of 'FF:FF:FF:FF:FF:FF' (all ones) was used.

The logic in some chips allows addresses to be selectively received so
that upper layers of software don't need to bother with packets that
have no meaning.  If the hardware multicast logic in the driver is not
complete, some drivers will just put the receiver in "promiscous" (accept
all packets) mode, which can unnecessarly burden the software in the
lower levels.  Some drivers just chose to ignore the need for multicast
which is a BIG mistake, and can lead to AppleTalk NOT working.

The other thing that happens is that there is ONE kernel variable that
seems to control both hardware (ISO level 2) and IP (ISO level 3)
multicasting.  Portions of the code that do the IP multicasting are at
the protocol level (using IP addresses above 224.0.0.0) have NOTHING to do
with the hardware multicasting, but they seem to share a variable.  Changing
it (The variable is CONFIG_IP_MULTICAST) allows the code to ALSO do the
hardware multicast, which is needed for AppleTalk.  At least this is
how MY kernel is setup (ymmv).

I may have the group hardware address wrong for AppleTalk, but the idea
is similar.  Hopefully this assists someone.  It may just be a simple
matter of configuring the kernel.  I just checked, the group address
of '09:00:07:FF:FF:FF' is the proper address for AppleTalk phase 2
broadcast.  Good luck!!

References:
/usr/src/linux/net/appletalk/aarp.c (location varies, but close enough).

-- 
Tom Watson         Generic short signature
[email-masked]     (I'm at home now)

---

From: Tara Piorkowski <[email-masked]>
Date: Mon, 08 Jan 2001 23:30:38 -0500

> /usr/src/linux/net/appletalk/aarp.c (location varies, but close enough).

Tom,

Thanks for your informative response. I played around with the kernel
configuration a bit, to no avail. Frustrated and needing to do other things,
I slapped a 3Com 3c509 card I had lying around in the machine, recompiled an
appropriate kernel, restarted and everything came up as I expected it to.
So, either there's a problem in the TLAN driver not supporting multicast or
there's a similar problem with the Proliant's Netelligent card. Regardless,
the money saved in time will easily cover the cost of the 3Com card.
Honestly, I'm a little surprised as I figured there are tons of Proliants
out there and some of them have to be running netatalk. Nonetheless, I
appreciate the help you and others provided. Thanks.

Tara

-- 
Tara Piorkowski
Network Administrator, vilaj.com