The company that employs me is involved in the fuel management industry, helping government agencies and corporations keep track of who can dispense fuel, how much and what types of fuel they can dispense, and how much fuel has been used.
One thing that we are not directly involved in is the manufacture or maintenance of tank level sensor (TLS) units. The company’s software does include the means to track fuel levels in storage tanks, however, as reported by TLS units monitoring those tanks, and that means we need to communicate with TLS units.
Under normal circumstances, the company’s communication software once configured retrieves current tank level data from each TLS unit, but there are times when we need to independently confirm what information a unit is reporting. For example, we or a customer’s IT staff may need to determine how a contractor configured the tank probes, confirm a tank’s capacity, or manually check current tank levels or delivery records.
Our usual approach when that is necessary is to open a command prompt and start the Windows Telnet client by entering something like the following:
telnet 10.10.10.10 3001
That is assuming that the customer’s workstation or server actually has the Telnet client installed, however, which is not necessarily always the case, and we don’t always have the option of making modifications to a customer’s environment. In those situations, we have to have an alternative.
A couple of month’s ago, I started playing around with the PuTTY client to figure out if it could serve as a stand-in for the Windows Telnet client. After all, Telnet is one of the listed connection types on the main PuTTY screen, so it should be able to handle the job, right?
I began by entering a TLS unit’s IP address, changing the port number—3001 and 10001 are common defaults used by Veeder-Root and other manufacturers’ TLS units—then selected the Telnet connection type and opened the connection. I was greeted by this response:
9999FF1B
That essentially means the TLS unit looked at the information submitted to it and responded, What does that mean? I don’t know what it is you want me to do.
The solution, it turned out, was simple enough. In PuTTY, under the Connection menu, on the Telnet page, I changed the telnet negotiation mode from active to passive. After doing that and connecting to the TLS unit again, I was able to enter commands like this:
CTRL+A SHIFT+I 20100
And after pressing the enter key, I got a rational response from the TLS unit.
Curious about why I had to change this setting, I went searching for an answer, and found this in the PuTTY documentation:
“In a Telnet connection, there are two types of data passed between the client and the server: actual text, and negotiations about which Telnet extra features to use… In active mode, PuTTY starts to send negotiations as soon as the connection is opened. In passive mode, PuTTY will wait to negotiate until it sees a negotiation from the server.”
In other words, in active mode, PuTTY tries to send information about what it’s willing to do, which the TLS unit interprets as a command that it doesn’t understand. That’s why I was getting the weird response from the TLS unit I was trying to contact.
In summary, if you need to make a Telnet connection to a TLS unit using PuTTY, be sure to select passive negotiation mode.