>I for one need to see a more detailed example (examples are so
>helpful!) from Michael to understand better what he wants to do.
>
>E.g "I run 'reverse_telnet' on machine A, it listens/connects on
>port NNN ..., I next run 'minicom -l /dev/wombat' on machine B and
>I gain tty access to the wombatd kernel module on machine C, ..."
That's pretty close. I haven't got time to sketch
this in much detail, but it's basically like this:
Machine M: embedded box w/serial console
Machine C: Cyclades
Machine L: Linux workstation
+---+ +---+ +---+
| | | | | |
| M |---RS232---| C |---Enet---| L |
| | | | | |
+---+ +---+ +---+
The Cyclades (as do most such boxes - "terminal
servers" or "serial port concentrators", etc) has a
telnet server in it that is willing to relay traffic
between its various RS232 ports and various telnet
sessions established by remote telnet clients. In
other words you can say "telnet cyclades" and basically
be directly connected to the serial port of interest.
That's cool, but not good enough for what I want to
do, which is use GDB running on Machine L to debug
the mess in Machine M. GDB does know how to talk
through a directly connected serial port device
like /dev/ttyS1 but (as far as I can determine -
I'd be thrilled to learn that I'm mistaken) doesn't
know how to speak Telnet protocol. That's where
reverse telnet comes in; if I can get a reverse
telnet daemon to run on Machine L, connect to the
telnet server in Machine C and create its magic
little pseudo-device on Machine L, I can mention
that device to GDB (also running on Machine L) and
everything should Just Work(tm), right...?
=
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
