[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Issues with Netatalk and MACE
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.
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
Main Index |
Thread Index |