mruddick
asked on
How do I make ARP cache age in 30 seconds?
How can I get an ARP cache to age in, say, 30 seconds. What I've got is the following:
A device with a given IP, say IP1, has a MAC address, say MAC1. During a short time interval, this device gets a new MAC address, MAC2. While IP1 has MAC1, it does a tftp transfer of a file from the tftp server. After IP1 gets MAC2, it tries to do another tftp, but tftp times out since the tftp server still sees MAC1 mapped to IP1.
I can manually intervene and do an "arp -d IP1" to clear the ARP entry, and then try the tftp transfer again with IP1+MAC2, which updates the ARP cache, and everything's fine.
Anyone have good ideas how to manage this without manual intervention?
What would happen if something were running on the tftp server to periodically clear the ARP entry for IP1, and this entry got cleared DURING a tftp transfer? Would it barf completely and stop, or just recover with a new ARP and be basically invisible?
A device with a given IP, say IP1, has a MAC address, say MAC1. During a short time interval, this device gets a new MAC address, MAC2. While IP1 has MAC1, it does a tftp transfer of a file from the tftp server. After IP1 gets MAC2, it tries to do another tftp, but tftp times out since the tftp server still sees MAC1 mapped to IP1.
I can manually intervene and do an "arp -d IP1" to clear the ARP entry, and then try the tftp transfer again with IP1+MAC2, which updates the ARP cache, and everything's fine.
Anyone have good ideas how to manage this without manual intervention?
What would happen if something were running on the tftp server to periodically clear the ARP entry for IP1, and this entry got cleared DURING a tftp transfer? Would it barf completely and stop, or just recover with a new ARP and be basically invisible?
ASKER
Jyoungman -
Yes, changing MACs seems like a strange thing to do, but it's in a product test environment, so it's not like it's the only *weird* thing I'm doing to the product. I'm trying to automate some testing tasks, but was having trouble with this particular bit.
Yes, changing MACs seems like a strange thing to do, but it's in a product test environment, so it's not like it's the only *weird* thing I'm doing to the product. I'm trying to automate some testing tasks, but was having trouble with this particular bit.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The MAC of a LAN-machine can be found using the function GetMacAddresses(const Machine: string; const Addresses: TStrings): Integer; found in the JEDI Code Library (JCL). This can be fetched from http://www.delphi-jedi.org. It is free, it works and it doesn't spawn external processes to resolve the MAC.
What it exactly does, I don't know, but it works :o)
Hope any of you can use it. Enjoy :)
What it exactly does, I don't know, but it works :o)
Hope any of you can use it. Enjoy :)
the TFTP requestor. Most will work fine.
However, when a device changes its *IP* address, it issues a "gratuitous ARP" packet, saying
IP1 is-at MAC1
This is how you detect IP address clashes. So if you can get the device which is changing its MAC address to issue a gratuitous ARP when its MAC changes, everything should work seamlessly.
Failing that, depending again on the TCPIP implementation of the TFTPing device, you may be able to put the interface in promiscuous mode and so catch packets intended for IP1 no matter if they're sent to MAC1 or MAC2.
This often won't work because ethernet drivers check that the packet sent to them really is directed at them -- in this way they can support IP multicast when the ethernet card has no packet-filtering logic at all - they just put the interface into promisc mode and do the checks in software.
Can I ask *why* you're changing MAC?