Ask Slashdot: Best Way To Solve a Unique Networking Issue? 384
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.
It's not a networking issue. (Score:4, Funny)
>> Unfortunately the devices are not actually on a network
So...it's not a networking issue?
Re:It's not a networking issue. (Score:4, Informative)
>> 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. (Score:5, Informative)
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: (Score:3)
Alternatively, you could say the manufacturer has done a good job of eliminating networks as a source of malware.
Re: (Score:3)
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 agre
Re:It's not a networking issue. (Score:4, Insightful)
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!
Re:It's not a networking issue. (Score:5, Informative)
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. (Score:5, Funny)
Are you paid by the hour? If yes, what the actual fuck are you thinking?
Re:It's not a networking issue. (Score:5, Insightful)
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: (Score:3)
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. (Score:5, Funny)
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: (Score:3)
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 wi
Re: (Score:3)
"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: (Score:2)
That sounds like a lack of a code of ethics to me.
Replace each and with a period to make smaller sentences. Maybe not simpler to do, but easier to read.
Re: (Score:2)
Engineers have a code of ethics
I'm not aware of any code of ethics. Though the company I work for has a general saying that when you do an action, ask yourself if it's something that you'll want to be remembered for, which all employees do, even the management, accountants, etc.
Re: It's not a networking issue. (Score:3)
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: (Score:2)
That's not the important question.
These are gas pumps. Should he network them together? Is the question.
Though I do see an advantage of a closed local network for the pumps that doesn't have outside access. ( access only through a specific port.
Re: (Score:3)
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: (Score:3)
Re: (Score:3)
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
Re:It's not a networking issue. (Score:5, Insightful)
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.
ToTo, I don't think we are on Slashdot anymore. (Score:5, Funny)
A competent, helpful answer in the third post.
Re: (Score:3)
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
Re: (Score:2)
Or, simply configure the pumps to have different IP addresses. Does his boss pour gasoline on him and set him on fire if he changes their IP addresses?
Re:It's not a networking issue. (Score:5, Insightful)
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. (Score:5, Interesting)
Re:It's not a networking issue. (Score:4, Insightful)
Better to simply buy 8 $100 used laptops off eBay, and use one for each pump.
Re:It's not a networking issue. (Score:5, Insightful)
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. (Score:5, Funny)
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: (Score:2)
The answer is 2.
Re: (Score:2)
So...it's not a networking issue?
That's what makes this networking issue so unique.
Cakewalk (Score:3)
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.
it's a security nightmare, distributed (Score:2)
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.
wow, that makes me feel good (Score:5, Funny)
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 (Score:4, Informative)
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 (Score:5, Insightful)
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: (Score:2)
Actually, it can go either way. You can buy dispensers with built-in pumps - one pump per dispenser per fuel type, with suction piped to the tanks, or you can drop a pump into each fuel tank, with discharge piped to the dispensers. You do have to be careful about minimum positive suction head if you go with a dispenser-mounted lifting
Re: (Score:3)
If the headline is posed as a question, the answer (Score:5, Insightful)
... 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... [fit-pc.com] or just some generic mini-ITX board in a telecom chassis or whatever.
Re: (Score:2)
Not only that, the gas station may not want more than 1 pump down at a time.
Re: If the headline is posed as a question, the an (Score:2)
Re: (Score:2)
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.
Re: (Score:3)
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.
Solution (Score:5, Informative)
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.
Re: (Score:2)
This. It was the first thing that came to mind.
Re: (Score:2)
Yes, this. There are a good number of cheap managed switches and that would collapse the octupus USB hub into a neat little package.
(Actually you can also get some of the cable modems to vlan on the switchports, depending on the chipsets, but that's a bit more hinky)
The other possibility is to play ebtables tricks based on the device MAC address, but you still end up needing a hub, so just go with the managed switch.
Easy! (Score:5, Insightful)
Get 16 laptops.
Re: (Score:2)
Or an intern?
Re: (Score:3)
And then the Intern goes to Ask Slashdot, and we start the whole thing over.
It's some kind of Internception.
Re: (Score:2)
Re:Easy! (Score:5, Informative)
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.
Probably the way (Score:5, Interesting)
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) (Score:4, Insightful)
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! (Score:2)
Re: (Score:2)
i did this with outlook prior to it allowing multiple exchange accounts, although didnt tackle the ip routing.
The routing is the hard part.....it's like some kind of weird reverse-NAT. It seems like there should be some simple IP-Tables command to do this based on MAC address, but I don't know what the command would be. Then he could run multiple instance of the same software (depending on the software).
I don't think there's a way to set up that kind of routing in Windows, though.
Re: (Score:2)
It's like giving medical advice to someone over the phone.
The laptops while not elegant are the easiest for layman to implement with the least amount of "dafuq just happened" involved.
NAT? (Score:2)
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
Don't (Score:5, Interesting)
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 (Score:3)
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" (Score:5, Insightful)
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: (Score:2)
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.
This is a typical user whine. Ask the user to log off at the end of the day to allow the computer to be accessible during the nightly maintenance window, it becomes a life-and-death struggle for them to log in the next morning, launch their applications, grab coffee and -- gasp! -- talk to a coworker in the hallway. And then get mad when all the systems are rebooted during a three-day holiday weekend to deploy the security patches.
Re: (Score:2)
Re: (Score:2)
Yeah it's hard to imagine having a bunch of nework cables strung over a gas station being acceptable. Maybe just doing a cluster of pumps would be a better goal.
Re: (Score:2)
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: (Score:2)
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.
Not to mention the lawsuit when a customer trips over the cat5 obstacle course.
Re: (Score:2)
That's your experience, maybe, assuming you really keep tabs on them, but it isn't mine. With the two stations I frequent, one a 30 pump station, it is often difficult to even find an empty pump.
Point being that none of us here get to tell the gas station how to handle this situation. The gas station gets to tell us how to handle the situation. We're here trying to find an elegant solution to a problem we think we can create without regard for the users just so we don't have to work so hard.
So what are you
Priority Crucial Question (Score:2)
Are you paid by the job or by the hour?
I have a question. (Score:2)
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?
Re: (Score:2)
What type of idioticly designed pump takes half an hour to run a software upgrade?
According to the OP, the update process involves "running a manufacturer-provided program that connects to the device and pushes the new software."
I don't think it's too hard to guess what level of software quality is provided by the pump manufacturer.
Can we say DUPE POST! (Score:2)
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/ [slashdot.org]
Is the software locked down to the specific IPs? (Score:2)
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/... [microsoft.com]
Get a second ethernet adapter. (Score:2)
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 mea
Why make it less secure? (Score:3)
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.
Contact the vendor (Score:2)
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.
16 VM's! (Score:2)
...oh, and can anyone recommend an exacto knife? (Score:4, Insightful)
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.
VLANs... (Score:2)
Network the pumps (Score:2)
Network the pumps. Push the software one at a time. Lay off the tech. Problem solved.
Obvious solution (Score:3)
I can't believe nobody has posted the most obvious solution yet. Upgrade to IPv6.
Use VLANs and address translation... (Score:2)
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 translatio
Just get paid by the hour. (Score:3)
What's the best way to sharpen my football bat? (Score:5, Funny)
16 netbooks (Score:3)
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.
Re: (Score:2)
Yes. This would be the simplest option. Unless the problem is that the loading software will only do one at a time and this is to make the very slow updates happen in parallel (30 minutes vs. up to 8 hours).
Re: (Score:2)
At no point did the Asker state TCP/IP was involved, nor is there any reason to think it is.
Is there anything that uses Ethernet without using */IP? Is there anything that uses Ethernet without using */IP that also uses IP addresses??
Re:Why not just... (Score:4, Interesting)
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.
Re: (Score:3)
ATA over Ethernet for one. If it's running over a private network also used for management the second question is also yes.
Re: (Score:3)
Yes. I worked with a 3com phone system that ran on bare Ethernet.
You're offtopic but I'll answer anyway. (Score:3)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
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: (Score:3, Informative)
Re: (Score:2)
OP said that they all have the same IP. Presumably this is enforced by the manufacturer, and he has no way to change it.
Re: (Score:2)
Re: (Score:2)
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.
Re:follow defined procedures (Score:5, Interesting)
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.
Security challenge (Score:2)
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 owne
Re: (Score:2)