Tag: PuTTY

How to use PuTTY to communicate with a TLS unit

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.

How to fix PuTTY showing only a few files from directory

A few weeks ago, I ran into a weird issue where WinSCP would load only the /home/ directory on a Linux-based terminal, and the ls command in PuTTY would return a list of only the first few files in any directory. I’d never encountered anything like it, but since I finally figured out the problem, I thought it was well worth documenting.

The problem

It all began when one of our techs at work was installing a new terminal and needed me to connect to it to load the customer’s application. I fired up WinSCP, entered the terminal’s IP address, clicked Login, and waited. WinSCP reported that it was connecting and that it was loading the directory contents, but after a while it timed out. I tried again; same result.

Odd, I thought, running a continuous ping to check the terminal’s network connectivity. I could see a packet was getting dropped here and there, but it was nothing excessive, and definitely not something that should be preventing WinSCP from connecting. I was able to connect to the terminal via PuTTY and changed to my target directory, but when I ran the ls command, I got a list of only seven or eight files, and that was it.

I could connect to other terminals on the customer’s system without any trouble but updated WinSCP just to be sure we had the latest and greatest, but that didn’t make any difference. We chalked up the problem as a possible bad flash card and shipped out a replacement card which we tested in a terminal in our office for the tech to install. Even after he plugged in the new card, however, we continued to see the same behavior, which led me to believe that the problem was not with the terminal itself, but with the customer’s network. But what could it be?

The research

You would think that doing a search for “PuTTY and WinSCP won’t list contents of remote directory” would turn up some helpful results, but my initial efforts to figure out what was happening were fruitless. It was only after a couple of hours of searching that I finally ran across an Apple Community thread from 2011 that finally got me pointed in the right direction.

In that thread, the original poster complained about a Linux-based box “hanging” when they issued basic commands when connecting to the machine via SSH. Interesting…that sounded kind of like what I was seeing in PuTTY.

One of the users who replied, Camelot, stated that the problem was “almost certainly a MTU issue,” explaining that the original poster’s VPN was probably not resetting the MTU properly, resulting in “large packets…getting truncated and/or dropped—that’s why small transactions…work, but large ones fail.”

The solution

I’m not going to get into the weeds with a detailed explanation of MTU (maximum transmission unit), but even though no VPN was in use between the customer’s server and terminal, a MTU mismatch turned out to be exactly the problem. Somewhere on the customer’s network between the server and the terminal, there is a router or switch whether the MTU is set to less than the default packet size of 1500 used by both the customer’s Windows server and our Linux-based terminal. This was wreaking havoc with my attempts to transfer data, even basic directory listings, using WinSCP and PuTTY. This happens because the 1500-byte packet gets broken into two smaller fragments; the first makes it through, and the rest gets dumped.

Serenity Networks has a very good explanation of how to determine the MTU between two devices. It boils down to this:

  1. At a command prompt, enter ping ip -f -l 1500. If you see the message Packet needs to be fragmented but DF set, the MTU is less than 1500; proceed to step 2.
  2. Repeat the command from step 1, but reduce the last number by 10 (from 1500 to 1490), and keep doing this until you find a number that gives you normal ping results.
  3. Now, repeat the same command, but increase the last number by 1. Keep doing this until you find a number that once again gives you the Packet needs to be fragmented but DF set message; the last number that gives you normal ping results is your MTU.

In the particular environment that I was troubleshooting, MTU needed to be set to 1348. Since our terminal is Linux-based, I didn’t have to bother getting the customer’s IT team involved to try to track down the weird piece of networking equipment, instead, I was able to set the MTU on the terminal’s NIC by doing the following based on a nixCraft post:

  1. On terminal, enter sudo nano /etc/network/interfaces.
  2. Under the gateway line for eth0, enter mtu 1348, then press CTRL + X and Y to save the file.
  3. Enter sudo reboot to restart the terminal.

Once this was done, I entered ip 1 to confirm that the terminal was using the correct MTU, then fired up WinSCP. WinSCP connected immediately and displayed the remote directory on the terminal with no complaints, and I’ve had no further problems with it.