You are here: Home → Forum Home → The Mac Observer Forums → Mac Geek Gab Crew → Thread
Changing IP address without transmitting ARP collision detection packets
-
Kenneth Carey
- [ Ignore ]
I need to change my IP address either through the command line or through a C API without having the ARP address collision detection packets being transmitted.
I have tried using ifconfig -arp which appears to compelte suiccesfully - no ARP packets are transmitted. However, other network utilies stop functioning. For example - I am unable to ping other machines.
I have also tried using the ipconfig command. While this does change the IP address without breaking other network functions such as ping - there does not appear to be a way to prevent the ARP packets from being sent.
Does anyone know of a way to dymanically change my IP address without sending the ARP packets that does not break other network features?
Help is very much appreciated.
-
I’m not aware of the -arp argument, and it doesn’t appear in the man page near as I can tell. What does ‘ifconfig’ show after you’ve issued the command this way? Is it showing an IP address still assigned to that interface?
Signature
-Dave Hamilton / The Mac Observer / Mac Geek Gab / Dave on Twitter
When you find a big kettle of crazy, it’s best not to stir it. -
Kenneth Carey
- [ Ignore ]
The man page containing information related to the -arp option can be found on the ifconfig man page
I issue the following command:
sudo ifconfig en0 192.168.28.49 netmask 255.255.0.0 -arp upUsing wireshark I can see the -arp option works properly because there are no arp packets transmitted over the wire.
Then when I try to ping another machine on network I get the following error:
$ ping 192.168.5.10
PING 192.168.5.10 (192.168.5.10): 56 data bytes
ping: sendto: Operation not supported
ping: sendto: Operation not supported
ping: sendto: Operation not supportedIt is interesting to note that using wireshark I am able to see ping requests sent from other machines coming into this machine, but ping does not respond. It appears as though once the ifconfig command is issued my network connection can only handle incoming traffic.
I re-issue the ifconfig command to see the network settings:
$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
gif0: flags=8010 mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=89e3<UP,BROADCAST,SMART,RUNNING,NOARP,PROMISC,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.28.49 netmask 0xffff0000 broadcast 192.168.255.255
ether 00:23:df:a0:d2:22
media: autoselect (100baseTX <full-duplex,flow-control>) status: active
supported media: none autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,flow-control> 10baseT/UTP <full-duplex,hw-loopback> 100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX <full-duplex,flow-control> 100baseTX <full-duplex,hw-loopback> 1000baseT <full-duplex> 1000baseT <full-duplex,flow-control> 1000baseT <full-duplex,hw-loopback>
en1: flags=8823<UP,BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500
ether 00:23:6c:98:fe:f5
media: autoselect (<unknown type>) status: inactive
supported media: autoselect
fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078
lladdr 00:23:df:ff:fe:a0:d2:22
media: autoselect <full-duplex> status: inactive
supported media: autoselect <full-duplex>It is also interesting to note that if I let everything sit overnight and retry the ping command again in the morning - all appears to work properly.
[ Edited: 09 November 2009 11:42 AM by Kenneth Carey ]
Any help on how I can get this ifconfig command to work properly is greatly appreciated. -
Ah yes, of course. I was looking at the ipconfig man page, not ifconfig. Thanks.
And from what I know about ARP and the description in the man page, it seems to link IP address to MAC address. This likely means that though your computer knows its IP address is the new one (.28.49), your computers ARP cache has not yet been flushed of the old data, therefore the computer doesn’t know the link between its IP address and its MAC address. Overnight, the ARP cache expires and/or self-flushes, and boom, it picks it up and all is well.
I would try issuing an arp -a both before and after you issue your ifconfig command and see if anything changes (especially with regards to your computers entries for itself). My guess is that nothing will, because you have explicitly told ifconfig to ignore dealing with ARP.
Near as I can tell you can use the arp -d <hostname> command to selectively remove entries from the cache, or use arp -d -a to flush the entire cache. If this is the problem, I would guess that removing the incorrect entries (or all entries) would indeed solve it.
Signature
-Dave Hamilton / The Mac Observer / Mac Geek Gab / Dave on Twitter
When you find a big kettle of crazy, it’s best not to stir it. -
Kenneth Carey
- [ Ignore ]
Dave:
Thanks for your help. With the information you provided I was able to resolve my issue.
Intersting observation I have made - ifconifg will not properly detect an IP address already in use. When I use ifconfig to assign an IP address that is aready in use by another node on teh network - it will still send the gratuitious ARP packet over the wire and claim the address as its own even though it knows it is in use.
IPCONFIG will detect if an IP address is already in use and not make use of it. Much more user friendly.
BTW - do you happen to know how to change the ARP timeout value? I would like to experiment with the amount of time an entry in the ARP table remains valid.
Once again - thanks for your help.
