[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IP address woes
- Date: Thu, 20 May 2004 15:13:24 +1000
- From: cjohns at cybertec.com.au (Chris Johns)
- Subject: IP address woes
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 .
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:
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.
 TCP/IP Illustrated Vol 1 W.R. Stevens, Sec 4.5 p59.