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."
... 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.
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'
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.
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!
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/
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.
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.
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!
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.
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.
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?
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!
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.
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.
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.
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.
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?
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
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.
... 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.
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.
Because if you can remotely connect and disconnect them then you can update them in you pajamas from the other side of the world.
You can also automate the entire process so that while it might take eight hours... you are personally not sitting there while it happens.
You can have a script run that sequentially updates each station and you can do so without actually having to physically go to the station.
The construction of the rig would be pretty cheap. You could hack something together with an arduino with an ethernet shield. or get yourself a Yun.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
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
+1
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.
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.
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.
As someone that has worked with small business customers a lot... they don't care so long as it works.
If I need to update the firmware on the pumps, then no one is going to care how I do it so long as it works.
I also fail to see why this idea is less attractive then the more fully software methods? This is pretty simple and you could build a rig that did this in an afternoon.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
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
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