Forward from GNU volunteer coordination

["S. Morningthunder" <mthunder@jreyes.ifisicacu.unam.mx>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4628 bytes --]

I don't know whether this will be of any use to you or not.  But it
seems like a logical place to begin.


------- Start of forwarded message -------
Resent-From: GNU Mailing List Maintenance <gnu@prep.ai.mit.edu>
Date: Wed, 26 Nov 1997 23:59:46 -0800
From: Pascal Martin <pmartin@earthlink.net>
To: gnu@prep.ai.mit.edu
Subject: over-the-ethernet debug stub
Resent-To: gvc@prep.ai.mit.edu

Hello.

I have seen on your WEB pages a request for help for this project.

Although I would have enjoyed volunteering, I currently have no time
available.

I do, however, have some experience on that subject, having designed
and implemented a very similar debugger stub in a previous job.
Here are some comments about your description of the project.

It appears to me that such an Ethernet support would be an invaluable
addition to the embedded environment support in GNU, so the stub
should be designed for reuse ouside the HURD itself.

- - protocols to be used.

  My experience is that it is always a bad idea to not use the
  Internet protocol suite, because most systems protect the low
  level Ethernet socket for obvious security reasons. Also, using
  the Internet suite is much more portable (including Windows 95/NT).

  I had developped a small UDP/IP suite which, compiled, took
  about 7 Kbytes of 68k code, despite the fact it was Ada sources.
  This implementation included ARP/RARP and ICMP/ECHO support,
  plus an auto-configuring routing table:

  * ARP/RARP is obviously a must-have and more recent alternatives
    are quite memory-hungry.
  * Having ping to work has been proven very useful.
  * The routing support made me able to debug a target in France
    from my workstation in San Diego (how fun !).

  In other words, UDP/IP is perfectly suitable for this project.

  Of course, UDP/IP packets may be lost, so each command must have
  a sequence number, the workstation must retry commands when it
  receives no answer (timeout), and give up after n retry (except
  may be after a "go" command, because you never know how long it
  will take..).

  The target side must reply to all commands, but must execute
  a command only once and be able to repeat its last reply. This
  involves at most a mere 1.5Kbytes of data (one Ethernet packet).

  A variant of the existing gdb remote debugging protocol is
  probably usable: just add a header to contains the sequence
  number. In any case, avoid double acknowledgment as I have seen
  in some product: the UDP packet was acknowledged, then the
  answer packet was sent (and acknowledged..). This was an artifact
  of reusing a protocol designed for RS232 lines, and this was really
  inefficient, and even less reliable.

- - Ethernet sharing.

  What have been a major problem is to share the Ethernet access
  between the debugger and the applications. An acceptable solution
  was to let the debugger peek at each network packet received, so it
  can intercept debugger's commands when the application is running
  (so the debugger can do dumps or stop the application).

- - auto-configured routing support.

  A target is always a server that answers to a debugger requests.
  That means a target always receives a packet from the workstation
  before it sends one of its own.

  Because of that it knows the _Ethernet_ address of the source.

  There are two cases:

  - the workstation is local. The Ethernet address is the address
    of the workstation. There is no need to issue an ARP request:
    we can fill the ARP table right now.

  - the workstation is on a remote network. The Ethernet address is
    then always the address of a router. Because Internet routes are
    almost always bi-directional, sending the answer packet to that
    router will initiate a successful routing trip to the workstation.

    It is then safe to associate the workstation's IP address with
    the _router_ Ethernet address.

  Conclusion: any valid debugger UDP/IP packet received can be used
  to blindly initialize an ARP cache entry. This is totally automatic,
  there is absolutely no configuration required, and there is not even
  really any routing code involved.

  .. and I never took any patent on this one, so I guess you can use
  it without any fear of being sued.


I hope this may help some day..

Regards,
Pascal MARTIN.
------- End of forwarded message -------

-- 
A wall of infinite dimension stands before the course of human evolution. 
It is the finitude of the earth and its resources.

Steve Morningthunder

Instituto de Física, Universidad Nacional Autónoma de México
mthunder@gnu.org
mthunder@jreyes.ifisicacu.unam.mx