AppleShare Client for Windows: AARP Issue

On a Windows client, when AppleTalk is initializing, a response to the first AARP (AppleTalk Address Resolution Protocol) Probe packet causes the stack to transmit another AARP Probe packet with a different tentative node address. If this second probe packet receives a response, the Windows stack continues to transmit AARP Probe packets with this same tentative node address. Is there a way to workaround this?
This problem will be addressed in the next release of the AppleShare Client for Windows software. As of this writing, there is no known date when this software will be available.

In the meantime, a workaround is to manually edit the AppleTalk node parameter in the SYSTEM.INI file. This address is under the [AppleTalk] heading, as can be seen in the following example:

[APPLETALK]
NODE=74

Below is a brief description of how dynamic address assignment works:

Each protocol stack in a given node must have a protocol address. This address is usually assigned when the stack is initialized. AARP is used at AppleTalk startup time to find a unique node ID on the network. AARP must then make sure that the address it selects is not being used by another node on the data link. It does so by using the data link to broadcast a number of AARP Probe packets, which contain the tentative protocol address. When a node's AARP receives a Probe packet corresponding to one of its protocol stacks, it examines the protocol address of that stack. If the Probe's tentative protocol address matches the receiving node's address, AARP sends back an AARP Response packet to the probing node.

If the probing node receives an AARP Response packet, then the tentative protocol address is already in use and the node must pick a new tentative address and repeat the probing process.
Published Date: Feb 19, 2012