Re: Issues with Netatalk and MACE

[David Riley <fraveydank%gmail.com@localhost>]

Well, Appletalk is a little more complicated than that, since it has a naming 
platform build on top of it (NBP, which was the basis for IP Zeroconf/Bonjour 
which does the same thing using DNS).  Here's what the NBP "client" (on a Mac 
it would be the system, but in Unix world everything but DDP (the equivalent to 
IP) and AARP (equivalent to ARP) is done in userland) does to resolve or 
register a name to an Appletalk address:

- On a single network, the client just sends out a broadcast to look up a name. 
 Quite simple, and basically the way IP Zeroconf handles it.  If someone sees 
the request and matches it, it sends the response directly back to the receiver 
(this is very much like ARP as well).

- On a routed network, the client sends a broadcast request (BrRq) to the 
router, which then sends FwdRq packets to the other routers which are 
responsible for the "Zones" in the network (another naming concept).  All the 
routers then turn the FwdRq packets into broadcast LkUp requests as in the 
single-network example and forward any responses to the original requester.

The problem is, Netatalk is hard-coded to assume the latter method, which means 
that when it is both the router ant the client, it is trying to talk to itself. 
 What I'm observing is that the AARP packet that's getting sent out by me 
trying to find me is not getting a response, thus the NBP query to probe 
whether a given name is already taken can't be sent out.

Think of it this way: you're running a DNS server on your machine (let's call 
it 192.168.1.1).  You want to run a service with a given DNS name, but you want 
to query the DNS server to see if the name is taken yet, so you need to talk to 
yourself.  So you send an ARP request to 192.168.1.1 (from 192.168.1.1) to 
resolve the Ethernet address of the DNS server (yourself), then you send a DNS 
request to yourself after you've figured it out.  This works under IP, because 
there seems to be some short-circuiting the IP stack when talking to yourself, 
but Appletalk doesn't seem to be acting that way.

tcpdump shows broadcast AARP requests when my machine is trying to find itself. 
 I can see them in tcpdump both on external machines and the machine in 
question, but looking through the network code, it's not because it's actually 
being received; I only see the outgoing packet because if_ethersubr.c copies 
outgoing packets to the bpf device for monitoring.

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.


- Dave


On Jul 9, 2010, at 3:15 PM, Dennis Ferguson wrote:

> 
> On 9 Jul 2010, at 10:48 , David Riley wrote:
>> Digging a little deeper, I see on the network that I'm sending out multicast 
>> AARP requests for my own address (let's call it 42.182 for now).  "tcpdump 
>> -nvvvXe aarp" shows that I'm asking who-has 42.182 from 42.182.  Sadly, 
>> though, my own machine doesn't see those requests (MACE doesn't get its 
>> outgoing broadcasts/multicasts looped back, it seems).  If I instrument 
>> sys/arch/macppc/dev/am79c950.c to print out every MAC address that comes 
>> across in the Rx interrupt, I never see that frame.
> 
> I know very little about Appletalk, but I'd be surprised if this
> were a problem at all.  Your machine doesn't need to receive arp
> requests it sends for its own address, it already knows everything
> that it could possibly tell itself.  The purpose of those requests
> is most likely to detect other hosts on the network using the same
> address, and the fact that it isn't getting any response is good since
> it indicates that there are no address conflicts.  I think IP ARP does
> the same thing for the same reason, though it only sends requests like
> that when the address is first configured rather than continuously.
> 
> Your problem is likely elsewhere.  Does tcpdump show traffic from
> the machines you are trying to talk to?
> 
> Dennis Ferguson