Ask Slashdot: Best Way To Solve a Unique Networking Issue?

New submitter petro-tech writes: I work as a service technician, maintaining and repairing gas pumps and POS equipment. In my day to day activities, one that consumes a ton of time and is relatively regular is the process of upgrading the software on pumps. This is done by connecting to the pump via direct ethernet from my laptop, then running a manufacturer-provided program that connects to the device and pushes the new software. Some sites have 8+ pumps with 2 devices in each, and at 20-30 minutes apiece this can be quite time consuming. Unfortunately the devices are not actually on a network, and as such cannot be updated remotely, also since they are not on a network, they are all configured with the same IP address. Additionally the software doesn't allow you to specify the adapter to use. I would like to be able to get to a site, connect a cable to each pump, and load them all at the same time. The only way I can figure to accomplish this with the software we've been provided is to do this: Get a 16-port powered USB hub, with a usb-ethernet adaptor in each port; Set up 16 VM's with extremely stripped down XP running on each, with only one USB-ethernet adaptor assigned to each VM; Set XP to boot the application for loading software as its shell; and load each device that way at the same time. Is there a better way to accomplish this? Have a question for Slashdot's readers? Take a look at other recent questions first to see if someone else has had a similar question. And if not, ask away! The more details and context you include, the more likely your question will be selected.

Comments

It's not a networking issue.

[xxxJonBoyxxx]

>> Unfortunately the devices are not actually on a network

So...it's not a networking issue?

Re:It's not a networking issue.

[antiperimetaparalogo]

>> Unfortunately the devices are not actually on a network

So...it's not a networking issue?

No, it is a networking issue; nodes are nodes, even if not connected - what the guy does normaly is a network with 2 nodes, now wants more.

Re:It's not a networking issue.

[ArmoredDragon]

I think what he's asking is whether or not he can network them together even though they all have the same IP address. And the answer is yes.

As a network engineer, I can think of a way with a Cisco catalyst switch, OR, a linux box with multiple ethernet ports:

For a Cisco switch, get a layer 3 switch, enable ip routing, put each switch port on a separate vlan, create an SVI for each vlan that is on a /30 subnet using the first address of that subnet. Create an access control list so that all traffic that goes ingress to the second IP address of the vlan subnet has its destination address changed to the static IP address of the equipment and the source address changed to be the IP address of the SVI, and then change all egress traffic from the second subnet IP to change the destination address to match that of your laptop and the source address to match that of the second IP address in the subnet.

For a linux box you'd do the same thing, only using SNAT and DNAT in iptables.

Effectively what you're doing is creating a NAT table that allows you to uniquely address each device, without actually changing the IP addresses themselves to become unique.

If you're not very affluent in networking, the above will sound VERY confusing, but trust me it can be done.

Re:It's not a networking issue.

[g0bshiTe]

I think you like many are missing the main question and would in fact be the only question I'd ask him and it would determine if you should continue or stop right there.

Are you paid by the hour? If yes, what the actual fuck are you thinking?

Re:It's not a networking issue.

[ArmoredDragon]

I think you like many are missing the main question and would in fact be the only question I'd ask him and it would determine if you should continue or stop right there.

He offered me a problem, so I offered him a solution. I'm an engineer, I solve problems. He didn't ask for security (which this can be secured by the way, but that involves a bit more discussion, which I don't have enough information to counsel on.)

Are you paid by the hour? If yes, what the actual fuck are you thinking?

Have you ever heard of lean principles? Basically by reducing the number of steps it takes to perform a job, you reduce the chance of human error (thus increasing your product's quality) while also lowering costs. Managers who employ this technique love it when employees make suggestions like this that actually work.

Does his boss appreciate that kind of thing? I don't know, but if I was his boss, and he brought this kind of solution to me, that would gain him some extra brownie points. Instead of having him do that time wasting work, I'd maybe give him better jobs to do that may even pay more, if I had them available.

Re:It's not a networking issue.

[nblender]

Similar, but less complicated...

On a Cisco catalyst,

script this:

conf t
int g0/1
no shut

ping and program

shut
int g0/2
no shut

ping and program ... lather rinse repeat

Re:It's not a networking issue.

[un1nsp1red]

Basically by reducing the number of steps it takes to perform a job, you reduce the chance of human error (thus increasing your product's quality) while also lowering costs.

However, the chance of a human error borking 16 pumps at one time increases dramatically.

Re:It's not a networking issue.

[rudy_wayne]

I think what he's asking is whether or not he can network them together even though they all have the same IP address. And the answer is yes.

As a network engineer, I can think of a way with a Cisco catalyst switch, OR, a linux box with multiple ethernet ports:

Yes, there are a few possible solutions, but I'm surprised that nobody has mentioned the biggest barrier to implementing any of them:

Trying to connect to 8+ pumps at the same time is going to require running 8+ ethernet cables from a central location to each pump. You're going to have cables all over the place, and unless it is done while the gas station is closed it means people driving over the cables, stepping on them, tripping on them and yanking them out of the socket, etc........

Re:It's not a networking issue.

[Anonymous Coward]

As a network engineer, I can think of a way with a Cisco catalyst switch, OR, a linux box with multiple ethernet ports:

That's way too much complication for what he needs.... Assuming each pump has a unique MAC, all you need to do is a bit of work with ARP tables. Collecting MAC's should be easy, cable up and try and ping the standard IP address... They will all reply to the ARP request. Scrape up the MAC's, dump them into his Virtual Machines running the update software to map that MAC to that IP in the VM and make the assignment never expire. Do your update, the software is unlikely to know the difference... For this approach, you only need a switch/hub and network cables.

My other idea was to build a VM box with a separate network segment for each VM, then map these all though a Linux VM that puts them on an 802.1q VLAN. Go buy a *cheap* managed switch (and I do mean cheap) and create one trunk port with each other port on a separate VLAN untagged. No need for an expensive Layer 3 switch... In fact, you could set it up on a cheap consumer router running OpenWRT as long as the switch supports VLANs, in which case the most expensive part of the hardware would be the network cabling..

Re:It's not a networking issue.

[Krishnoid]

If you're not very affluent in networking, the above will sound VERY confusing, but trust me it can be done.

I think you mean 'fluent', as in you understand networking well. Then again, you could mean that this is expensive, in which case, 'affluent' would be correct. Although, the original problem refers to programming pumps, so it could be 'effluent'.

Glad I could clarify that.

Re:It's not a networking issue.

[mjm1231]

I used to tell this to my boss all the time when we had to make changes to all 500 PC's on the domain, and walking from PC to PC to do it manually was still standard practice. If I screw up with a script, at least they'll all have the same mistake, instead of 500 different mistakes.

Re:It's not a networking issue.

[spire3661]

You could fashion a wireless setup pretty easily. Plug Ethernet to wireless dongle into pump, done.

Re:It's not a networking issue.

[suutar]

It sounds like he's only networking them long enough to update them. He brings the hardware, plugs in the pump, does his thing, unplugs. He just wants to parallelize; de-networking the pumps is still a step.

Re:It's not a networking issue.

[rot26]

Is "when you do an action, ask yourself if it's something that you'll want to be remembered for" considered an action? ERROR: STACK OVERFLOW

Re:It's not a networking issue.

[TsuruchiBrian]

Are you paid by the hour? If yes, what the actual fuck are you thinking?

Because who wouldn't want to keep doing a tedious job over and over as long as the income is steady? /s

Even if this person is a lazy fuck (which I suspect he isn't), he still has an incentive to solve this problem. He could automate the software load for all the gas pumps (minimizing the amount of work he needs to do), and sit in his car playing cell phone games for the amount of time it normally takes to do it the tedious way.

It pays to be efficient whether you are a lazy fuck or someone who wants to get a lot of work done. Only dumb people waste their time.

Re:It's not a networking issue.

[TWX]

Basically by reducing the number of steps it takes to perform a job, you reduce the chance of human error (thus increasing your product's quality) while also lowering costs.

However, the chance of a human error borking 16 pumps at one time increases dramatically.

That depends on how much direct control the technician has over the pumps. If the technician doesn't really make any choices and is just conducting rote firmware updates or pushing out prewritten configurations then short of b0rking the process itself he can't do much to break them.

As for the process itself, I advocate a low-tech solution. Go get a bunch of older small Netbooks with ethernet jacks on them, set up a box in the van or service truck as the wifi controller, connect those netbooks to the wifi in the truck, and then connect the netbooks to the pumps. Use the box in the truck to control the netbooks, automate the process or at least add some scripting that makes it easier.

Re:It's not a networking issue.

[TWX]

Be careful, the Cylons can infiltrate computer networks. May be better to keep them separated.

Re:It's not a networking issue.

[gstoddart]

But the reality is from the description of this, the manufacturer has done a crap job of building the "networking" part of this, and if you start trying to be clever and hook it up to an actual network you might really fsck it up.

So, imagine some field tech decided he'd rather find a clever new way to fix things, and then hoses (pun intended) the pumps because he's doing something which the pumps can't actually be made to work with.

Who the hell do you think is going to fix it?

You can call it a networking problem, but I would suggest if the manufacturer has given them all the same IP address ... these things aren't designed to be "networked" in any meaningful sense of the word.

Do you really want to run the risk of fucking up the pumps because you think you have a solution which works?

Because setting up a bunch of VMs so you can hook them up in a clever way and try to do this in parallel sounds like you have a better chance of it going wrong than going right.

It may use some networking technology in a limited way, but it isn't a networked device ... from the sounds of it they use that networking port as little more than a serial connection. And if you start trying to connect them all at once with some fancy setup of your own, you have no frickin' idea how it's going to work or what will happen.

You don't want to explain to the gas station owner why he has no working pumps and why the company who makes them wants no part of what you broke by doing it in an unapproved way.

Re:It's not a networking issue.

[antiperimetaparalogo]

But the reality is from the description of this, the manufacturer has done a crap job of building the "networking" part of this [...] You can call it a networking problem, but I would suggest if the manufacturer has given them all the same IP address ... these things aren't designed to be "networked" in any meaningful sense of the word. [...] It may use some networking technology in a limited way, but it isn't a networked device ... from the sounds of it they use that networking port as little more than a serial connection. [...]

Since i agree with everything you write, i keep only the parts of your comment i want to reply to: yes, it is a frivolous and impractical network... but it is still a networking problem/issue!

Re:It's not a networking issue.

[vux984]

I used to work as a field tech, back in the day.

Yeah, "back in the day". Welcome to the new age of gps in trucks, and in company issued phones with fleet tracking.

Re:It's not a networking issue.

[Gr8Apes]

the manufacturer has done a crap job of building the "networking" part of this,

Actually, the manufacturer has done an EXCELLENT job of building the "networking" part of this. Hacking into this remote is going to be very problematic! Think of the built in security! Maintaining it, however, is a different story.

Re: It's not a networking issue.

[rickb928]

Professional Engineers do indeed have a code of ethics. Ask the NSPE.

But there are few network engineers that qualify as Professional Engineers. A P.E. is licensed and/or registered, and mostly a graduate of an engineering school.

Cisco certifications are demanding, but I doubt they qualify anyone as a P.E.

Re:It's not a networking issue.

[Anonymous Coward]

I'm not aware of any code of ethics.

http://www.nspe.org/resources/ethics/code-ethics

http://www.ieee.org/about/corporate/governance/p7-8.html

http://courses.cs.vt.edu/professionalism/WorldCodes/ASCE.html

http://en.wikipedia.org/wiki/Engineering_ethics

Now you are.

Re:It's not a networking issue.

[msauve]

Using the AC power outlet conveniently located next to the pump? Or that the pumps provide PoE? And, you'll need dongles which retain their configuration and an AP which is configured with a different SSID for each. After that, you still need the switch/NAT stuff which makes it even possible.

Better to simply buy 8 $100 used laptops off eBay, and use one for each pump.

Re:It's not a networking issue.

[MooseTick]

"Are you paid by the hour? If yes, what the actual fuck are you thinking?"

Perhaps he is thinking he can get a week's worth of work done in 2 hours. Assuming he didn't bother telling anyone about his new technique, he can now go play golf or nap the rest of the week while the boss thinks he is "hard at work".

Re:It's not a networking issue.

[Darinbob]

Alternatively, you could say the manufacturer has done a good job of eliminating networks as a source of malware.

Re:It's not a networking issue.

[Darinbob]

The maintenance is usually built into the cost. Plans during design may have been for 1 firmware patch/upgrade a year. However in practice this may change over time.

Or they factor in the cost of manpower to walk around to each pump and upgrade them versus the cost of adding in a network and the security subsystem to deal with a network and the cost of back office support services to manage the network and security issues, and then decided that the flunky with a laptop is the better solution. Sure, I agree it's not good to be the flunky in that case, but it's how so much of the world works.

Re:It's not a networking issue.

[cusco]

There is an answer to this, I've done something similar with security devices. Ideally you would use a hub, if you can still find one, rather than a switch. You'll need the MAC addresses of each pump first, well use 00-12-34-56-78-9A and 00-12-34-56-78-9B. Set a fixed IP address on your laptop, for example 172.16.16.16, and turn off your wireless. Open a command prompt as an Administrator and enter:

arp -s 172.16.16.20 00-12-34-56-78-9A

arp -s 172.16.16.21 00-12-34-56-78-9B

Now your laptop thinks that you have pumps at address 172.16.16.20 and 172.16.16.21. Enjoy your extra time!

wow, that makes me feel good

[phantomfive]

Unfortunately the devices are not actually on a network, and as such cannot be updated remotely, also since they are not on a network,

It makes me feel good to know that something in this world is still air-gapped.

Re:wow, that makes me feel good

[Anonymous Coward]

They aren't actually air-gapped. They are on a two-wire control network with the POS device - which is why the dispenser (NOT PUMP) can be stopped remotely from the POS. It is also how price changes, pre-authorizations (I want $20 on #7) are done. But that network doesn't allow firmware updates, just control.

The original submitter probably doesn't know much about these if he calls them pumps. A station has only one pump per grade of fuel (although in some rare cases of multiple tanks even when they are connected together they may have 2 pumps per grade of fuel). The heads that people call "the gas pump" are dispensers only. They don't create the pressure that generates flow. He is reprogramming / flashing the dispenser control heads. It is normal for the ordinary consumer to call these things "gas pumps" - but people who work in the industry generally know better and would call them dispensers.

Re:wow, that makes me feel good

[uncqual]

Although, perhaps the original submitter called them "pumps" rather than "dispenser control heads" because they assumed that was what most /. readers would understand. Generally it's best to communicate in the language your audience understands unless it confuses others -- and you, allegedly knowing how these things work, seem pretty confident that you understood what the submitter meant. Mission accomplished.

Re: wow, that makes me feel good

[phantomfive]

Oh but don't worry, they're secured using the NetUSB driver!

If the headline is posed as a question, the answer

[rwa2]

... is no.

The thing you propose sounds fine. But do they really want to upgrade all of the pumps at once? Sounds like a great way to brick an entire facility.

The only "improvement" I could think of would be to set up some kind of cheap router that can do MAC address filtering, that way you can set up the router to allow only one of each pump to show up as that one silly IP address at a time on a switched network. But then you'll still be able to only do one at a time.

The "right" way to do this is just throw money at the problem and attach a real computer to each pump, with a separate interface to talk to the static IP. Maybe something as small as http://www.fit-pc.com/web/prod... or just some generic mini-ITX board in a telecom chassis or whatever.

Solution

[TooMuchToDo]

1) Get a managed switch
2) Configure all ports but one to be on their own VLANs
3) Configure one port to be a trunk port
4) Configure your laptop or other computing device to support trunking
5) Configure your virtual machine so the entire process is scripted. It should boot, execute the upgrade procedure, and then provide logging for the process to you.
6) Start VMs, with each configured on one of the VLANs.

Done.

Easy!

[WPIDalamar]

Get 16 laptops.

Re:Easy!

[Kohath]

Crappy used laptops are cheap. You don't need 16. You need 4. The first one will be about done by the time you get the 4th one started.

Re:Easy!

[Minwee]

And then the Intern goes to Ask Slashdot, and we start the whole thing over.

It's some kind of Internception.

Probably the way

[phantomfive]

The only way I can figure to accomplish this with the software we've been provided is to do this: Get a 16-port powered USB hub, with a usb-ethernet adaptor in each port; Set up 16 VM's with extremely stripped down XP running on each, with only one USB-ethernet adaptor assigned to each VM; Set XP to boot the application for loading software as its shell; and load each device that way at the same time.

That might be the best way, because you are limited by the software they gave you. Might consider trying Linux and Wine to save space. If that works, then you can load 16 raspberry pies into a briefcase and run it from there (I've seen similar operations for wireless monitoring).

If you actually do build that setup, please take pics because it sounds kind of cool.

KISS (Keep It Simple Stupid)

[Ariastis]

Go on FleaBay and get a few older laptops for dirt cheap ; set one up with your software and copy it to all the others.

You can now do thay many pumps at once, and if one has a problem it wont screw up the whole lot.

Arduino to the rescue!

[RecursiveLoop]

Create 8 battery operated arduino's whose sole purpose is to translate and then broadcast the single IP Ethernet to unique IP on a wireless network, run a local ap, then I'm sure there are apps/scripts that will allow you to sandbox the OEM app allowing the reversing of the IP translation back to the original and running multiple concurrent independent instances(no VM required), i did this with outlook prior to it allowing multiple exchange accounts, although didnt tackle the ip routing. Then sit back and get fat while you compete you full days job in an hour.

Re:Why not just...

[DutchUncle]

In the problem specification, it says that the devices have the same IP. Maybe the installation program relies on this. Since it's an embedded system, changing it may not be possible. OP has to deal with the situation as it is, and "change the situation" is not a simple option.

Don't

[HornWumpus]

If you fix this problem they will more then likely fire you. Nobody likes a smart-ass. They know what your time is worth, likely not much. Just do it the slow way.

Seriously, you are an upgrade monkey.Just monkey on and look for a better job where you can use your skills and you will be _paid for them_.

Alternatively: If your employer is contracting to do the upgrades, figure out how to do it in 25% of the time and take the business from them. They don't own their clients, but likely think they do.

VLANs are your friend

[Mr. Sketch]

I think you could configure each port on the switch with a different default VLAN and plug those into the terminals (e.g. Port 1 gets VLAN 1, Port 2 gets VLAN 2, etc). That will by default separate each port into a separate network. Then use VLAN tagging on your XP VMs that you were going to spin up, so they each are effectively connected to a separate port on the switch (e.g. VM 1 is tagged for VLAN 1, VM 2 is tagged for VLAN 2, etc).

This is just the high-level details of what you'll need to do. Most lower-end consumer grade switches don't have VLAN support, so you may need to spring for a better switch, and make sure your VM software supports VLAN tagging.

None of these solutions "work"

[mschuyler]

OP said "day to day" activities. He's updating one pump at a time. What are the other pumps doing? Dispensing gasoline. To update all 16 pumps at once would render all 16 pumps out of service for half an hour. That is simply unacceptable for the station. They would not want to just shut everything down and eliminate a half-hour's worth of revenue from 15 pumps just so OP is not inconvenienced.

This is a typical IT viewpoint. We have a technical problem to solve, and to hell with the users. They're just in the way of our supreme elegance anyway.

Re:None of these solutions "work"

[FalcDot]

You are quite right.

Then again, he also mentions that "some sites have 8+ pumps with 2 devices in each".

Just being able to update both devices in a single pump should already cut his worktime in half, while having two stations down instead of one should not affect the business very much.

Re:follow defined procedures

[Adriax]

Yup. A bunch of cheap single boards with ethernet would work. Like raspberry pi.
Strip down the OS and script it to push the update from a given directory on boot up. Then you can just clone the SD card for 4/8/16 devices and update them with the new firmware as needed.

Pi, case, battery with power switch, small SD card. $50-$75 a piece depending on how fancy your want to get with the case and battery.

Re:Why not just...

[hawguy]

Except, you know, saying that they are all using the same IP.

Yes, that doesn't 100% lock in the use of TCP, but in 2015? You can pretty well assume that we're dealing with TCP/IP, and the asker can offer additional information if this isn't the case.

Lots of devices still use TFTP for firmware updates, so the pumps could be using UDP/IP rather than TCP/IP.

Re:If the headline is posed as a question, the ans

[Andrewkov]

Not only that, the gas station may not want more than 1 pump down at a time.

Re:What will you do with your free time?

[f205v]

I do fully subscribe to this point of view. If you solve the problem for cheap, test it a couple of times just to be on the safe side, and then SELL THE SOLUTION to your employee.

Re:Why not just...

[Minwee]

Is there anything that uses Ethernet without using */IP?

I'm not even going to start answering that, but I am curious about one thing.

Which major corporation are you the CIO for? Please be honest, as I stand to win $20 here.

ToTo, I don't think we are on Slashdot anymore.

[GrantRobertson]

A competent, helpful answer in the third post.

Re:Why not just...

[sjames]

ATA over Ethernet for one. If it's running over a private network also used for management the second question is also yes.

Why make it less secure?

[Etcetera]

Dear Lord...

You have an airgapped network that prevents remote access, reducing the question of security to one of physical security... which is typically handled with big locks, cameras, 24 hour staffing at the gas station, and maybe men with guns if it comes down to it.

Why would you network these together and create an avenue for simultaneous, surruptitious hacking and attacking of your industrial equipment?

Be thankful you have a job, and don't let the SysAdmin's (natural, and usually good) desire for laziness and efficiency to lead to a future security issue justified by convenience.

Cakewalk

[Spazmania]

Get a switch which supports VLANs, 1 vlan on each port and the trunk on your laptop. Then run the mfg's software inside virtual machines, each of which has one of the vlans connected to its virtual ethernet, using the mfg's IP address. Now you can run all the updates in parallel.

The better solution is for the mfg to give you software and a configuration that does not suck. But if you're stuck with it, the above will work just fine.

...oh, and can anyone recommend an exacto knife?

[aaarrrgggh]

Sometimes, for diagnostic purposes I also need to add a second read head to the credit card scanner. It would really be helpful if I could add this to the network, along with the keypad's diagnostic port. Any ideas?

In all seriousness though, there are some real fire protection issues with taking cables from the pump zone elsewhere. Everything in and out needs to be properly sealed to prevent explosive vapors from entering into a non spark-resistant system.

Obvious solution

[mjm1231]

I can't believe nobody has posted the most obvious solution yet. Upgrade to IPv6.

Re:Why not just...

[RatherBeAnonymous]

Yes. I worked with a 3com phone system that ran on bare Ethernet.

Just get paid by the hour.

[jpellino]

Instead of by the device. Problem solved!

What's the best way to sharpen my football bat?

[netsavior]

I am having trouble with my billiards table, could you please tell me the best way to keep my football bat sharp so that my chlorine levels stay consistent?

Re:If the headline is posed as a question, the ans

[jittles]

Besides, if you can do it in 1/16th of the time, you might find your maintenance budget get slashed to 1/16th of previous year/quarter. From what you described, it seems you/they allocate about a day to upgrade each station (16 units at 0.5 hour each.) Beats driving around in traffic to 16 different stations a day, too.

Don't be silly. The maintenance will still take just as long. He'll just have much more time to focus on his real priority - Clash of Clans.

16 netbooks

[Bitmanhome]

Why 16 VMs? If you're looking to learn VMs and/or advanced networking, then sure go that route. If you're just looking to save some time, just get 16 old laptops or netbooks with ethernet.

You're offtopic but I'll answer anyway.

[Medievalist]

Is there anything that uses Ethernet without using */IP?

Yes, tons of stuff. Dozens of protocols.

Is there anything that uses Ethernet without using */IP that also uses IP addresses??

Yes; there are a number of "companion" protocols that interoperate with IP when it's on an ethernet. You've probably heard of ARP and ICMP, to give just two examples. Neither of those is actually part of the Internet Protocol, and they don't ride over it, but they do use IP addresses on an Ethernet.