.TH LINECHECK 1 .SH NAME linecheck \- debugging tool for .IR term serial lines .SH SYNOPSIS .B linecheck [--stderr] [--seven_in] [ escape ... ] < /dev/tty?? >/dev/tty?? .SH DESCRIPTION The .IR linecheck program performs a first-order test of the transparency of the link. .IR Linecheck sends packets, once per second, each of which contains one of the 256 possible 8-bit character codes. The diagnostic output helps you determine which characters do not get through. This is important, since almost all of the problems associated with getting .IR term running occur because individual characters or character sequences do not get through the serial link or cause other characters to be sent and/or echoed by the link. .IR Term can easily be told to avoid sending these characters by listing them in the termrc file, the problem is determining which ones to avoid. .IR Linecheck tests all 256 individual characters and helps you determine which are not getting through. It only checks individual characters, not character sequences. If you specify the "--seven_in" option, linecheck will apply as seven bit mask to the characters it receives. (This is only needed if you are using a parity bit on with a seven bit line. Try linecheck first without this option.) .PP .IR Linecheck must be run on both systems the same way .IR term is run. That is, the stdin and stdout should be directed to the serial port while the stderr goes to the log file linecheck.log. Remotely you can type .PP \ \ \ linecheck .PP to the sh, or .PP \ \ \ sh -c 'exec linecheck' .PP to the csh. Locally you should escape from your comm program and type something like .PP \ \ \ linecheck < /dev/modem > /dev/modem .PP to a sh. .PP You can tell linecheck not to test certain characters by listing their decimal numbers on the command line. For instance, if you know flow-control will get eaten, you can use "linecheck 17 19", and it won't test those chars. Or, if your link goes through an .IR rlogin (1) on the remote end, you will want to put 126 on the command line to escape the '~' character. Also, in this case, you'll want to use .PP \ \ \ rlogin -8 -L .PP in a bid to establish a maximally transparent rlogin. .PP Once .IR linecheck has finished running on both ends, you should examine the respective log files on the two systems. These files will contain lines of the form ' sending char' and ' received valid', where is the decimal number of the character in the packet. These indicate that the local .IR linecheck (the one generating the log file) sent the character or received the character from the other .IR linecheck. It's normal if the 'sending' and 'received' numbers are not in sync. .PP Lines of the form 'Invalid packet: ' are the interesting output. They indicate a packet was received, but was corrupted. This may be due to simple line noise, or to the opacity of the link to a character generated by either the remote or the local .IR linecheck program. At least three possible kinds of link opacity can lead to invalid packets. When a character that should be be escaped is sent the link may simply not transmit the character in question, or the link may transmit a different or extra characters. Also, at the same time, the link itself may echo characters back to the system which sent the character in the first place. You must study the log files from both systems to determine which direction of the link causes the problems and which characters should be escaped on which system. Real link problems like these should be repeatable while line noise effects will not. .PP The bottom of the log file lists characters that linecheck believes should be escaped by the other system in the termrc file. These are characters that the other system sent, but which were not received correctly. If you had no invalid packets then this summary is probably reliable. If there were invalid packets it is possible that .IR linecheck's recommendations are wrong. You must examine both logs closely to determine what caused the invalid packets. .PP If, for some reason, you get stuck out in lala land, and can't kill the remote program, try typing '00000'. That should kill it, and restore your terminal. .SH BUGS .IR Linecheck is too slow and won't detect if 17 and 19 need to be escaped. .SH SEE ALSO .IR term (1), .IR termrc (1), .IR term_setup (1), .IR term_clients (1), .IR termtest (1), .IR linecheck (1). .SH AUTHOR Michael O'Reilly, michael@iinet.com.au, original author .br Bill C. Riemers, bcr@physics.purdue.edu, current developer.