Re: Issues with Netatalk and MACE

[Donald Lee <MacPPC2%caution.icompute.com@localhost>]

>On 9 Jul 2010, at 13:04 , David Riley wrote:
>> I never see a copy of the NBP packet go out over the network, because the 
>> Appletalk layer throws it out as soon as it's determined that it can't 
>> resolve the address with AARP.  In a sense, you're right; my machine is 
>> querying to see if the NBP name is in use.  It works fine for finding its 
>> own Appletalk address, but the probing for the name is failing.
>
>While NBP might be complicated, AARP is just ARP for Appletalk and is
>exceedingly simple.  The only useful function that ARPing for your
>own address could have is the side effect of telling others that you
>are using that address.  If it isn't doing that, and is really, truly
>trying to discover its own MAC address by sending packets, then it is
>broken and you need to figure out why it isn't recognizing its own
>address, and is instead sending AARP packets for it, in the first place.
>
>Note that the first thing at_aarpinput() does is this
>
>        /* Check to see if from my hardware address */
>        if (!memcmp(ea->aarp_sha, CLLADDR(ifp->if_sadl), 
> sizeof(ea->aarp_sha))) {
>                m_freem(m);
>                return;
>        }
>
>so getting the ethernet device driver to loop a copy of the packet back
>into the box won't help since AARP will drop packets from itself anyway.
>Which makes perfect sense: if it knew the answer it wouldn't send the
>query in the first place, so if receives its own query that is clearly
>something it won't know the answer for.
>
>I think the box inherently needs to be able to recognize its own addresses
>to function, which means it shouldn't be sending packets to itself out of
>a wire let alone arping for its own MAC address.  What does the routing
>table entry for the local address look like?
>
>Dennis Ferguson

If I may chime in from dim memory......

I *think* the MACE chip was the one that had its MAC address reverse-endian-ed
in the HW, requiring SW workaround.

This may be wrong, but is worth checking.....

-dgl-