Subject: Re: Some Minor Troubles w/netatalk 1.5pre3
From: Tom Watson (tsw@johana.com)
Date: Sat Jan 06 2001 - 08:15:53 EST
On Fri, 5 Jan 2001 20:06:30 -0500 (EST), netatalk-admins@umich.edu wrote:
> on 1/3/01 8:26 AM, Chris G. Sellers at sellers@Oakland.edu 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 tsw@johana.com (I'm at home now)
This archive was generated by hypermail 2b28 : Sun Oct 14 2001 - 03:04:30 EDT