Mapping between IP (or ethernet) and Appletalk addresses
Tom Anderson
At work, we have an ethernet, and almost all the machines are Macs. All
the machines (except the few PCs) have all three of ethernet, IP and
Appletalk addreses, and names, where appropriate (many also have SMB or
whatever names, but that's another story).
I'd like to be able to map between all three (or even four) kinds of
addresses. So far, i can work with ethernet and internet addresses:
'nslookup' (and the gethostbyname/gethostbyaddr library routines) let me
map between internet names to addresses, and 'arp -a' (are there library
calls for this?) lets me map between internet names/addresses and ethernet
addresses, provided they're on the local network (which they are).
However, what i can't figure out is how to get between appletalk and
ethernet/internet addresses. For starters, i'm not even sure what level i
should be looking at - i know appletalk can run over ethernet (ethertalk,
right?), without using IP, but ISTR reading that it can also run over IP
(does that have a name? intertalk? that sounds terrible). Which is likely
to be happening on my network? Either way, how can i map between appletalk
and underlying network addresses? 'atlookup' lets me map between appletalk
names and appletalk addresses, but i can't see any way to get from there
to ethernet addresses, or vice versa.
Any ideas? A command-line tool that's already on my system would be ideal,
but a library routine would be fine, since i've no problem writing some
code to access it (although Carbon would be better than Cocoa, since by
objective C is non-existant!).
Thanks,
tom
--
Only men's minds could have mapped into abstraction such a territory
Clark Martin
Tom Anderson <tw...@urchin.earth.li> wrote:
> Hi,
>
> At work, we have an ethernet, and almost all the machines are Macs. All
> the machines (except the few PCs) have all three of ethernet, IP and
> Appletalk addreses, and names, where appropriate (many also have SMB or
> whatever names, but that's another story).
>
> I'd like to be able to map between all three (or even four) kinds of
> addresses. So far, i can work with ethernet and internet addresses:
> 'nslookup' (and the gethostbyname/gethostbyaddr library routines) let me
> map between internet names to addresses, and 'arp -a' (are there library
> calls for this?) lets me map between internet names/addresses and ethernet
> addresses, provided they're on the local network (which they are).
>
> However, what i can't figure out is how to get between appletalk and
> ethernet/internet addresses. For starters, i'm not even sure what level i
> should be looking at - i know appletalk can run over ethernet (ethertalk,
> right?), without using IP, but ISTR reading that it can also run over IP
> (does that have a name? intertalk? that sounds terrible). Which is likely
> to be happening on my network? Either way, how can i map between appletalk
> and underlying network addresses? 'atlookup' lets me map between appletalk
> names and appletalk addresses, but i can't see any way to get from there
> to ethernet addresses, or vice versa.
>
> Any ideas? A command-line tool that's already on my system would be ideal,
> but a library routine would be fine, since. i've no problem writing some
> code to access it (although Carbon would be better than Cocoa, since by
> objective C is non-existant!).
Have you checked out the CLI tools? /usr/atlookup and /usr/atstatus.
atlookup lists the AT addresses and sockets and names for each service.
atstatus gives a response but it seems like it's meant for
laserprinters, it never gave a response for anything I tried. And there
is appleping but that doesn't seem to work either.
I have to thank you, in checking this out I discovered that my wireless
router passes AppleTalk.
--
Clark Martin
Redwood City, CA, USA Macintosh / Internet Consulting
"I'm a designated driver on the Information Super Highway"
Tom Anderson
I have looked at those - atstatus is indeed a printer management tool,
appleping is a ping tool, but doesn't do anything else, and, as i mention
in my post, i've looked at atlookup, which looked promising, but doesn't
seem to have anything to say about the underlying addresses.
> I have to thank you, in checking this out I discovered that my wireless
> router passes AppleTalk.
No problem!
tom
--
Osteoclasts = monsters from the DEEP -- Andrew
Tom Stiller
AppleTalk and IP are separate protocols; the fact that they can share
the same physical layer does not make them interdependent.
The 'atlookup' command will return the AppleTalk nodename as assigned in
the Sharing system preference panel (the part before the colon) but
there is no requirement that that be the same as the host name.
Further, the host name is not dependent on the IP address; either can be
changed independent of the other.
--
Tom Stiller
PGP fingerprint = 5108 DDB2 9761 EDE5 E7E3
7BDA 71ED 6496 99C0 C7CF
Tom Anderson
Right. That's more or less what i thought - i had this vague idea there
was also an appletalk-over-IP mechanism, but i must have been mistaken.
> The 'atlookup' command will return the AppleTalk nodename as assigned in
> the Sharing system preference panel (the part before the colon) but
> there is no requirement that that be the same as the host name.
By 'host name', you mean the internet hostname, like
somecomputer.somedomain.net or whatever? If so, then no, of course there's
no such requirement, since IP and appletalk are, as you say, separate
network-layer protocols. I know that - that's why i'm looking for a way to
map between internet and appletalk names.
> Further, the host name is not dependent on the IP address; either can be
> changed independent of the other.
True, but at any point in time, there's a definite association between
them: in general, a potentially complicated association, with multiple
addresses per name and multiple names per address possible, but typically,
a simple 1:1 association. In most environments, that association is stable
over a timescale of hours, and often much longer (my machine has had the
same address and name for as long as i've worked here, which is getting on
for two years).
Therefore, it's meaningful to think of both the internet address and name
as identifying a particular computer at a particular point in time, and
since that computer also has an appletalk name and address, to ask what
the appletalk identity of a computer with a particular internet identity
is.
tom
--
NOW ALL ASS-KICKING UNTIL THE END
Tom Stiller
> i had this vague idea there was also an appletalk-over-IP mechanism,
> but i must have been mistaken.
You weren't mistaken, but encapsulating AppleTalk messages within IP
wrappers doesn't make the two protocols interdependent. In this case IP
is just the delivery mechanism, replacing the LocalTalk physical layer.
> Therefore, it's meaningful to think of both the internet address and name
> as identifying a particular computer at a particular point in time, and
> since that computer also has an appletalk name and address, to ask what
> the appletalk identity of a computer with a particular internet identity
> is.
While it's true that all these identities exist at once, they are
independent and it does not follow that one can be derived from another.
As I recall, AppleTalk node IDs are assigned when the device powers up.
The protocol includes a weak attempt to preserve the ID over startups,
but it is not guaranteed; sort of like assigning IP addresses via a DHCP
server.
Hostnames are a little different; they are associated with an IP address
through a table which may be maintained on either a server or replicated
among the nodes of a network.
Clark Martin
> On Fri, 13 Jan 2006, Tom Stiller wrote:
>
> > AppleTalk and IP are separate protocols; the fact that they can share
> > the same physical layer does not make them interdependent.
>
> Right. That's more or less what i thought - i had this vague idea there
> was also an appletalk-over-IP mechanism, but i must have been mistaken.
There is an AppleTalk over IP protocol but it's rather obscure. An
Australian university produced software to route it (as well as an
Appletalk router). I believe that the Kinetics Fast Path and maybe the
Cayman Gatorbox also handled it.
I did setup a test network once but never really used it.
Ignatios Souvatzis
On 2006-01-13, Tom Anderson wrote:
[...]
> Therefore, it's meaningful to think of both the internet address and name
> as identifying a particular computer at a particular point in time, and
> since that computer also has an appletalk name and address, to ask what
> the appletalk identity of a computer with a particular internet identity
> is.
If you want this, you'll have to check the ARP and the Appletalk ARP
tables - but those are caches on your machine, and only filled if your
machine is using Appletalk as well as IP to the target. For IPv6, add
"ndp -a" to the mix.
After that, you can use nbplkup =:= to associate a name to the
Appletalk address, and "host" to associate a name to the IPv4 and
IPv6 addresses, if desired.
Regards,
Ignatios Souvatzis
--
seal your e-mail: http://www.gnupg.org/
Tom Anderson
> I've set f'up to comp.protocols.appletalk, where this probably belongs.
Fair enough.
> On 2006-01-13, Tom Anderson wrote:
>
> [...]
>
>> Therefore, it's meaningful to think of both the internet address and
>> name as identifying a particular computer at a particular point in
>> time, and since that computer also has an appletalk name and address,
>> to ask what the appletalk identity of a computer with a particular
>> internet identity is.
>
> If you want this, you'll have to check the ARP and the Appletalk ARP
> tables - but those are caches on your machine, and only filled if your
> machine is using Appletalk as well as IP to the target. For IPv6, add
> "ndp -a" to the mix.
Right. This is more or less what i thought. I can force addresses into the
cache by some means or other (eg use atlookup to get a list of addresses,
then appleping to access each in turn, which will bring the
appletalk-ethernet mapping in), then look at the cache. The question is,
how do i look at the cache? I can see the internet ARP cache with 'arp
-a', but i can't find an appletalk AARP equivalent. Is there one?
Since appletalk lives in the kernel, and the kernel (in the form of
Darwin) is open source, i've been able to track down the AARP cache (which
is called the Address Map Table in appletalk lingo) to netat/ddp_aarp.c,
and its aarp_table variable; the structure of this table, and macros to
access it, are defined in netat/at_aarp.h. However, this doesn't help me
much, since these are internal kernel structures, and aren't, AFAICT,
exposed to userland (ie me) in any way! I'd really like to find a way of
doing this that doesn't involve writing a kernel extension ...
> After that, you can use nbplkup =:= to associate a name to the Appletalk
> address, and "host" to associate a name to the IPv4 and IPv6 addresses,
> if desired.
I don't seem to have a nbplkup on my machine - but i'm happy with atlookup
for the name/address bit.
tom
--
""when i go to sleep, i dream "Wow. What a cool period of ulness."" --
TWIC, ox.clubs.ousfg -- William, ox.clubs.ousfg
Ignatios Souvatzis
This was on NetBSD with the netatalk package installed. We don't have a
userland tool to query the appletalk arp cache, either, afaict.
Regards,
-is
Tom Anderson
Ah, right.
> We don't have a userland tool to query the appletalk arp cache, either,
> afaict.
Curses!
Anyway, thanks a lot for reassuring me i'm not insane / barking up the
wrong tree / missing something obvious. Next stop is a Darwin mailing list
for one final check, then to figure out how to write a kernel extension to
do this ...
tom
--
I gotta handful of vertebrae and a headful of mad! -- The Doomguy
Ignatios Souvatzis
I checked --- on NetBSD it's not as easy as rewriting arp.c, because the
Appletalk ARP cache is implemented old-style (with a seperate hash table)
instead of integrated into the routing table :-( So either one or the other
has to be rewritten.
Tom Anderson
> On 2006-01-26, Tom Anderson wrote:
>> On Wed, 25 Jan 2006, Ignatios Souvatzis wrote:
>>
>>> On 2006-01-25, Tom Anderson wrote:
>>>> On Tue, 24 Jan 2006, Ignatios Souvatzis wrote:
>>>>
>>>>> On 2006-01-13, Tom Anderson wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>>> Therefore, it's meaningful to think of both the internet address
>>>>>> and name as identifying a particular computer at a particular point
>>>>>> in time, and since that computer also has an appletalk name and
>>>>>> address, to ask what the appletalk identity of a computer with a
>>>>>> particular internet identity is.
>>>>>
>>>>> If you want this, you'll have to check the ARP and the Appletalk ARP
>>>>> tables - but those are caches on your machine, and only filled if
>>>>> your machine is using Appletalk as well as IP to the target. For
>>>>> IPv6, add "ndp -a" to the mix. After that, you can use nbplkup =:=
>>>>> to associate a name to the Appletalk address, and "host" to
>>>>> associate a name to the IPv4 and IPv6 addresses, if desired.
>>>
>>> This was on NetBSD with the netatalk package installed. We don't have
>>> a userland tool to query the appletalk arp cache, either, afaict.
>>
>> Anyway, thanks a lot for reassuring me i'm not insane / barking up the
>> wrong tree / missing something obvious. Next stop is a Darwin mailing
>> list for one final check, then to figure out how to write a kernel
>> extension to do this ...
>
> I checked --- on NetBSD it's not as easy as rewriting arp.c, because the
> Appletalk ARP cache is implemented old-style (with a seperate hash
> table) instead of integrated into the routing table :-( So either one or
> the other has to be rewritten.
On OS X (ie Darwin), it's not too bad - the appletalk stuff is separate
from the IP stuff, but it's all accessible once you're inside the kernel,
so it would only take a fairly simple kernel extension to do it. In fact,
the hardest bit is doing the communication with userland, which on OS X is
done with an obscure variety of socket. I'm hoping to have a crack at it
at the weekend!
tom
--
Not all legislation can be eye-catching, and it is important that the
desire to achieve the headlines does not mean that small but useful
measures are crowded out of the legislative programme. -- Select Committee
on Transport