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.
>> Unfortunately the devices are not actually on a network
So...it's not a networking issue?
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.
"First they came for the slanderers and i said nothing."
App apps on the apps to app apps and app other apps!
Apps!
... have each device IP'd different and come in with a switch and plug them all in at once, since they aren't really networked anyway why does it matter what the IP is?
Seems like if you had more than one device or virtual devices, and more than one ethernet cable on more than one ethernet port, you could stagger your installs.
- Zav - Imagine a Beowulf cluster of insensitive clods...
... 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.
I have no clue how you would manage that in Windows, but I would think it would do the job somehow.
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.
Get 16 laptops.
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.
"First they came for the slanderers and i said nothing."
How about getting a managable switch, assign a different VLAN to each port. Then have one port connected to all VLANs and connect your XP VMs to different VIDs. Should at least save you the hassle of using 16 usb dongles as well as the USB hub.
Let's pretend we solve your problem and now you can update all systems at once reducing a day's work to 30 minutes.
Are you getting paid by the hour?
What will you be able to do in your new found time?
It looks to me like you are solving a problem with zero benefit to you. You didn't create the inefficient system you are required to work and improving it won't help you.
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.
not really, what your really talking about is "doing the right thing". what i mean is that a short cut would be to connect everything to a network and basically brake the security of the Air Gap, also your idea may fail because the VM software will have to do Time Sharing with the limited cores of your laptop. witch at time may make some vm machines look like they are Frozen. and also Even Ram maybe a issue two. but good luck anyways.
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.
You need 16 Netbooks. Hookup one move to the next one. KISS is the way. Next problem /.?
You might be able to use an Ethernet switch with VLANs instead of a USB hub. Configure 16 VLAN IDs, then in your VMs configure the VLAN ID in each VM's network connection.
Since the manufacturer does not support choosing the NIC you'll be updating on, using a VM solution would be the most direct for allowing your updates in parallel. The downside is that as a previous comment said, it's a risk of bricking an entire facility at one time so you may consider doing one isle of pumps as a time and testing.
If the pumps are not designed to be on a network and simply using Ethernet as a faster way of updating/reading software then adding in a switch with MAC address filtering, etc. might be a moot point. However, if the pumps truly are network aware, or using DHCP, you could consider a small switch and LAN running with your notebook as a server.
I guess you could throw each one behind some sort of NAT router; maybe something like a Raspberry Pi, so that to the actual LAN they each have a unique IP. But even going for a low end computer-on-a-stick solution, you'll need a second USB ethernet adapter, or ethernet-to-WiFi bridge, not to mention it sounds like they are still air gapped, so can you reasonably get cabling to the pumps? So you're talking here about 20-30 NAT routers plus cabling. A big cost, with some security implications that need to be thought out.
Have you thought about talking to the vendor?
The world's burning. Moped Jesus spotted on I50. Details at 11.
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.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
- Use a managed switch that supports adding VLAN tagging
- Forward VLANS to your Windows machine, create virtual NICs for the VLANs
--> now you have separated the pumps on VLANs, each of which your windows machine can talk to
- Start the updating program multiple times, each with different firewall settings such that each instance talk on only one VLAN .exe multiple times
- Its probably enough just to copy and rename the
Connect all to a switch & set each switchport to its own VLAN. bounce your laptop from vlan to vlan upgrading.. or trunk all vlans onto your laptop port and use VM's or something similarly silly tagged to each vlan on the trunked port to access multiples at the same time.
Or inquire with manufacturer fi the devices can be re-ip'd...
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.
Things you think are in the Constitution, but are not.
Instead of trying to centralize the operation and running cables all over the place, you should be thinking about distributing the task. How much horsepower and/or interaction does this updater app require? Why not look at getting a bunch of cheap/small computers for this task like a Raspberry Pi or a NUC or something? Seems to me, that you could even design something that would approximate an embedded solution. Maybe even add an LED that turns green on completion. Then just carry around a mini keyboard/trackpad and a battery powered portable monitor in case you need to interact with any of the computers.
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.
How about a moderation of -1 pedantic.
Depending on the restrictions in the downloading software, you may be able to get away with adding manual entries into the arp table (arp -s). Once you know the mac address, try to add an arp entry to an alternate address. Since you don't actually need routable IP addresses this may work with just a simple L2 switch. This trick has been used for a long time for initial configuration of printers and serial converters.
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.
I don't suffer from insanity, I enjoy every minute of it!
Why worry how long it takes? You get paid by the hour, correct?
Chances are, if something goes wrong and they find out you were not following their procedures you will be out of a job.
Not only that, the gas station may not want more than 1 pump down at a time.
Are you paid by the job or by the hour?
What type of idioticly designed pump takes half an hour to run a software upgrade?
Let me guess: Some useless manager thought it'd be easier to stick a full-fledged PC running Windows inside every pump than it would be to hire someone who can do proper embedded software development?
All the pissing matches about IP access for gas stations were covered in a past post.
http://it.slashdot.org/story/15/01/23/1856201/us-gas-stations-vulnerable-to-internet-attacks/
plug each and let them loose?
Basically what I wonder is if although the units are locked down to a specific IP is the software used to do the uploading?
If not, you can use arp to give the machines a new IP against their MAC addresses. Then run multiple instances of the install software and point at each IP.
https://technet.microsoft.com/...
That's exactly what I came here to say. Why this would save OP time...it will cost the station money. The current setup means one pump is down at a time. His proposal means all the pumps at the station will be down, or even if he is more responsible and does half and half, half of them will be down. This is unacceptable from a cost-benefit perspective (no way is his time savings worth the loss in sales) and from a customer service perspective. Just forget it and bring a book. You're getting paid, right? Unless you are paid by the job and not by the hour or salaried, it isn't your problem.
How about ethernet to wireless for each pump, a wireless radio, a good encryption setup, and one of the vlan or vmware solutions mentioned above? This assumes the pumps function during upgrades, and that wireless security is an acceptable employment risk.
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.
If you could automate the process of connecting and disconnecting ethernet cables physically then I assume the networking issue would be settled?
You might consider using servos to unplug and plug cables into a switch.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
Pump Jockey! Works for tips!
.
Curious how the pumps communicate with the POS system in the office, some other type of network? Too bad the updates can't be sent via that network.
This might half the time required. You say you have a VM already on the laptop. Get a handful of external ethernet adapters. I think the best number will be in the neighborhood of 4, but learn with 2.
Run the VM and have one adapter present in each VM. Connect to device inside the pump. Start the next VM. etc. This is still a 2-node network, each instance will have a "fail safe" in an error will stop the one instance. With a typical gas station having 2 double pumps per island having 4 connections means one island at a time. 2 connections means 1 double pump at a time.
Best part is the headache is all in the VM working properly, and should be transparent to the software and to the pump. I am sure you have a training system to practice on before taking this live to the field.
Laugh, it's good for you!
Is rather vague. Do do you have to physically stay connected the whole time, or can you start the upgrade, disconnect and repeat then cycle back to confirm success? WTF is it doing that it takes 20-30 minutes?
Security hasn't been mentioned, and is rather important. Principally, I would want to know about (a) the regulatory requirements and (b) the risk of whatever security controls you would put in place (e.g. the loss potential) versus the value gained.
All of that said, if I owned a company doing what you described, I would certainly investigate options six ways from Sunday to find a better method, and I would suspect a better one than what you described is possible.
A competent, helpful answer in the third post.
Work on this idea on your own time, patent it and then sell the idea to the company that you work for assuming you don't want to go through the hassle of marketing it yourself. Otherwise all you are doing is donating your time to the company you work for. Document thoroughly that you did this on your own time. Don't ask for help from any colleagues or special consideration from your management. That way when the company threatens to confiscate the idea, you have your ass covered.
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.
Hire a Linux system administrator, systems engineer,
didn't see this in the initial description, but where are the ports you're connecting to? Are they wired back to the station, where you have a panel to jack into, or do you have to stand at each pump with a cable and a laptop? If it's an active station, standing there, with 16 cables draped along the pimps may be another logistical issue.
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.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
You know I'm all for open source but if you have a proprietary system that's vendor supplied, contact the vendor.
Make it a time/cost/material problem...
Yes, there is a technical work around for this, but if the firmware update is this half-assed you have other issues.
"Don't fear death... fear not living..." -me
Uhhh.... what you suggest is probably not a benefit overall...
Running a few VMs on a laptop is already a resource constrains... even if you run a minimal setup of XP, you'll still have a horrible time trying to power on 8 VMs.
I have done this on a MacMini before as I tried to simulate a network for a program I wrote, and I literally had to return the MacMini for a swap with iMac having top configurations.... Still had a horrible time with 12 nodes
Regardless how powerful your laptop is, I dont think it can do 16VMs at a time.
Then I would play with ARP cache.
Hopefully each Pump has own MAC address (but can have same IP) and you have list of these addresses connected to switch. Then go one by one specifying each MAC address for same IP and do software update. Then flush ARP, set next MAC for IP address and repeat. So your computer wouldn't do ARP lookup for IP address but manage it "manually".
Running multiple Windows'es on Linux VM you could do multiple updates at once. But that would need ebtables to allow each VM to talk only "own" Pump's MAC.
This would not need managed switch but just one Linux laptop with Windows'es on virtual machine. But if you can have managed switch then VLAN's would be perfect.
Good luck and tell what solution you decided to try.
Br, Henri
not a central one at this point. I will bet you a gallon of Ethyl that the pumps have hardcoded authentication, and the software probably has enough holes you could drive the Indy 500 through.
you don't want that on a network. not even for a little bit. you want that locked behind a panel. if there is no security, all you have is obscurity.
if this is supposed to be a new economy, how come they still want my old fashioned money?
bridging capability is built in, and if used with a managed switch...
https://docs.docker.com/articl...
I've built a fair number of hypervisors, both VMware and Hyper-V. The hardware required to run 16 VM's concurrently is quite substantial. Good luck running 16 instances of Windows XP on a laptop!
If these pumps have credit card readers on them, please be aware that there are substantial regulations such as Payment Card Industry (PCI) standards that apply. Any integration will need to have adequate security to fully comply with those standards. See https://www.pcisecuritystandards.org/
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.
If you ask me, I'll create a single Linux VM, with all USB net lab cards attached to the vm, and the with Linux few routing tools it can be used as a router to broadcast a the data to all of them in parallel. This way you'll need a single windows app, a route to the VM and a single click.
You'd need a configurable switch, which can run a couple hundred dollars. THen you can put each port of a switch on a seperate VLAN. Should work.
I'd just order a bunch of cheap laptops off ebay. evening having 5 or six of them.
sounds like a SCADA setup and truthfully these devices should never be connected to a network in the way you are suggesting. Mainly because this opens them up to outside compromise. Take a step back and look at this from a security point of view... these pumps control pressure in a line, or control how much two chemicals mix or control a system. When they were conceived networks existed, definitely networks exist today... so why not just get rid of your job and push all these updates via netowrk at 3 in the morning like normal companies and fire the 50 technicians that speed hours updating them manually?
Because manual updates close so many security holes it should not be thrown away.
Is there any reason you couldn't buy multiple single-board computers capable of running a minimal XP install? You could set each device up so that it could boot, and directly initiate the software update. You could then just plug it up to a pump, start it up, and then move on to opening up the next pump and starting the next units. I'd be that with only 5 or so units, by the time you get to the 6th pump, the first unit would be finished with an update. And I think this would probably take less time than it would take to open up and wire up all of the pumps to do it at once.
All the pumps have the same IP address. Also, software incredibly unhelpful.
IMO they should've used something actually designed for point-to-point connections, like firewire if serial is deemed too slow. Since they didn't, up to them to unfsck their thoroughly fscked nondesign. The only real solution is for the manufacturer to get its head out of its ass, so complaining to them is in order.
You assume that they're a 24 station. Many stations (particular those at grocery stores, etc) do not operate 24hr, so it's feasible - possibly even likely - that the updates are being done during the off-hours.
Network the pumps. Push the software one at a time. Lay off the tech. Problem solved.
How about a moderation of -1 pedantic.
" 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."
Some have suggested VLAN's as a solution. What that means is Virtual Networks. Essentially giving each pump it's own network switch, but only having to use one actual network switch to do it.
But you said the reason they all have the same ip address is because they're not networked. So network them and give them different ip addresses. Whether you have to statically configure them or can do it via DHCP. Now you can communicate with them all through one adapter. Problem solved.
No need to create a VLAN or a 16-port USB hub. If the problem is that they're not on a network, then put them on a network.
Now one might complain that now these are no longer air-gapped. But there are 2 counter-points to this: 1. they still are air-gapped from the internet. they're simply no longer air-gapped between each other. you still can't access them remotely one still needs physical access. 2.) any other solution, vlan, usb hub, etc., also removes this air-gap between each other pumps, they're just more complicated.
So first problem solved. You now have only one plug.
Second problem - automating pumping out all the software. Well if you could specify the destination ip address through command line, you could easily script it. Failing that, there's always the fall back of recording high-level macros. as in mouse button clicks and keyboard clicks. just google "macro recorder". Record one session of software updates, done. then you just plug in your computer and run the macro. done.
Having said that, there is that concern of bricking all your pumps at once. There is an advantage of putting a human in the loop, even if that means its slower and less efficient. I'd say whatever you do - test and verify on a single pump first.
And also know that if you make it easier to update the software, you're simultaneously making it easier to do so maliciously (or more likely, cause harm accidently).
(no way is his time savings worth the loss in sales)
Even at stations that have lines at certain times of days, there are hours where they are nearly empty. Your "no way" case would be more of a rare exception, where he would still have a chance to default back to the other way (or maybe even just two pumps, which would halve his time). For other places that sit mostly empty at least some time of the day, they would save money, especially since if they truly need every pump they have at certain hours, it wouldn't be taking him all day and would be less likely to need to take one down during rush.
Just because there may be a faster way to do it does not mean you should do it. One commented mentioned the entire system being down for the entire duration of the upgrade. That would be a no-go as far as the customer is concerned. One pump is a manageable inconvenience, half is inconceivable, all is grounds for termination. Gas stations sell more than gas, and those pumps draw people into the stores attached. Let's say you can get the process down to five minutes somehow, and the customer is actually on board with this. You do have the risk of bricking an entire station at once now. Stuff happens when upgrading firmware. Five minutes turns to thirty. Good uploads get interrupted. Shit happens. Lastly, why would you want to reduce your hours of billable time? You figure out a way to make your job part time and it will become part time, or part of someone else's job. Had it happen once. Literally worked myself out of a job.
I can't believe nobody has posted the most obvious solution yet. Upgrade to IPv6.
Ideology: A tool used primarily to avoid the bother of thinking.
Hello-
If the 16 port switch is a SMART switch, you can, make the last port a TAGGED port, that carries tagged vlan traffic.
Make each of the other ports (except number one) an UNTAGGED vlan. (keep number one stock so you can access the switch!)
Maybe reserve one for the windows box.
Then, on your computer, run a linux instance with vlans configured, like eth0.2, eth0.3 openwrt would be great for this, you can run it on a little router or a VM.
On the linux box, (openwrt) set up address translation with DNAT and SNAT to make the same IP on each of the VLANS appear as a unique IP on the same network as the windows box. (There's a little voodoo because you don't want any routing to happen, since you have several networks with the same address scheme.) Then, you can run upgrades simultaneously to several different IPs on the windows box (if it lets you) and the physical box it goes to will just depend on which port it's plugged in to.
This VLAN trick is a great way to fake having a whole bunch of network cards in a single box, even a virtual one.
=Rmortyh
Raspberry PIs with cross-over cables.
Every one of them with the same scripts. Buy 10 of them. By the time to finish hooking up the last one, the first one will be done.
So he's going to run up to 16 cables to 8 peds of 2 pumps each...? I guess if you're OK with doing that each time, sure...
Also, if it's only you/your company doing these, why can't you change the IP's on the pumps? Sure, if there was some other application or device needing them to be on a set IP, that would nix that idea.... but as said... they're not networked anyway.
I had a sucky sig.
Instead of by the device. Problem solved!
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
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?
Working in the PCI compliance industry I just wanted to point out that you don't want to tell your QSA about this. Violates most of the safeguards that the PCI DSS standards are their to provide. Good luck!
Can you run multiple instances of the application? In that case, this (or a similar application) could be helpful. The idea is to make every instance to use a particular interface. I also thought that maybe, if the application can be run using wine, you could lunch multiple instances on a Linux box, each one using a different network configuration, but seems that it's not possible.
Open Source Network Inventory for the masses! Kuwaiba
Have someone that installs the card skimmers do this for you.
What manufacturer is this? When I dealt with POS interfacing with Tokheim and Gilbarco pumps (including the MPDs) all the smarts was in the controllers and the modules of our POS software that ran the pumps, card readers (Petrovend units for non-MPD stations) and RF tag hardware. The pumps were relatively dumb and only required software updates when the physical hardware was modified, and we could do the software bit while the pump was down anyway for the physical work. Most "software updates" were just changes to the database tables that told our software how to react to events and what settings to send to the pumps for mix ratios, prices and so on. Your description sounds like you've got a good chunk of the POS system actually running in the pump itself.
Buy a few micro-factor PCs, install firmware flash software on each. Use Wi-Fi to remote into each one using the laptop.
Also "In my day to day activities, one that consumes a ton of time" -- is that billable time? Because then you'll be losing money by optimizing the process.
... and don't wait for one to finish before starting the others.
Consider this: They're paying you to spend a full day at each gas station doing firmware updates. If they care about the time it takes you should be able to get them to spring for a bunch of laptops so you can load all the pumps at once, properly, without resorting to VMs and trickery. Issuing you 16 laptops so you can do three or four stations in a day is a hell of a lot cheaper than hiring three or four more technicians as babysitters. Argue your case from that perspective and don't bother with the half-ass solution. If they don't go for it, then find a good book and keep doing it one pump at a time. They've decided that you're worth the expense.
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.
I think you need to re-think that.
First, I don't believe they aren't networked. They can tell inside at the register what the pump is doing so that tells me they ARE networked. Non-networked devices wouldn't need a IP address. You should have no problem doing this remotely. They many not be public facing, but that's not the same as not networked.
Post all the details of the hardware and how you get into them, and we will see if we can come up with some good options for you.
Network address translation.
The most elegant way to do it, is to buy a potentially expensive smart switch that can do all this for you in a compact and efficient. You may have to do some research on how to configure it properly.
The next best way would be to build a PC with a bunch of NICs and basically build the switch from my first suggestion. It's probably even more effort to configure it. It may be even more expensive if you need to buy all the parts new, but you are more likely to have these common parts or know someone who does, and they can be old.
The way that requires the least technical know-how but might be the most MacGyvery, ugly, and fun, id to get a bunch of old routers (one for each pump). Set the DMZ address of each NAT router to be the fixed IP of the pumps. Configure the wan addresses to something like 192.168.0.1 (for pump 1), 0.2 (for pump 2), etc. Then hook all the wan ports on the routers to a big switch along with your laptop. And hook up each pump to one of the lan ports of it's corresposnding NAT router. And bingo, you are on a network where each pump has a different IP address.
The downside with this last one, is that you have a lot of points of failure. Old routers are not known for being very reliable. The good news is that they are cheap, and you don't need the wifi to work. You don't even need them all to be the same make/model.
Get a 16 or 24 port managed switch that supports vlans (you need a port for each pump plus your laptop)
Put each pump in a separate vlan
Use a descent laptop with parallels or VMWare workstation
Run X number of machines to run the upgrade, each connected to a different vlan (trunk the vlans to the VMs through the laptop NIC (maybe use a USB nic)
Get a little fancy and see if you can script the running of the upgrade so when the VM starts it automatically starts the upgrade process.
Another option that could be wireless would be to use a device that supports multiple SSIDs like a Mikrotik router with wireless.
Each SSID would be a separate vlan/separate pump.
On the pump side use a similar mikrotik device to bridge the wireless and ethernet port. (you might be able to use something like a Raspberry Pi as this client device)
Let me start by saying that I have no real experience with solving networking systems. I do, however, have plenty of experience with network problems. With that out of the way. . .
What if you connect a router to each pump (that's 8 cheap routers I guess), each NATing it's pump. Then you can configure each router with a different IP address of your choosing. A ninth router (or a switch) connects your laptop to the 8 routers as a network of 18 nodes (8 pumps behind 8 routers, a switch, and your laptop). All ethernet, a normal network, your laptop addresses the "outside" IP address of each of the 8 routers.
I picture you with a rack of 8 routers, a switch at the top, your laptop, and a whack of ethernet cables.
Something's wrong. Obviously, the pumps are new enough to use ethernet to be updated. Also, the pump's computer seems to be powerful enough to support an IP stack (they are all using the same IP, so they are using an IP, ...but this may be speculation (maybe the IP doesn't do anything and just happens to be the same because it doesn't matter).
How big are such updates, that they take 20-30 minutes over ethernet? What kind of slow storage is used inside the pump? What kind of slow protocol is used to exchange the data (send everything back and forth a couple of times for verification)?
Twisted pair ethernet is isolated at both ends. That's what the little black block on the card is, an isolation transformer. It's analogous to what used to be called a 'balun'. So, there are no ground loops, and while I believe it may be possible to make a spark, it would be very unlikely and also very low power.
Certainly no worse than the existing upgrade connection.
I assume anything this guy is wiring is TEMPORARY while he does the upgrade. Either way, that's a lot of cables!
It's not great... It's pretty awful actually, but it's about the best you can hope for if you can't get a software update to support something better.
I can recommend a much more efficient method of it works.
if the software will operate on Windows Server 2012 R2, you can do a core installation which runs pretty well on 256megs of RAM.
If you can make it work with WINE, you can run a Linux installation which consumes much less.
If it runs on ReactOS, that might be even smaller.
If it's command line, you might be able to run it on Intel Galileo boards and have one for each pump.
You can actually probably do a single USB Ethernet adapter and a switch with multiple VLANs and run Hyper-V which is amazingly efficient for running Windows guests.
There are many ways. I would be most concerned about Ethernet cables sprawled all over the gas station.
Setting aside all the negativity (most of it relatively justifiable, even if absurd sounding, and most of it also relatively work-around-able): .. I'd look at something like a small form factor PC (yeah, not as convenient as a laptop) with a couple of quad port NICs.
- Bricking all the pumps at once (I assume this is being done before/after hours, and there IS a recovery procedure)
- Networking creating sparks that blow the place up (How is hooking up 2 cables to 2 pumps different than hooking up 1 cable to 1 pump)
- Interrupting customers (Again, before/after business hours, or during non-peak hours, and only doing a few at a time)
- Simultaneous hacking exposure (Connecting device doesn't have to be internet-connected, and in that case, how is connecting to one a time different than connecting to all of them)
- Automating yourself out of a job/hourly pay (Nothing wrong with working smarter, rather than harder; applies to just about every career, even with an hourly wage)
Run your virtualization hypervisor of choice (VMware ESXi or VMware Workstation, VirtualBox, whatever), and install your vendor's preferred OS and software application as a VM. Clone it many, many times (as many times as you have NIC ports). Give each one of them a single dedicated NIC. Run cables to each pump, and start your engines (that's about as close as I can come to making a gas station pun).
It's a fairly simple solution in that it doesn't require any fancy networking knowledge (VLANs, iptables, NATting, etc), and you're using a very straightforward virtualization configuration that most vendors will agree is supportable (their preferred OS, a single network port, etc).
If you can find a way to setup a couple of quad port NICs on your laptop, you could probably use that as well. In fact, many laptops have the option of purchasing a "docking station" that often have PCIe slots. If that's the case, maybe that's all you need to make the above solution work.
I think that being able to do "4 or 8 at a time", using a solution like this one, would be a huge improvement over doing 8 or 16 of them "one at a time".
Don Head
UNIX/Linux Administrator
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.
as I read this I was mostly disappointed about the XP part. I guess that's the way they roll out there in gas pump upgrade world.
The next Mad Max: PUMP UPGRADE XP
Aren't you paid by the hour? Why would you want to work yourself out of a job
I don't know what laws might apply but since I used to maintain the certification databases for the American Petroleum Institute I would strongly discourage any workarounds. In the USA every nut, bolt and screw used in the oil industry pipeline is certified by the API. If you wanted to connect any device to the system you'd have to get it approved, tested and certified.
I would guess that the lack of a unique IP is just the first layer of security. If you hook two devices to the pump a the same time it would probably trigger a shutdown of the station. A subsequent internal investigation would find that someone had connected an unauthorized network device to the system. I won't guess what would happen after that but I wouldn't be surprised if it set of alarms in one or more federal agencies.
I do not block ads. I do block third party scripts.
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.
Not that this wasn't entirely predictable.
If this is like the upgrade I've seen, the ENTIRE STATION is down for the duration of the updates. The back office systems, credit card readers, EVERYTHING is down for updates and/or replacement. And the software is such a work of art, if any single piece doesn't work, you have to rollback the universe.
Simplest solution is to attach a raspberry pi to each pump and leverage the pi as a wireless connection to your laptop.
1.Raspberry Pi with battery pack
2.Wireless hub or wireless network setup on your laptop.
3.Connect each pi to your gas pump.
4.Setup rpi to connect on the local ethernet port (usual a 192.168.1.* or 10.0.0.* address), and also automatically connect to your wifi network
5.Setup port forwarding on your raspberry pi to forward the gas pumps port to the raspberry pi port.
6.Point your update software to the port on the rasperrypi and voila, you should be able to run the update.
This will allow you to update multiple pumps simultaneously.
P.S. There is a high possibility that the update software is leveraging a protocol called tftp to update the software. If that is the case then you don't even need to have the rpi do any port forwarding. You can just get the tftp image and put it on the raspberry pi, then have the rpi automatically run a tftp job once it is connected to the gas pump.
Yes, tons of stuff. Dozens of protocols.
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.
What OP doesn't say (and probably doesn't know) is how that IP address is assigned. As likely as not, it's assigned by the software he is using on his laptop, via DHCP by his host software; that would explain why they ALL have the same IP address. (Certainly that could be in the pump firmware, too, but we have zero evidence of that, so it could just as likely be the other.)
If the pumps actually get their address via DHCP, the software could be hacked to assign a different IP to each pump, and then using a simple ethernet hub or switch, run the firmware update in multiple threads, one thread per pump.
I don't know that's the case, but I have been given no reason to believe it is not.
OP should find out how the IP address is being assigned. He could probably do that simply by trying to telnet into the pump, or using one of the many bits of network analysis tools available.
Many people on here are suggesting the use of wifi to avoid having wires going everywhere. Don't do that. Many embedded devices don't do sanity checking on their firmware images. A dropped packet could silently corrupt the firmware, or cause the process to stall for no apparent reason, or some other headache that you don't want to deal with.
In any case, these devices are on isolated machine networks and it's probably best to keep it that way. You should really just get multiple laptops. Once you get a rhythm going it's easy to babysit 3 or 4 laptops. You'll crank through the job pretty quickly and the constant motion from one to the next will keep boredom at bay for much longer than just staring at a progress bar.
Exactly. Plug in the device to upload and restart.
( add some LEDs so you can see it across the street )
Plug in 12 devices to work in parallel.
Eat at Jack-in-the-box across the street.
Never let the company know that you have a parallel solution.
Claim its all serial.
Go home after 80 mins, claiming you worked a 12 hour shift.
to do them one after the other(serial) setting the arp manually seems the best option.
im guessing you want to do them in parallel...and the vendor app is windows only, .
if you gave the MACs, combinig the arp + vm with direct interface binding is simplest (with a ethernet hub)
if you dont have the MACs, use a manageable switch, trunk port to your laptop and different vlan to each port (1 to 8 untagged)
linux on the laptop, then use a script with qemu or KVM to start 8x VMs (windows in the vm) but bind them to each a different tagged vlan id.
this way, each vm sees only 1 pump without needing the MAC.
May be able to accomplish this with a handful of raspberry pi's (or other similar setups). If you are handy with some coding, I would think you could create a very simple yet elaborate result with it.
Are the pumps not carrying out POS functions? If so, they're networked-
Petro-Tech, I'll echo others: please do a small write-up and let us know how you end up solving this. This project sounds cool. Pictures would also be nice. :)
'He who has to break a thing to find out what it is, has left the path of wisdom.' -- Gandalf to Saruman
You could use raspberry pi
3 Step process
1)Get however many you need, hook them up to your laptop (running dhcp)
Get some battery packs for each..
2)Upload the firmware upgrade image to memory
3)Setup a bootup script to execute upload to tftp ip of the static gas pump ip
Done
You need an agent on the device to deal with the download. Fixed IP and port for host that is serving up files.
Set up 16 VM's with extremely stripped down XP running on each, with only one USB-ethernet adaptor assigned to each VM
Instead, get 8 cheap laptops, and set them up to do the same thing. As others said it may only be a serial interface rather than an actual network port and you don't want broken pumps.
Why the hell is everyone saying he needs crazy vlan rules or expensive switch magic or even some rediculous number of VMs?!?!
Switches are fucking stupid and don't inspect layer 3 unless you beg them to.
Step 1, see what the list of mac addresses is with basic ping and dump
Step 2, just throw a translation table up for a pile of 10 addresses to static far side arps + DNAT and just do what you need to to those with a 5 line bash script.
This is literally a 2 minute job...
Fucking amateurs....
a handful of selfish greedy people are no match for millions of selfish, greedy people -u4ya