Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Helge A Bentsen]

Okay, great, so, next question (which wouldn't have applied if you had mentioned the word "Android"): why is it important that your control devices use DHCP addresses (and not just link-local like everything else)?

-Russ

Because I haven't figured out a way where I can remote from a computer to another using link local.
So far I've only managed to get them to see each other using static IP or DHCP.

[Andrew Broughton]

Never tried this, but my guess is:
Get another router
Turn off the DHCP server on it, and connect a LAN port on it to the Link-Local network
Connect the WAN cable to a LAN connection on your wireless router (that has DHCP enabled)

If the 2nd router has the WAN port set up for DHCP and NAT, then I would think it would "just work". BUT... maybe not... You might have to do some port forwarding or set up a DMZ port on the non-DHCP router. Not sure.

So, you'd need to have 2 routers, 1 for the wireless control connection that has DHCP enabled, and one that has DHCP disabled that does NAT between the wireless router and the Link-Local network.

[Andrew Broughton]

Or maybe just turn of DHCP on your WAN port on the wireless router and connect the WAN port to the link-local network? Might still need port forwarding or DMZ, not sure.


Yeah, just gave it a try, and it doesn't seem to work. I'm probably out of my depth here, but I'm sure there's a way to do this.

[Russell Ault]

Because I haven't figured out a way where I can remote from a computer to another using link local.
So far I've only managed to get them to see each other using static IP or DHCP.

What remote software are you using?

{...} Yeah, just gave it a try, and it doesn't seem to work. {...}

In general, for two devices to talk to each other over an IP network, either (a) the devices must have addresses within the same subnet, or (b) the devices must be linked through one (or more) gateways that know how to find each other. The link-local addressing specification goes one step further than this and specifies that those addresses (as the name suggests) can only be used for local communications (i.e. gateways aren't allowed). This means that any device that has only a link-local IP address is restricted to communicating exclusively with other devices on the same subnet. Put another way, if device A has a link-local IP address then device B must also have a link-local IP address to be able to communicate with it.

Moreover, most of the control software we use in our industry assumes that the control device and the controlled device will us IP addresses within the same subnet. Some of it can be made to work through a gateway, but others (typically those that rely on discovery of some kind) just won't work across subnets, and either way the question is moot as long as the devices in question have link-local addresses.

TL;DR: if you want everything on the network to be able to talk to each other, and if you want to use link-local address for some of those devices, then you need to use link-local addresses for all devices on the network.

-Russ

[Andrew Broughton]

TL;DR: if you want everything on the network to be able to talk to each other, and if you want to use link-local address for some of those devices, then you need to use link-local addresses for all devices on the network.

But... Isn't that just what a router does? Allows a local network with it's own subnet communicate with another network in a different subnet? e.g. LAN with 192.168.1.xxx addresses communicating with the internet which has xxx.xxx.xxx.xxx addresses.
I thought NAT would take care of the conversion, but I'm not sure how computers on the LAN "see" the WAN IPs without DMZ, port forwarding or "route". This is where I'm out of my depth, as using a DMZ (which I thought opens all ports) didn't seem to work.

[Helge A Bentsen]

What remote software are you using?


-Russ

Microsoft Remote Desktop for MacOS.

[Russell Ault]

Microsoft Remote Desktop for MacOS.

Huh, that's strange; what error message do you get when you try the connection?

But... Isn't that just what a router does? Allows a local network with it's own subnet communicate with another network in a different subnet? {...}

Yes, but only if (a) the application supports its traffic being routed and (b) the devices on the subnets in question are all configured with gateway addresses. In this case, the former isn't true about much of the software we use in our industry (if for no other reason than because IP broadcasts are basically un-routable, which we should all be thankful for), and the latter isn't possible if the devices are using link-local IP addresses (link-local really is "all or nothing", and that's by design).

-Russ

[Helge A Bentsen]

Huh, that's strange; what error message do you get when you try the connection?

Yes, but only if (a) the application supports its traffic being routed and (b) the devices on the subnets in question are all configured with gateway addresses. In this case, the former isn't true about much of the software we use in our industry (if for no other reason than because IP broadcasts are basically un-routable, which we should all be thankful for), and the latter isn't possible if the devices are using link-local IP addresses (link-local really is "all or nothing", and that's by design).

-Russ

No network traffic or similar, can't remember the exact wording.
If I put a static IP or DHCP in there, it's rock solid. Actually super easy to operate the remote PC.

But ok, I'm starting to suspect that what I want might not be possible, so I might have to rethink the whole idea.
Thanks for your input, much appreciated 

[Russell Ault]

No network traffic or similar, can't remember the exact wording.
If I put a static IP or DHCP in there, it's rock solid. Actually super easy to operate the remote PC. {...}

On a purely technical level RDP as a protocol should work just fine with link-local addresses, so it might be worth troubleshooting this more to see if it can be made to work for your particular application.

Another option that might work would be to configure virtual network interfaces on both computers and assign static IP addresses to those interface. This way computer-to-computer communications could use the virtual interfaces and this statically-assigned subnet while computer-to-device communications could continue to use the physical interfaces and link-local subnet. (Note that this doesn't require VLANs: although it's rarely done in practice, there's nothing inherently wrong with having two separate IP subnets operate inside the same Ethernet broadcast domain).

In theory you could go a step further and create two totally-separate physical networks for computer-to-computer traffic and computer-to-device traffic, but such a setup is arguably more complicated and requires more equipment.

-Russ

[brian maddox]

(Note that this doesn't require VLANs: although it's rarely done in practice, there's nothing inherently wrong with having two separate IP subnets operate inside the same Ethernet broadcast domain).

...
-Russ

I do this sort of thing all the time combining control and Dante networks over the same "broadcast domain". Like all things networking, there is a time and a place, but yes this can work just fine and is sometimes preferable to a more complicated configuration...

[ProSoundWeb Community]