• Date
    mfo
  • Date
  • Replies 4 replies
  • Subscribers 188 subscribers
  • Views 1240 views
  • Users 0 members are here

OSC blocked / "error, networks must not be in the same subnet"

Hi,
I'm using EOS 3.1.0 on a Windows 10 notebook and found my OSC input blocked due to the following situation.

There are 3 network adapters: the WiFi and two Ethernet ports. The later two had both adjacent addresses assigned, which in the EOS shell was flagged by "error, networks must not be in the same subnet" . Out of interest: really, is that an issue?

In any case, both ports were not connected! EOS also saw those as "Offline" in the About tab.

And yet, they blocked OSC input, despite it running locally via the WiFi adapter (as EOS doesn't allow for localhost - which by the way would be great to have!).
Unrelated/unconnected network adapters shouldn't block OSC/UDP etc., no?

  • There is an other question i am having.

    Why is it so important to have "Not the Same Subnet" ?

  • Eos flags ip addresses that are on different physical networks but overlapping subnets because the software would have no way of knowing how to respond to messages from the different networks.  Subnets configure what is "inside" and "outside" of your local network.  If addresses you want to connect to are "outside" your local network the requests have to be sent to a router so they ca be forwarded to the appropriate network.  If you have two networks that are the same or overlapping the computer can not determine where to send packets.  I doubt that the two "offline" networks were blocking anything.  

    Now for the blocked OSC input.  What did you do to determine that it was getting blocked?  Is it not working at all?  Have you used tab 99 diagnostics to see incoming and outgoing OSC?  It is far more common for firewall to block incoming packets.  Does the computer see the network as a "public" or "private" network?

    Are you transmitting osc from a different software in the same machine or from a different machine?

  • in reply to Druuka

    Thanks for explaining. I understand the confusion about Subnet ranges, however those addresses were still distinct and fixed, I don't see the conflict potential. For example: network adapter A, address 2.0.0.10, sends to Artnet Node A. Network adapter B, address 2.0.0.20, sends to Arnet Node B. EOS has a clear partner on both ends, has it not? Tho ofc there could be windows/networking issues due to this setup...

    But be it as it may, this is easy enough to fix by using different address different ranges.
    Actual problem, OSC block:

    I was sending OSC into EOS and that worked fine and reliably for days. From the same computer (hence I would love to see Localhost supported. Because atm any change in the network situation means re-configuring my setup.)
    Suddenly it stopped working. I saw my sending software working fine, but no reaction on EOS' side. No input shown in diagnostics tap. Exited it, saw the error message in the shell. Changed Network adapter addresses. Restarted EOS, it worked fine again.
    Hence my assumption it was the addressing issue.

    Though I must admit, in the meantime I found another thing that occasionally "blocks" OSC: when my WiFi fails (shaky router). It again emphasizes the need for Localhost.



  • in reply to mfo

    First of all, ArtNet uses broadcast, so not each network adapter has just its own partner, they also have each other...

Related

www.etcconnect.com