IP address woes

[Chris Johns]

Angelo Fraietta wrote:
> Shouldn't this be automaitically added to the cache in RTEMS when I 
> receive the brodcast address? RTMES is able to determine the IP address 
> when it receives teh bradcast message (I know because I can see it on 
> the console). Shouldn't it be added to the cache in the IP layer?

I assume you are referring to the ARP cache. This is the IP layer to 
Datalink layer mapping protocol. I do not know of other cached info in 
the IP layer.

I do not think the ARP cache is updated on incoming IP packets. I have a 
number of Windows machines that do SMB broadcasts and my API cache 
(Linux) does not show these machines.

Broadcasting an IP packet from MacOS will not require an ARP request as 
the MacOS will know to use the Ethernet MAC broadcast address 
(ff:ff:ff:ff:ff:ff). The RTEMS machine will respond and send a directed 
packet to the MacOS's IP address. This will require an ARP request from 
the RTEMS box and the MacOS machine to respond. The MacOS machine may 
also update its ARP cache with the RTEMS box's data when responding [1]. 
Both ends will have each other in their ARP cache. You should now check 
each end and make sure they are both valid.

Goggle gave me this link for commands you can use to debug your problem:

  http://www.cromwell-intl.com/tcpip/commands.html

Look for the ARP cache commands. RTEMS has a function you can call that 
will dump the ARP cache.

This may not be your problem, but an incorrectly byte swapped IP address 
in application code could cause this sort of problem. The Windows 
machine is a certain byte order while the MacOS code is the opposite and 
the code breaks.

[1] TCP/IP Illustrated Vol 1 W.R. Stevens, Sec 4.5 p59.

-- 
  Chris Johns