Periodically we receive a question along the lines of "what happened to my job?" It seems that the user expected two jobs, but saw only one come into RPM Remote Print Manager® (RPM) and usually, the two expected data files are merged.
In this post, we'll look at several tools RPM provides to look at the actual print traffic RPM receives. RPM's LPD protocol setup provides a "capture" feature, and the diagnostic logging provides details on LPD, telnet, and others.
Finally, we'll close with a caveat on job tracking.
LPD capture
The RPM 6.2 release included an all-new LPD module that provides the capture feature.
The capture feature does not include any actual print data, so your data privacy will not be compromised. Capture provides a record of the LPD print protocol so that if RPM has a problem with how your print client communicates, we can track it down and fix it.
The more common benefit is that this provides a record of what happened. If you turn the capture setting on, RPM records the traffic for every LPD print job, which can be valuable information.
The one downfall to capture is that if you leave the setting on when you don't need it, your system will eventually have a considerable number of capture files you don't need. At one point during testing, I wondered why RPM took so long to startup. I discovered the reason was that I had over eighty thousand capture files. I had left the capture setting on past the need for it and forgotten about it.
Benefits of capture
- a capture file is a small text file, easily attached to an email message
- the file is plain text
- each line in the capture file includes a command and a timestamp; among other things, you can see how fast your network is delivering your print jobs
- no actual print data is included, just a command showing that print data arrived and the number of bytes
How to set capture up
In the RPM interface, go to Configure / Port Settings. Select "lpd" from the list:
Click "Modify Port" to show the LPR/LPD form:
Select the "capture" setting in the highlighted area, and click OK.
You do not need to restart the RPM service for this to take effect. Similarly, you can turn capture off the same way by deselecting the capture setting and clicking OK.
How to interpret the results
Ideally, you would email your capture files to Brooks support once you have talked with a technician about their recommendations. However, there's no need to keep the capture file a mystery. Let's take a look at a job I sent myself for purposes unrelated to this post.
{ "value": 515, "command": "accept", "timestamp": "2017-11-27 17:51:06.411" }
{ "value": "AnJlbW92ZQo=", "command": "read", "timestamp": "2017-11-27 17:51:06.416" }
{ "command": "ack", "timestamp": "2017-11-27 17:51:06.417" }
{ "value": "AjQ0IGNmQTAwMWdyb290Cg==", "command": "read", "timestamp": "2017-11-27 17:51:06.417" }
{ "command": "ack", "timestamp": "2017-11-27 17:51:06.417" }
{ "value": "SGdyb290ClBEYXZlCmZkZkEwMDFncm9vdApVZGZBMDAxZ3Jvb3QKTjd6LjEA", "command": "read", "timestamp": "2017-11-27 17:51:06.417" }
{ "command": "ack", "timestamp": "2017-11-27 17:51:06.417" }
{ "value": "AzYyMjUgZGZBMDAxZ3Jvb3QK", "command": "read", "timestamp": "2017-11-27 17:51:06.417" }
{ "command": "ack", "timestamp": "2017-11-27 17:51:06.418" }
{ "value": 6225, "command": "data", "timestamp": "2017-11-27 17:51:06.434" }
{ "command": "ack", "timestamp": "2017-11-27 17:51:06.434" }
{ "value": "AA==", "command": "read", "timestamp": "2017-11-27 17:51:06.434" }
{ "command": "close", "timestamp": "2017-11-27 17:51:06.434" }The strings in this file are in JSON format, which is one of several commonly used data encodings on the Internet. Each line has a "command" tag which explains how to interpret the rest of that line. Each line has a "timestamp" tag. You'll notice from start to end this job took twenty-three milliseconds.
If you were curious about the strings next to the "value" tag, these are actual strings that are usually binary, not plain text. If you are interested in the actual values, find a Base64 decoder on the Internet and paste the value into the decoder.
If you've read our FAQ on LPD you might recognize the various stages of the LPD protocol. The longest string value in our sample file is the control file data which shows the job name is "7z.1" and the user and hostname values.
Using diagnostic logging to track jobs
We have an extensive section on diagnostic logging [/diagnostic-log] already. If you are not familiar with our diagnostic log, please start there.
In the RPM user interface, go to Log / Diagnostic Logging. The active settings are the ones with the checkmark. That's what you want to do here; make sure you check the following settings:
- lpd2
- telnet2
As soon as you do this, RPM will start recording diagnostic data in the LPD and Telnet modules log. There are other settings that contain "lpd" and "telnet" which do not help here.
If you use these two settings, you will not need to restart the RPM service. The same applies later when you turn these settings off.
Please note that turning on logging will not solve any problems automatically. If we need the logging, it's to help us track down a problem utilizing more information.
The caveat to job tracking
Whether you use LPD capture or diagnostic logging, the biggest single downfall to either approach is that it shows what happened. It rarely indicates an error, because if a job is missing, RPM won't know it's missing if it never received it. It will require more logic to piece events together.
The point of logging is that it gives us a clear record of what did happen.
The other caveat we run into is that unless we get a specific date and time, or some additional identifying information, we won't know by just looking at a log which job might have a problem.
One example of identifying information might be this: if all your jobs are 55K bytes, and we see one that's 110K bytes, then we know to look there. That's where the customer is the most valuable asset in troubleshooting because you know your system like no one else.
If you have any questions about this post or would like to see other topics, please leave a comment. Thank you!