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.

Documentation is a necessity, not a luxury

“Documentation? We don’t need no stinkin’ documentation!”

That seems to be the approach of many IT departments to keeping a record of how things work. It’s an unfortunate attitude, really. Sure, not taking the time to create documentation may save a few minutes today, but a year from now when you’re trying to recall what setting you had to change to get some piece of software to work as desired, or when you’re trying to figure out which cable end in the rat’s nest in your network closet provides connectivity to the vice president’s office, you just might find yourself wishing you had written something down.

With that in mind, I propose the following: documentation isn’t just something that’s nice to have. It’s a necessity. Skip it—or get into a job where it’s not available—and you will be pulling your hair out.

Documentation vs. no documentation

In my previous gig, we created how-to guides on how to install specialized accounting software. I worked up an “if I get hit by a bus” document explaining each of the little processes and duties I had to handle on a regular basis. We even had a map of the building with each set of network ports labeled, and on the network switches in the server room? Each of those ports was numbered to identify how it matched up with the labels on the map.

When I started my current job, however, I was in for a bit of culture shock. Documentation consisted of a couple of OneNote files, a few user manuals that had for the most part not been updated for the current versions of the various pieces of software used by the company, and a lot of, “Go ask _____, he might know how that works.”

That approach might work for a while if you’re running a one-man shop, or if your company has exceptionally low turnover, but someday someone—maybe even you—may need to know how to do something again. Why make life more difficult for your successor—or yourself—by not creating some documentation?

Thankfully, things have improved some where I work. There’s always room for further growth, of course, but the tech support group at least has a Wiki now, and I’ve been adding things to it no matter how mundane or commonplace they seem. It may not be something I need tomorrow, but a year from now, or when someone new starts, I would much rather have spent five minutes writing a how-to than have to figure it all out from scratch. And as the new guy, I would have loved to have had that kind of resource available to me.

What you can do

Chances are that you too have run into a lack of documentation. That’s not something that can be fixed overnight, especially if it has been neglected for a long time, but you can start fixing the problem now. Here are a couple of suggestions to make life easier for future you and those who follow:

  1. If your employer has an internal knowledge base of some sort, ask if you can add material. Even if it hasn’t been updated in the last five years, start squirreling away information. Post existing manuals that aren’t already there. Ask your colleagues for suggestions of things to add; even if they’re not willing to do any writing themselves, maybe they’ll at least give you some ideas of things that would be useful.
  2. Create your own knowledge base, especially when you discover things that aren’t specific to a particular workplace. That could be a blog like this one, or a Wiki, or even a bunch of Word documents stored in a folder on your computer. The exact structure is less important than making sure that information is stored somewhere that you can find it. Oh, and make sure you back it up, too. All the documentation in the world will do you no good if your hard drive goes belly up.

Creating documentation may seem like a waste of time, but I speak from experience when I say it’s worth it. Do it. Your future self will thank you, and anyone who follows in your footsteps will thank you as well.

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!

If you want to work in tech support, you need your own website (and if you’re already there, you should have one too)

I’ve been working in tech support for more than a decade now, but it’s not necessarily what I intended to end up doing. Instead, I kind of backed into the job.

When I started thinking in 2007 that I wanted a change from the crazy hours of working at a radio station, I didn’t have much other professional experience. What I did have was experience creating some personal websites, a familiarity with HTML and CSS, and it was that background along with a general knowledge of computers that landed me a position as webmaster for a small non-profit organization, and that ultimately led to my career in tech support.

I tell you this story because I believe that if you want to work in tech support, you need your own website. Moreover, if you’re already working in tech support but don’t have your own site, you need to start moving in that direction.

Want to work here? Where’s your website?

My experience with websites was indisputably a major factor in me getting my first computer-related job even though my background was almost entirely on personal projects, the only exception being a moderately lengthy stint maintaining the student newspaper’s website during my college days.

Could I have gotten that first job without knowing a thing or two about HTML and CSS? Maybe, but it would have been a lot more difficult to argue that I deserved the opportunity. My new boss gave me the chance, though, and I not only ended up maintaining and doing a lot of development work on the company’s website, my role gradually morphed into doing at least as much tech support as website work!

10 years down the road, I’m doing tech support for a different company. Instead of a non-profit, I now work for a company that manufactures fuel control terminals and the website used to manage the system. Yes, even now that I’m a “Technical Support Specialist,” I still deal with websites.

Now, I’m not saying that having a bit of experience working with your own website is going to guarantee you an IT job—far from it. I do think that not having that experience could hurt your chances of getting a job in tech support, though, especially if the next guy or girl does have that experience. Even the CompTIA A+ exam has website-related questions on it. The industry expects you to have that experience.

It’s not just for kids

But what if you’ve already been doing tech support for a couple of years? Do you still need to bother creating your own website? I say yes.

As I mentioned, in my current position, I have to provide support for users of the software (website) used to manage our hardware products. Although I’m not actively involved in development of the website, it certainly doesn’t hurt that I know my way around IIS, to be able to set up a local site for testing and so forth.

Furthermore, keeping up my personal website work is helping me develop additional skills and discover tools that are directly applicable to my job. For example, earlier this year I configured my own virtual Web server, and in the process discovered Linux’s tail command; since then, I’ve used that more times than I can count at work to monitor logs while troubleshooting. Sure, I might have eventually run across that bit of information, but I discovered it a lot more quickly simply because I have my own website.

Summary

If you want to work in tech support, having experience managing a website, even on a personal level, will at the very least put you on even ground with other folks trying to get hired for the same positions. If you’re already working in the industry, managing your own website (and maybe even a Web server) will give you valuable experience and might just lead you to make a discovery or two that will help in some other facet of your job.

If you don’t have a website, it’s time to get started.

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!