You would, of course, be in a better position than I to know this (billw@cisco.com ) but I've heard from several sources that there is a user defined chunk of data that can be transmitted with each ping request and reply. Quoting http://www.vijaymukhi.com/vmis/icmp.htm
...the first ICMP packet starts off with an 8 which stands for 'Echo Request'. This means we're asking the destination server to Echo the packet back to us when it receives it. In this way we can both time the packet and check the reliability of the link. This first byte is known as the Type Field. The next byte is a zero and stands for the Code. After that come two bytes for the Checksum and right after that come another two bytes for the IDentification number. The ID has to be unique, so most UNIX boxes set the ID's to the number of the current process. The next two bytes constitute the Sequence Number. Finally, we can add any optional data if we so desire. The data added will be echoed back to us so that we can check the reliability of the line.
The only limitation is that the optional data be less than 64k as more than that may cause problems on older implementations of the PING service. There is a nice (read: more complex than necessary) ICMP implementation in C++ at http://www.vijaymukhi.com/vmis/icmpprg.htm Also, by definition, a ping is about the simplest protocol in the internet. And it is always implemented so even if you hit the wrong IP address, you get something back, and can tell if your connection is good (and you have the wrong IP address). Seems to me that ping with "user data" would be ideal for embedded internet PICs. No need for TCP/IP in the PIC. Just PPP (if you need dialup) and ICMP. What am I missing? --- James Newton (PICList Admin #3) mailto:jamesnewton@piclist.com 1-619-652-0593 PIC/PICList FAQ: http://www.piclist.com or .org -----Original Message----- From: William Chops Westfield [mailto:billw@cisco.com] Sent: Thursday, June 15, 2000 15:53 To: jamesnewton@piclist.com Cc: PICLIST@MITVMA.MIT.EDU Subject: Re: [PIC] How about an open-source emWare like product? Why not only implement UDP and a ping service on the PIC (or whatelse there is needed). Appending data/commands at the end of the ping. I thought you were at least peripherly interested in "conformance." Adding "user data" to ping packets (or ICMP in general) isn't allowed and wouldn't count as conforming to much of anything. Additionally, ICMP is frequently supressed by all sorts of firewalls. I don't think y'all are "getting it" with respect to emWare and similar products. Providing internet connectivity is only PART of such a product. A larger part (IMHO) is providing a supported web application library. emWare presumably (I have not looked at it in much detail) allows an embedded designer to incorporate web-managed/available data into their project WITHOUT them having to learn a bunch about internet networking in general. An open-source product might be useful for some people, but is probably about as much use to emWare customers as a java compiler is to basic stamp target audience. For a stripped-down TCP/IP implementation on a microcontroller, I wouldn't worry very much about "conformance" in a larger sense, as long as you are "well behaved" within the scope of what you actually do. Implementing fragment reassembly is pretty pointless if your applications can limit packet sizes to those which are very unlikely to be fragmented, for instance. ICMP support is a slightly thornier issue, but I think you could do without it... BillW cisco