• State Verified Answer
  • Date
    jolson
  • Date
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 43 subscribers
  • Views 1428 views
  • Users 0 members are here

Connecting to CEM+ Dimmer Controllers - Networking Related

I ran into an issue recently that was surprising at one location. While the computer running Concert and UpdaterAtor were on the same VLAN/Subnet as the CEM+ Dimmer Controllers, and could ping each other and access the website GUI, neither Concert nor UpdaterAtor would see these devices. It was discovered that the CEM+ had an incorrect network router in the configuration. Which from a networking standpoint would explain why you would not be able to traverse between subnets, but it would seem that the router defined on the CEM+ host shouldn't impact the discovery protocol as that should all occur on the local network/broadcast domain. Thoughts?

Parents
  • 0

    HI ,

    Sorry for the late reply. Do you know what versions you were running at this location? Discovery has changed a bit through the versions, and depending on the network configuration, this may or may not have an effect on what you were seeing.

    Often after we discover something, we try to make a unicast connection to the device to get more details and information. If the misconfiguration blocked that traffic, we may have counted the device offline or unreachable so as to not give you unexpected partial results.

  • +1 in reply to starksk

    Thank you for responding. While it was able to communicate using a unicast packet, it appears that the discovery mechanism used directed broadcast versus limited broadcast. The subnet mask of the CEM+ was on a class B subnet (255.255.0.0) while everything else was on a class-C (255.255.255.0). But in the same class-C address space. As a result, they were able to see each other in  a unicast way, as well as through the limited broadcast address (255.255.255.255), since it seems like UpdaterAtor uses directed broadcast (192.168.1.255) which the CEM wasn't responding to because it expected (192.168.255.255) to be it's respective broadcast address. Not sure how or why someone setup a class-B subnet for the CEM+s but once I discovered that and got them on the same subnet MASK everything worked well.

Reply
  • +1 in reply to starksk

    Thank you for responding. While it was able to communicate using a unicast packet, it appears that the discovery mechanism used directed broadcast versus limited broadcast. The subnet mask of the CEM+ was on a class B subnet (255.255.0.0) while everything else was on a class-C (255.255.255.0). But in the same class-C address space. As a result, they were able to see each other in  a unicast way, as well as through the limited broadcast address (255.255.255.255), since it seems like UpdaterAtor uses directed broadcast (192.168.1.255) which the CEM wasn't responding to because it expected (192.168.255.255) to be it's respective broadcast address. Not sure how or why someone setup a class-B subnet for the CEM+s but once I discovered that and got them on the same subnet MASK everything worked well.

Children
No Data
Related

www.etcconnect.com