Category: Software

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.

One solution to “A device attached to the system is not functioning” error

Late last year, I received a call at work from a customer with a question about their software, and I needed to log in to their system to take a look. I fired up my VPN connection, then opened Remote Desktop Connection and entered the customer’s server information.

When I attempted to connect and log in to that Windows Server 2008 machine, however, I was greeted with the cryptic message, “A device attached to the system is not functioning.” After acknowledging the message, I was promptly and unceremoniously disconnected from the server.

But what does that mean?

Obviously, something was not exactly right, but what? I turned to search engines to try to figure out what was going on.

It turns out this is an old Windows message. Microsoft TechNet has an entry for the message in its Windows 2000 Error Messages Reference which helpfully explains that an attached device is not working for any of a variety of reasons, the first being that “it is switched off, or connected improperly.” Okay, that makes sense, but the recommended solution? “Correct the problem and retry the command.” Wow, thanks. I’ll get right on that once I figure out what the problem is!

Another suggestion I found on a Microsoft forum was to check Device Manager to see if any malfunctioning devices were listed. That actually was not a bad idea, and I would have happily started there, but since I did not have physical access to the machine and could not connect via RDP, that was sadly not really an option.

My search continued, and although I don’t remember exactly where I read it, I eventually stumbled across a snippet that mentioned that Windows will sometimes display this error if the user account that you are trying to use to log in is already logged in remotely but disconnected from that machine. It’s not entirely clear to me why an account being logged in but disconnected would cause Windows to report that “a device attached to the system is not functioning,” but in the context of the sort of remote support we do at work, it seemed feasible that that was what was going on.

As I already mentioned, though, this was a customer’s machine to which I did not have physical access. I could ask the customer’s IT help desk to check, but it could take some time to get a response. Was there any way to check to see if the Windows account I was using was indeed already logged in to that server?

The answer, it turned out, was yes, at least in this particular situation.

Enter PsTools, and PsExec

Microsoft offers a collection of command-line administrative tools named PsTools. Among them is PsExec, which Microsoft bills as “a light-weight telnet-replacement that lets you execute processes on other systems.” Happily, the account that I was trying to use to log in had administrative privileges, so if I could connect, I should be good to go.

The PsExec documentation explains all of the different arguments that can be passed to the program, but a very helpful post on Vlad’s IT Blog put me on the fast track.

After downloading and unzipping the PsTools pack, I opened a command prompt and navigated to the folder containing PsExec. I then entered the following, using the name of the computer to which I was connecting and my username and password on that machine. The cmd at the end can be replaced by whatever program name you want to run—in my case, a command prompt:

psexec.exe {server} -u {username} -p {password} cmd

In no time at all, I was in. The next step was to find out if my account was already logged in; I did that by entering query session, and sure enough, there was my account’s username with a session state of “disconnected”! I typed logoff {sessionid} to log off that session using the ID listed for the disconnected session, then typed exit to get back to my own machine’s command prompt.

Once all of that was done, I again tried connecting to the customer’s server via Remote Desktop Connection, and was able to log in without any further trouble. Problem solved!

How to send CTRL + ALT + DEL to a Remote Desktop session running within a Remote Desktop session

While connected to a customer’s server via RDP yesterday morning, I needed to send CTRL + ALT + DEL to another machine to which I was connected via a different RDP session running on the first server. It’s easy enough to do that over one level of RDP—you just press CTRL + ALT + END—but how was I supposed to send it to an RDP session running within another RDP session?

The solution provided by user Dave in a Server Fault thread was to use the first server’s On-Screen Keyboard. I went to the Windows menu, searched for that, and was able to send the keystrokes right over. Problem solved!

How to reenable Connect SalesLogix DB to Outlook prompt

At work, we use a CRM package called Sage SalesLogix. SalesLogix has a Microsoft Outlook add-in that allows users to save a copy of an email to SalesLogix when they send.

When you first open Outlook, a “Connect SalesLogix DB to Outlook” window appears with a prompt to enter your SalesLogix username and password. There’s also a “Don’t prompt me again” checkbox which, as I stared through blurry eyes at my computer screen this morning, I checked by accident.

Although this window does add an extra step to the process of opening Outlook, what if my SalesLogix password changes at some point? What if I need to reenter that information? The SalesLogix add-in has no options that can be set through Outlook, so after closing Outlook, I went digging through my system registry.

After opening Registry Editor by running regedit.exe, I started drilling down, eventually ending up at HKEY_CURRENT_USER\SOFTWARE\SalesLogix\Outlook\AddressBook. It was there that I found a registry value named PromptLogin; its data was set to 0. I changed that value from 0 to 1, then launched Outlook again, and voilà—the box prompting me for my SalesLogix login information was back.

How to protect your computer against ransomware

Last month, the WannaCry ransomware attack made headlines when tens of thousands of computers owned by government agencies and private companies around the world had their files encrypted. The attackers demanded hundreds of dollars to undo the damage on each infected computer, but with no guarantee that paying the ransom would actually accomplish anything, victims were stuck between a rock and a hard place.

While the May attack was big news, it’s hardly the first time attackers have encrypted files on users’ computers and then demanded a big payout for decryption keys, and it certainly won’t be the last. What can you do to avoid having your day ruined by a ransomware attack? Here are five suggestions that will help you avoid not just ransomware, but viruses, spyware, and other nasty things, too.

Stay updated

The WannaCry ransomware used a Microsoft Windows exploit as its main method of spreading and infecting additional computers. Microsoft had previously released a patch to plug that hole on supported versions of Windows, but that didn’t help users whose computers hadn’t been patched, or who were using old, unsupported operating systems like Windows XP.

The lesson here is simple: make sure you keep your operating system updated, and make sure you upgrade by the time an OS reaches end of life. (This can be tricky if you have systems running software that will only function on an older OS; in that case, lock the system down as much as possible to minimize its exposure to the bad guys.)

Be a standard user

When you set up a new Windows installation, the first account you create is by default an administrator account. That makes it easy for you to change things, but it also makes it easier for ransomware and malware to change things.

The solution? Set up the required administrator account and use it for initial configuration, but after that, use it only when necessary to do administrative chores like installing software. For everyday use, log in using a standard user account. If you’ve been using an administrator account, set up a different administrator login on your computer, then change your existing account to a standard user account.

Use antivirus/antimalware software

Windows 10 has built in antivirus protection in the form of Windows Defender, but it doesn’t hurt to run different antivirus and antimalware programs if you prefer. If you’re using an older version of Windows, this is even more important since antivirus was not baked in to the OS.

Does running the latest and greatest security suite guarantee that your computer won’t get hit? Not at all; undisclosed zero-day vulnerabilities are especially difficult to protect against. The goal here is to try to give your computer extra help warding off stuff that you really don’t want installed.

Don’t click that link; don’t open that attachment

In a former tech support job, I got a call one day from an employee who had just gotten a popup message notifying her that her documents had been encrypted. The source of the problem? She received an email with an attachment from an unknown sender, and although she knew something didn’t look exactly right, she opened it anyway.

I wish I could say that story is unusual, but it’s not; if people didn’t open infected attachments, or click on links that say they go one place but actually point somewhere else, the baddies wouldn’t keep sending them to our email addresses!

How do you protect yourself? Mouse over links without clicking them to see where they would actually take you; if an email claims to be from Google, but the link points to a .ru domain, it’s probably bad news. Not expecting a .ZIP file from Uncle Fred? Give him a call and ask if he actually sent something to you.

Most importantly, use common sense. If you take a gallon of milk out of the refrigerator and it smells bad or there’s an unidentified glob of green goo floating in it, you’re not going to drink the milk, right? Use the same logic when you’re using your computer: if something in an email or on a website doesn’t look quite right, it probably isn’t.

Show file name extensions

This one is super easy. Open a Windows Explorer window; going to your Documents folder will do. If you’re using Windows 10, click the View tab in the ribbon and make sure “File name extensions” is checked. On Windows 7, press the Alt key on your keyboard, open the Tools menu, and select Folder options; click the View tab, then make sure “Hide extensions for known file types” is unchecked.

This forces Windows to display the actual file extension for a given file. That doesn’t mean a particular file really is a Word document, but you’ll at least know that it really is named Receipt.doc and not Receipt.doc.exe.

Summary

These five suggestions don’t provide ironclad protection against the bad guys; after all, while we’re figuring out ways to protect ourselves, they’re busy trying to figure out ways to get around our safeguards! Nevertheless, taking a few simple steps can save you a lot of grief down the road.

How to force Notepad++ to save with file extension

A few versions back, Notepad++ introduced a new save dialog option that results in files not being assigned an extension by default. While I can see the value of having that option available, it’s not a feature I personally want to use.

It turns out that clearing a single checkbox restores the previous behavior of having a file extension. Here’s how:

  1. In Notepad++, on the Settings menu, click Preferences.
  2. Click Default Directory, uncheck the “Use new style save dialog (without file extension feature)” checkbox, and click Close.

Restart Notepad++, and you should be good to go.

Note that there was a bug when this feature was first introduced that would prevent your change from getting saved. To ensure you don’t run into that problem, make sure you’ve installed the latest version of the software.

How to set up a Windows 7 virtual machine on Windows 10

Several months ago, I decided it was past time to set up a Windows 7 virtual machine on my home computer. It’s not something I need on a daily basis, but I want to have that environment available in case some future Windows 10 update changes something to the point where one of the programs I use no longer works.

I opted to go with the 32-bit version of Windows 7, and found a legitimate license key for sale on eBay. Once I had the installation media in my possession, I fired up VirtualBox. If you’re wanting to do what I did, here are the steps:

  1. In VirtualBox Manager, click New. Enter the name for your virtual machine and select the type and version; as mentioned previously, I’m using Windows 7 (32-bit). Click Next.
  2. Specify amount of memory—I chose 2048 MB—then click Next.
  3. Select Create a virtual hard disk now, then click Create.
  4. Choose your hard disk file type. The recommended and default setting is VDI (VirtualBox Disk Image), but you can choose something different if you have a particular need. Click Next.
  5. Select type of storage on physical hard disk. I selected Fixed size. Click Next.
  6. VirtualBox defaults to a virtual hard drive of 25 GB. Adjust this if necessary—I bumped it up to 40 GB since I have plenty of space on the drive where I’m storing VMs—then click Create. The virtual hard drive creation process takes several minutes.
  7. Start your virtual machine. Select your startup disk (or .ISO file) and click Start.
  8. Proceed through the Windows installation process:
    1. Choose language to install, time and currency format, and keyboard or input method, then click Next.
    2. Click Install now.
    3. Check the “I accept the license terms” checkbox, then click Next.
    4. Choose the custom (advanced) installation type.
    5. With Disk 0 Unallocated Space selected, click drive options (advanced), then click New, then click Apply and click OK.
    6. After setup finishes create disk partitions, click Next. Setup will take several minutes to install files.
    7. After the virtual machine restarts, enter the user name and computer name. Click Next.
    8. Enter a password and click Next.
    9. On the Windows product key screen, click Skip.
    10. Choose Windows Update settings.
    11. Select time zone, then click Next.
    12. Select your computer’s current location, either home or work.
    13. After Windows starts, change the screen resolution; default is 800×600 pixels.
    14. While holding the Windows key on your keyboard, press the Pause/Break button to launch the system information window.
    15. Click the “3 days until automatic activation. Activate Windows now” link.
    16. Click Activate Windows online now.
    17. Enter your Windows product key, then click Next. After activation completes, click Close.
    18. Install Windows updates, restarting the virtual machine as necessary.
  9. After you finish installing and updating Windows, go to VirtualBox’s Devices menu and choose Insert Guest Additions CD image. When the AutoPlay window appears, click Run VBoxWindowsAdditions.exe, then tell the UAC prompt Yes.
  10. Click Next.
  11. Click Next again.
  12. Click Install.
  13. When the Windows Security window appears, click Install.
  14. When the Windows Security window appears again, click Install.
  15. Click Finish to reboot.

After the virtual machine restarts, you might need to adjust the screen resolution again. After that, you’re done!

How to create a copy of a SQL table

Before clicking the button to execute an update or delete query on a table in Microsoft SQL Server Management Studio, have you ever asked yourself, Do I really want to do this? I know I have. This handy statement creates a copy of the table you specify so that you don’t lose all of your data if something goes awry.

SELECT *
INTO {%new table name%}
FROM {%existing table name%}

How to find scheduled task history on Windows Server 2003

I recently needed to look at the history for a particular scheduled task on a client’s Windows Server 2003 machine. In newer versions of Windows Server, this is easy: open Task Scheduler, select the appropriate task, and go to the History tab.

On Server 2003, this information is somewhat less obvious, but blogger Guarang Patel pointed me in the right direction with a post explaining how to find the task history. Essentially, after opening Scheduled Tasks, you go to the Advanced menu and choose View Log, and then you’re where you need to be.

The task history on Server 2003 is unfortunately very short indeed; in my case, I could only find two entries for the task I was researching because a different task is scheduled to run and gets written to the log far more frequently. Nevertheless, it’s helpful to know where to look.