1

At work we design dataloggers, by default the logger's IP address is 192.168.0.177, how can we go about having multiple dataloggers on the network without having to reconfigure the loggers?

The current setup is a Linux server handling DHCP, DNS, samba, etc connected to a switch and then our local windows PCs. We often want to connect to a datalogger but not interfere with each other, we've been managing this by disconnecting from the network or temporarily changing the IP but this causes other issues related to our workflow.

Would it be possible to buy a cheap router/switch for each PC and create a setup where we leave our desktop connected, it can talk to anything outside of the local switch, samba and any other services on the main server and local isolated logger on 177. There are a couple of Linux boxes that it would be useful to talk to from within the switch side, they would not be behind their own switch. If possible the PC would still receive it's IP from the main server DHCP.

Would a vlan on each switch be the kind of setup we should be looking at?

Our dataloggers are set up with a default IP in the same way a home router is set to 192.168.1.1, they are typically never used on a network but connected directly to a laptop when the user is out in the field. If they are left on a network then their IP address would be changed accordingly. What we are trying to set up is an environment where we can test and demo the logger in the office without having to change them from default settings. We essentially need our PCs to be able to access the work network and the logger without the two interacting.

LogicTom
  • 13
  • 1
  • 4
  • Your router analogy doesn't work. A router having a default IP is expected, as it is controlling the IP situation on the network. Client devices should never have a default IP. – EEAA Nov 26 '15 at 23:38

2 Answers2

5

Note: this is not the answer you want, but it is the correct answer.

The concept of a device with a "default IP address" is fundamentally broken and will cause many issues beyond what you're describing here. In this question, you're trying to solve for the wrong problem. Instead of doing what you suggest, make your devices use DHCP. To learn what IP is given to each device, monitor your DHCP server logs.

If the above is not possible, then the remaining solution involves procuring a switch (or multiple switches) that support PVLAN, and then NATing traffic to/from each device using another non-conflicting IP addresses from another subnet.

EEAA
  • 108,414
  • 18
  • 172
  • 242
  • I understand your answer, I should have explained more in the question. I have edited the question to include additional information. – LogicTom Nov 26 '15 at 20:10
  • To summarise what I added to the question. They require the default IP, when sold they usually aren't connected to a network, in the office we need a solution for test/development/demo situations. – LogicTom Nov 26 '15 at 20:24
  • 1
    Even with the extra data I'm still with EEAA in that hard coding .177 is a bad idea. I'd recommend Having the devices get an ip from DHCP or if that's an issue have them give themselves an unused 169.254.x.x IP (checking if it's used first). This range is designated "link local" so isn't going to mess with routing on your network and if you do it right you can guess the IPs of your devices. All you then need to do is manually add a 169.254.x.x ip to your PC and you can access the loggers without any nat. – Nath Nov 26 '15 at 23:30
  • 2
    Sorry Tom, you should stick up for a non-broken solution. Fixing this the right way is very simple. You are not the only company in the world that makes devices like this. Use DHCP. Your "requirement" for a default IP for dev/test doesn't hold water. Every other device manufacturer out there that knows what they're doing uses DHCP. It's not difficult to enable DHCP and still be able to do your testing and demos. – EEAA Nov 26 '15 at 23:33
  • Thanks for the responses but it's not that simple unfortunately. We can't just 'enable DHCP', the device is an embedded system that, years before I started at the company, decided it was going to have a static IP, these units are used out in the field so they hand out an IP to the laptop a technician connects to the device with, these are typically not IT savvy guys, they have locked down machines and rely on the device always having a static IP, the issue only occurs within our walls. – LogicTom Nov 27 '15 at 00:08
  • We cannot change this functionality for a few reasons, code space in the device, user familiarity and mostly the user using a locked down PC. I know what we're doing isn't the technically right thing, I questioned it when joining the company, but what I am after is a solution to the problem with the limitations I have in place. – LogicTom Nov 27 '15 at 00:13
  • @LogicTom Please see my edit. – EEAA Nov 27 '15 at 00:17
1

Had the exact same issue: Devices with static ip for service technicians to use. But needed to access a bunch of these fixed “service” ports on one (actually multiple) computers.

My solution - hokey as it is, works. I simply purchased a bunch of cheap USB to Ethernet adapters; configured each USB IPV4 ethernet port as a different address. This way I could attach as many of the same fixed ip service devices to my computer without any ip conflicts. Ugly as hell but boy does it work well!

Andrew Schulman
  • 8,561
  • 21
  • 31
  • 47
Nicholas J Hunt
  • 11
  • 1