Editor’s note: ATM Network technicians have the experience to solve even the thorniest problems, and routinely go above and beyond to do so. This is one such story.
About a month after installing an ATM in a bar in western Minnesota, the machine stopped communicating with the transaction server, making transactions impossible. A tech went down to check it out.
The machine worked properly when it was installed, so the technician figured that a component must have gone bad. He replaced the communications cable and several circuit boards, including the mainboard, but it still didn’t work. So he called in our troubleshooting team.
The first thing the team did was re-replace everything, just to be sure. Nothing helped.
Then they examined connections. The bar had a local computer network. The machine was hooked into that, using the network’s Internet connection to transmit transactions instead of a dedicated phone line.
So they began to ask the bar owner questions: Had there been any additions or changes to the network? Any differences at all? No. Further, the owner’s computer used the network for Internet access, and it worked just fine. That suggested the problem was with the ATM, not the network.
Then the bar owner mentioned that he had installed some security cameras in the bar, and that they weren’t working, either. And come to think of it, the ATM had stopped working after the cameras were installed.
The team went to look at the cameras. They were hooked into the network so that they could send their images to the owner’s computer. But why weren’t they working? And how could they have affected the ATM but left the owner’s computer unharmed?
On the Internet, central computers called DNS (domain-name servers) keep track of the location – known as “IP addresses” — of everything connected to it. Think of them as a giant directory, listing the address of computers so that messages can be sent and received from them. If a machine isn’t listed in the DNS, it’s invisible.
Networks like the one installed in the bar connect to the Internet through a router. Each router does two things: it keeps a list of devices connected to the network, and serves as the gateway connecting those devices to the Internet. That way the DNS only needs to know the address of the router; the router takes care of distributing incoming and outgoing messages for everything on the local network.
There are two ways for a router to handle addresses for its devices. A device can have a fixed, “static” address that never changes, or the router can assign a new “dynamic” address every time a device connects to it. Dynamic assignment is generally preferable, because it doesn’t require manually setting addresses for each individual device. It’s managed using a DNS setting on the router.
A quick check showed that the cameras and the owner’s computer had static addresses, while the ATM used a dynamic address. Which was confusing, because of the two devices with static addresses, one worked and one didn’t. The problem wasn’t as simple as “static good, dynamic bad.”
Thinking it over, the team decided that maybe the problem was with the router. So they checked it – and discovered that the DNS settings weren’t enabled for dynamic addresses. As far as the ATM could tell, it was properly connected, but its communications were hitting a wall at the router.
The owner enabled the settings, and the ATM worked perfectly.
But how had the problem occurred in the first place? Remember that the ATM worked when it was first installed, then stopped working when the cameras were installed. And the cameras, despite being on static IP addresses, still didn’t work.
After another round of questions, it turned out that the camera installer inadvertently disabled the router’s DNS settings during installation, knocking the ATM off the network.
And the cameras themselves? They weren’t working because of a separate installation error. Their problem was totally unconnected to the problem that took down the ATM. But it *looked* related, complicating the diagnosis of the problem.
