How does the VF200 Connection work?

Created by Dylan Marriott, Modified on Thu, 04 May 2023 at 10:29 AM by Dylan Marriott

Introduction

Most users will not benefit from learning how the VF200 Connection works under the hood, but understanding this may help more technical users troubleshoot issues they may encounter.

If you are not an IT Professional this document will not serve any purpose to you.

TABLE OF CONTENTS

Introduction
Push Connection
Time Synchronisation
How long does it take to receive Clockings from the terminal?
Possible Problems
Summary

Push Connection

Our previous clocking machines primarily used the 'Pull Model' for communication when retrieving Clockings, synchronizing date and time, and performing other network-related functions. In the Pull Model, our software (such as FRD or STComms) would connect to your clocking machine using its IP address at set intervals.

With the Push Model, the clocking machine initiates a connection with your PC at set intervals. Every 60-120 seconds, the VF200 attempts to send a message to your PC, referred to as a GetRequest or 'Heart Beat'. Your PC can respond to the GetRequest by sending commands such as 'Remove X User' or 'Send me All Clockings Stored'.

When the connection is established, a handshake is formed that allows the PC and the VF200 to set up encryption to prevent man-in-the-middle attacks and ensure security.

Note: CSComms is the Communication Service that is responsible for handling these connections, The code is configured in a way that has rigid handling of data that is sent and received, so no RCE is possible if the encryption key or chain is broken unless an exploit exists at Vendor Level. This will be addressed in the summary.

Pull Connection to this Clocking Machine will made available in CSComms in the near-future. As the VF200 is newly released. Initially having a Push Connection as the default allows users to have a more hassle-free setup and delaying Pull Connection to a later date is the better route as it doesn't provide much benefits.

Time Synchronisation

The only thing that isn't Push Model Orientated is the Synchronisation of time.

This process happens when CSComms receives a Clocking. It will respond to the message with a success code to inform the VF200 the message and Clockings were received as required. When the message is first received from the VF200 CSComms records the IP it was received from, and then sends a Date Time synchronization command to the terminal using the previously mentioned 'Pull Connection Model'

How long does it take to receive Clockings from the terminal?

The VF200 Fires an event every time a Clocking is made at the terminal, this Event will send a message to CSComms with the Clocking providing Real-Time data transfer between the VF200 and CSComms. If CSComms is unreachable at the time the Clocking is made, the clocking will be stored, but the event won't be fired again until another Clocking is made.

Possible Problems

The possible problems in a situation where a Push Model is worth the simplicity it provides.
In the future when we have a Central Comms Server all Clocking Machines will be able to be received by users fully configured.

This allows users to not have to know networking, setting an IP Address, etc.

When using the Pull Model if an external source wants to connect to the clock, there is a process that isn't user-friendly which includes Port Forwarding, the Push Model will simplify this as outbound connections are far less likely to be restricted and are more secure.

If you are having issues with VF200 not connecting to CSComms here are some likely causes.

VF200 Isn't on the Network

If the VF200 isn't on the network, then it will not be able to communicate with CSComms. Because of the Push Model, the IP of the VF200 doesn't matter so can be left on DHCP. Try checking your Ethernet cable for any issues. An easy test to carry out is unplugging the ethernet cable from the VF200 and plugging it into a laptop with WiFi Disabled. If the Laptop doesn't get internet access it will easily identify that the issue is to do with the Physical Ethernet Connection.

Firewall is Blocking the connection

CSComms on installation will make a firewall rule on Windows Defender Firewall that allows incoming connections on Port 9910 TCP. If you are using another service for your Firewall such as ESET or McCafee these will not be affected and will block the connection.

The possible ways to test this is to ensure CSComms is running and run a Port Scan against your PC on Port 9910 TCP using a program like NMAP. If the connection is open, this likely means the fault isn't caused by the PC/Firewall/CSComms.

If you find the port is closed/filtered it's most likely that CSComms isn't running or a firewall is blocking the connection. Most firewalls can be de-activated temporarily allowing you to run another Port Scan and see if the port is now open. Firewalls often come with Logs also, and you may find Logs indicating that this connection was blocked.

CSComms Isn't Running

If CSComms isn't running then it won't be able to accept these connections. CSComms comes with a Configuration Tool and a Service. The Configuration Tool being open doesn't mean the CSComms Service is running. You can check if the service is running by opening CSComms and looking at the Status Indicator shown below:

Pressing the Start Service button will start the service which runs in the background, alternatively, Start Server Debug Mode will make the configuration tool run the Service but not in the background. The execution will entirely be handled by Windows Application you have open as the Code for the connection is in a shared DLL Library.
If using Debug Mode closing the Application will close the open TCP Port.

Debug Mode and the Service provide the same functionality on Port 9910 they can not be both run simultaneously.

In Networking you can't have two Services running on the same port, otherwise, when establishing a connection there is no way to indicate which Service you want to access.

VF200 is Configured to Communicate with an Invalid/Incorrect IP

The VF200 follows the networking fundamentals. It will need it own IP Address to be able to communicate with other IP Addresses (devices).

To simplify the process leave the VF200 on DHCP as knowing the IP will not affect the functionality, and if the IP of the VF200 changes everything will continue to work as expected.

The IP is visible in the screenshot provided earlier of your PC, however, this can be incorrect at times as computers may have several network adapters with IPs. Such as TAP and VPN Adapters which may cause that information to be wrong. It is more reliable to use IPCONFIG in CMD Prompt to get your computers IP but for most cases, the IP displayed will be correct, as there is some functionality in CSComms allowing you to more accurately predict which Adapter is your actual network adapter connecting you to the real LAN.

Follow the steps below to Check & Change the IP of the Server. The Server is the PC Running CSComms:

From the List Setting menu tap 'System Settings'.
Followed by 'Communication'.
Next tap 'Server Setting'.
Finally tap the box to the right of the 'Server IP to open a separate box.
Type in the IP address that you got from your PC or Server & tap 'OK'
Tap the back arrow 3 times to return to the List Setting menu.

Summary

We understand that this is a technical document as highlighted in the introduction and it will not serve purpose to the majority of users but may help or give insight to IT Professionals using or managing an environment with CSComms and a VF200. The likely issues section will cover 99.9% of issues that may occur with the Connection not correctly working with the VF200. Our software and hardware packages do come with a Support Contract for the first year entirely free.

Any support thereafter is chargeable and is sold on a Yearly License basis. If you do have a valid Support Contract contact the Support Desk for further help if you are facing issues and we'll be more than happy to assist you. Documentation on our products is actively being worked on and is available for both customers with/without support contracts.

As touched on earlier if a security vulnerability exists in CSComms that has severe implications such as an RCE will be a fault with Microsoft. The code provided is not vulnerable to RCEs as it has no functionality that may introduce this level of attack.

As CSComms is written in C# and Utilises .NET Framework, if an RCE Vulnerability is introduced it will not be unique to CSComms and will affect all Microsoft Products, or all Products utilising .NET Framework.

The responsibility would be with Microsoft and practicing basic security measures such as ensuring your version of Windows is up to date will provide a substantial increase in your security. To reiterate these security practices do not need to be followed because you have CSComms installed, your machine would be vulnerable without CSComms ever being present in your network.

To a none-technical user that may seem daunting, but this is not new and if you have an IT Provider they should be carrying this out for you at a minimum. The level of security flaws in Microsoft Products if left un-patched for 12 months can have severe implications to your business. Here is an historical list of publicly known security flaws: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Microsoft

We went into a lot of detail on the security aspect as we wanted to make clear that this isn't a CSComms or Clocking Systems problem and it's important you know this information.