ICMP

Something in the protocol must make sure that the dump trucks are running properly and that they follow the right route to their destination. This task is partially the responsibility of the Internet Control Message Protocol (ICMP). MicroMonitor only implements a small portion of ICMP. For my purposes, the most important part of ICMP is the echo capability. ICMP echo is commonly referred to as ping . The purpose of ping is to allow one network device to find out if another device is on the network and healthy. A device that sends an ICMP echo request is attempting to determine if another device is healthy . A device that receives an ICMP echo request responds to confirm that it is alive . ICMP support is important if you want other devices to be able to determine whether the target system is present on the network. One other important use of ICMP (in this case) is that I need to be able to tell a sender if a packet is undeliverable. For example, MicroMonitor does not support Network File System (NFS), so if the system receives an NFS request, it should respond to the sender with an ICMP Unreachable Protocol message to let the sender know that the request is undeliverable.

Note 

There is one other handy use of ICMP echo in embedded systems. Earlier in this chapter, I mentioned the ARP cache. The ARP cache is very useful on a stable network. When a device is attached to the network, its MAC and IP addresses are fairly constant ( assuming no DHCP licensing for now). In a development environment, however, where network-attached devices are being built and debugged , the network configuration is somewhat less stable. In this environment, the ARP cache mechanism can get in the way, particularly if you need to recycle a particular IP address.

For example, assume that you are working on several network-enabled projects and that the network administrator has assigned you a single IP address for hardware testing. At first glance, this arrangement seems reasonable; though you are working with several different embedded systems targets, you will have only one turned on at a time. So you set up each device with the same IP address. When you connect to the first device using IP/UDP, everything works fine. Your host identifies the device as IP address 135.3.94.138 and MAC address 00:60:1d:02:0b:fe . Your host silently adds this relationship to its ARP cache.

Now you shut down device_1 and turn on device_2. It is also configured at IP 135.3.94.138 but has a MAC address of 00:60:1d:02:0b:f0 . When you try to talk to this device, your host says it cant find the device.

If at this point you issue the command arp a (or some equivalent) to dump the content of the hosts ARP cache, you will see that your host still thinks that 135.3.94.138 has a MAC address of 00:60:1d:02:0b:fe (because the host put that IP/MAC combination into its ARP cache during the earlier interaction with device_1). If you dont have the ability to flush your hosts ARP cache manually, you have two choices. You can wait until your machine automatically flushes the cache, which could be several minutes. Alternatively, you can issue an ICMP echo from your target to any other device on the subnet. The hosts network interface would see this broadcast and update its ARP cache immediately. Now communication between your host and device_2 works properly.



Embedded Systems Firmware Demystified
Embedded Systems Firmware Demystified (With CD-ROM)
ISBN: 1578200997
EAN: 2147483647
Year: 2002
Pages: 118
Authors: Ed Sutter

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net