Subject: Re: Some Minor Troubles w/netatalk 1.5pre3
From: Tara Piorkowski (tara@vilaj.com)
Date: Mon Jan 08 2001 - 23:30:38 EST
on 1/6/01 8:15 AM, Tom Watson at tsw@johana.com wrote:
> 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,
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
This archive was generated by hypermail 2b28 : Sun Oct 14 2001 - 03:04:30 EDT