Slashdot Mirror
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.
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.
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.
>> 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.
Antisthenes: "Wisdom begins by examining the words/names." - excuse my English, i am (slightly...) better with my Greek!
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.
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.
I'm pretty sure you can't run Wine on an ARM processor. Maybe you could run x86 Wine through QEMU on an ARM processor, but that's starting to sound crazy pants.
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.
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.
Lost at C:>. Found at C.
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.