Server-based diagnostics on Extron controllers (Part 2)

Introduction

This is part 2 of 3 for diagnostics on Extron controllers.

The EthernetServerInterfaceEx class in the Extron lib provides an interface to an Ethernet server that allows client connections. This class allows the client to send data over the Ethernet port in asynchronous manner using Send() and ReceiveData after a client has connected. This class enables configuration of the server's port number, protocol, interface and max clients.

Each Extron controller can be considered as a server, as it provides services to clients. The diagram above shows two AV LANs, where AV LAN 1 represents a setup in a classroom/boardroom, or a theater. At the University of Manitoba, the number of these spaces could range from hundreds to thousands, meaning N could be > 1000. On the client side, a client is actually a server (Linux server) that sends requests and receives responses from the Extron controllers. The wiring diagram shows Client 1, which, in this case, is my laptop used for testing. For the touch panel UI, I reused the layout from previous post file logging diagnostic part 1, with additional Messaging button and a Volume Slider added. Note on the layout:

• The Messaging button is used to enable/disable messaging between the client and the Extron controllers.
• The Volume Slider is used to adjust the volume of the Extron controllers.

Implementation

From Messaging class, I expect these Attributes/ Methods for Messaging class:

Attributes:

• MsgStatus: tracks whether messaging is enabled (initially False later can set to True)
• client: holds the client object
• ConnectionStatus: tracks whether the client is connected (initually 'Disconnected' later can set to 'Connected')
• Connected: the event is fired when socket connection is established.
• Disconnected: the event is fired when socket connection is closed.
• ReceiveData: the event is fired when data is received. The callback takes two arguments. The first one is the ClientObject instance triggering event and the second one is a bytes object.
• Connected: the event is fired when socket connection is established.
• Disconnected: the event is fired when socket connection is closed.
• ReceiveData: the event is fired when data is received. The callback takes two arguments. The first one is the ClientObject instance triggering event and the second one is a bytes object.

Methods:

• __Connected: when the event is fired, it will add the client to the list of connected clients, and then Send the message to all connected clients. It also updates the connection status to 'Connected' and prints a message.
• __Disconnected: when the event is fired, it will remove the client from the list of connected clients, and then if clients array is empty it will set the connection status to 'Disconnected' and print a message.
• __ReceiveData: when the event is fired, for example, the server receives 'end' string from the client, it will do some actions. In this case with 'end' command, it will call another TerminateClient function, which close the socket connection, remove client from the list and send a message to the client that the connection is closed.
• __ReceiveData: when the event is fired, for example, the server receives 'end' string from the client, it will do some actions. In this case with 'end' command, it will call another TerminateClient function, which close the socket connection, remove client from the list and send a message to the client that the connection is closed.
• EnableMsg: if this function is called, it will set MsgStatus to True, and then check the current connection status. If the connection is "Disconnected", it will trigger StartListen() function and set ConnectionStatus to "Listening".
• DisableMsg: if this function is called, it will set MsgStatus to False, and then close the connection with the client that triggered this function, and then change the ConnectionStatus to 'Disconnected'.
• Send: if this function is called in events, it will send the messages to all connected clients with the format of "time - message".

Testing

Step 1. After the server started.

The ConnectionStatus is 'Disconnected' and the MsgStatus is False. The server is not listening for incoming connections.

Check connection status, it should be 'Disconnected'.

From the screenshot above, I can ping and get reply from the server but I could not connect to the server through a Port.

Step 2. Now I pressed the Messaging button to enable messaging.

The connection status should be changed to 'Listening' and the MsgStatus should be True. I should be able to use TCP client app from my laptop to connect to the server again.

The screenshot above shows that I am able to connect to the server with TCP client app and the server sent a message: "Connected to Diagnostic Port at ...time..."

Step 3. Test buttons and volume slider on touch panel.

Whenever I press test buttons and volume slider, the server should send a message to all connected clients with the format of "time - message".

Step 4. Test ReceiveData event.

As I mentioned in the Implementation section, the ReceiveData event is fired when data is received. In the screenshot below is 'end' command that the clietn sends to the server. The server should close the connection with the client and remove the client from the list of connected clients and send a message back to the client.

From the example, there are many more ways to use the ReceiveData event to trigger actions (terminate the connection, check projector's status, check other connected devices...).

Conclusion

With this solution, there are also pros and cons to consider.

Pros:

• The server uses a defined port to send data to clients, making it more secure for unauthorize access.
• Data can be stored in a database for later analysis.
• Client (a server) can send requests based on admin's requirements such as lamp hours, projector status, usage time, etc.

Cons:

• Clients must establish and maintain connections, requiring checking on the port, IP address of all servers if the connection is lost. In case a lost connection, clients need to attempt reconnection to the lost server (every 1 second, then after 2 hours of lost connection, the interval will increase to every 1 minute). Since each Extron controller is actually a server, so there are hundreds of servers to thousands of servers in a campus. This creates a significant workload on the client side to maintain the connections.
• Cyber attacker can scan open ports and establish unauthorized connections and retreive data from the server.

Since there is only one client (a Linux server), all servers are aware of the client's IP address and open port number. There is a more efficient way to establish and maintain connection to the client. Part 3 I will focus on shifting the maintain connection workload from the client side to the server side.

Demo

Coming soon ...

Reference

Extron Training