Changing IP address without transmitting ARP collision detection packets

  • Posted: 05 November 2009 01:49 PM

    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.

         
  • Avatar

    Posted: 08 November 2009 08:31 PM #1

    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.

         
  • Posted: 09 November 2009 10:36 AM #2

    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 up

    Using 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 supported

    It 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.


    Any help on how I can get this ifconfig command to work properly is greatly appreciated.

    [ Edited: 09 November 2009 10:42 AM by Kenneth Carey ]      
  • Avatar

    Posted: 09 November 2009 10:47 AM #3

    Ah yes, of course. I was looking at the ipconfig man page, not ifconfig. Thanks. wink

    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.

         
  • Posted: 18 November 2009 04:10 PM #4

    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.