PRESENTING OPERATIONAL INFO

If you ARE interested in helping me fix bugs, then I encourage you to run the GDB debugger that comes with most linux distros, AND make sure you do NOT strip the 'jnos' binary, since it contains important info for the debugger to use when a crash occurs.

Using GDB is easy. With JNOS running already, find out it's pid, using the linux command:

ps -ef | grep jnos

Once you know what the pid is, then run the gdb debugger something like this:

gdb -p pid

GDB will load, JNOS will hang temporarily, and GDB will suddenly give you a "GDB>" prompt. Enter the command:

continue

at the prompt, and JNOS will continue to run again.

When a crash occurs, GDB will break out to the prompt again, and JNOS will hang. Take a screen shot of what GDB printed out, then type in the command:

where

back

at the GDB prompt, and note the info that appears. Please send all of that information to me, with a brief explanation of what might have been going on at the time. If you have JNOS logging in effect, please send the log file at the time of the crash if you don't mind. Logs are under /jnos/logs/ directory (by default).

In order to capture operator interface data for documentation (and when things go wrong), I found a couple ways that function pretty well. I find them most useful as I replicate problems since malfunctions are fairly infrequent, and so I don't always operate with the following stuff in place. After capturing the problem thru reenactment, I find it pretty easy to use my favorite text editor to select the portion of the screen text that relates to the bug, and prepare a file to use as an email attachment. To capture material for debugging purposes, my standard mode of operating (on Linux FC-4) is to:

init jnos from multi-session "F4" as root (#) so I have a separate jnos console immediately available
init gdb from multi-session "F3" as root (#) so I have an independant console for trace control and capture.
init telnet from multi-session "F5" as my normal user ($) to access jnos BBS services
use the GUI tools for most everything else on multi-session "F7" (as a normal uid)

I don't have jnos established as a service for 24/7 operation (yet) since radio availability is an issue and sometimes the TNC needs TLC if there has been power interruption. I often trace interface traffic using standard jnos features and catalog the results for back-tracking purposes. My favorite is to capture using "tee", a Linux (Unix) basic utility. To load the file "screen.txt" with data presented on the terminal, use the command:

...$ telnet 192.168.2.2 | tee screen.txt

After telnet exits, edit the screen.txt file as needed to display what was seen during the session. One caveat - the command line echos (that I type) are missing from the output. All-in-all, this works pretty well to collect text for documentation purposes - I use it to help me remember details about remote stations.

My second favorite for deeper analysis in HEX when special characters are involved, telnet has a built-in trace facility. There is a utility to re-display the hex data in character form, but I have not needed it to date. If the plan is to capture data, then:

...$ telnet 192.168.2.2 -n screen.dump

While in the session and before the problem, escape and enable the trace with:

^]
telnet> toggle netdata

After the problem (presuming telnet has not crashed) repeat the above to stop collection. After the session is complete then edit the file "screen.dump" with that favorite editor. When there is a surprise, and the "-n file" paramater is not given to telnet upon start-up, the file may be set during the session by:

^]
telnet> set tracefile screen.dump

That needs to be done before toggling netdata to keep the trace data off the screen. There are more options to this found in the man pages for telnet.

My third favorite requires root (#) user, so I don't do it often... Quoting Maiko: " I found this a short time ago - http://www.faqs.org/docs/Linux-HOWTO/Keyboard-and-Console-HOWTO.html#s20 I hope that helps. " This uses the command:

...# setterm -dump 5

In this case, I use the "F1" console as root to issue the command to capture the text existing at the moment on console "F5". Notice that by changing the "-dump #" that a screen may be captured from 2=administrator, 3=debugger, 5=user. This works when finding a suspected condition to document (assuming the condition fits one screen full or less) and the user can skip over to another multi-console to do the capture... This does not trace, it snapshots the screen and places the content into the file "screen.dump". Again my favorite editor helps me make a "show-and-tell" display for whatever purpose. NOTE: I have found the normal user can also do this BUT it must be preceded by a su and chmod to set /dev/vcsa5 with o+rw permissions.

I hope someone else finds this useful too...