[ale] how to redirect fds through telnet session in QNX?

[Step]

(Summary so you don't have to read my long email: I'm looking to avoid a
hardware solution and was hoping to embed a script or program I could then
run through telnet when needed that would log the debug messages or copy
(duplicate?) them on the telnet session.  Barring that, I hope to better
understand why that is difficult to do).

Thanks Chris -that helped me look up some more information.  I found this
page:
http://www.qnx.com/developers/docs/qnx_4.25_docs/qnx4/user_guide/chardev.html

All the way at the very bottom it explains a little more about what I'm
seeing with /dev/con1 (which is a virtual console) and /dev/ttyp0 (which is
the slave side of a pseudo-terminal).

I looked up null-modems (wikipedia provided a start here) and it looks like
there are such things as virtual null-modems.  That might be the answer - it
looks like you recommended this because a null-modem requires relatively
little effort and allows low-level access?

Here is the statement from wikipedia that caught my attention: "The
popularity and availability of faster information exchange systems such as
ethernet <http://en.wikipedia.org/wiki/Ethernet> made the use of null-modem
cables less common. Nowadays, such a cable can still be useful to
kernel<http://en.wikipedia.org/wiki/Kernel_%28computer_science%29>hackers
though, since it allows the user to remotely debug a kernel with a
minimum of device drivers and code".

I should have explained that we have a closed instrument installed in many
locations, so I'm constrained from putting additional hardware in place (at
least not very easily).  We have a custom cable bundle that includes a
standard ethernet connection - this is used for the majority of the
communication with the embedded device.  The embedded device has an IP
address, and so we can quite easily open up a telnet session from the
workstation (which might be 100 feet or more away).  We can also open up an
ftp session, and in fact have a client to do some standard ftp actions
automatically (such as backing up the software and/or the settings).

Since the instrument is often mounted on lifts, walls, or otherwise
relatively inaccessible locations, I was hoping to just push over a script
or some code with our next embedded software update, that I can then run
through telnet to duplicate or somehow send debug information to file.
Barring that, I want to understand why that won't work, in the hopes that
I'll better understand my Ubuntu box, networking, and generally improve my
understanding of computers.

I am not concerned about kernel crashes (as you probably guessed since we're
talking about QNX). What I would like to get insight into is certain of the
processes we wrote that are failing, without restarting the processes in
question.  The other part I don't understand is that if we restart the
processes, we do see the output in the telnet window.

I found a little information on the QNX device manager, which is what
normally manages the stdout (well, the communication from the processes) and
the consoles, serial devices, and pseudo-terminals.

I haven't been able to find a software null-modem that I can experiment with
yet, but I will keep researching.  Any more suggestions?

Thanks,
Step

On 3/23/07, Christopher Fowler <cfowler at outpostsentinel.com> wrote:
>
> On Fri, 2007-03-23 at 17:20 -0400, Step wrote:
> > Any other information I need to provide?  Any pointers would be
> > greatly appreciated.
>
> Attach a null-modem cable from a PC to the embedded device's console.
> Send all debug statements to /dev/console which in this case will be
> QNX's serial port.
>
> Log all messages on the PC coming from the serial port to disk for debug
> purposes.
>
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
>
-------------- next part --------------
An HTML attachment was scrubbed...