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

[James P. Kinney III]

On Sat, 2007-03-24 at 15:48 -0400, Step wrote:
> (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 made the use of null-modem cables less common.
> Nowadays, such a cable can still be useful to kernel 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? 

nc (netcat) may provide the ability you are looking for. It is possible
to use nc as a "pipe receptor" that dumps the received data over tcp/ip
using a defined port to a remote listening machine.
http://en.wikipedia.org/wiki/Netcat
> 
> 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
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
-- 
James P. Kinney III          
CEO & Director of Engineering 
Local Net Solutions,LLC        
770-493-8244                    
http://www.localnetsolutions.com

GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
<jkinney at localnetsolutions.com>
Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part