Serva Troubleshooting

0 ERR_SECURE_CONNECTION  

Update: October 26th 2022
This error appeared after October 11th 2022 Windows update which triggers TLS protocol failures on client and server platforms. This error only impacted Serva Pro Civilian licenses. Military licenses were not affected.
Microsoft has issued in October 17th 2022 and October 25th 2022 out-of-band (OOB) non-security update addressing this issue.

The error affected Windows releases and editions, including:
Client: Windows 11, version 22H2, 21H2; Windows 10, 21H2, 21H1, 20H2, Enterprise LTSC 2019, Enterprise LTSC 2016, Enterprise 2015 LTSB; Windows 8.1; Windows 7 SP1
Server: Windows Server 2022, 2019, 2016, 2012 R2, 2012, 2008 R2 SP1

Fixes Available via the Microsoft Update Catalog
The updates fixing this issue can't be deployed via Windows Update, Windows Update for Business, or Windows Server Update Services (WSUS).
You can install them by downloading from the Microsoft Update Catalog and manually importing them into WSUS and Microsoft Endpoint Configuration Manager.
Microsoft has released both standalone packages and cumulative updates:

Please properly update your OS and you will be able to run Serva Pro without the mentioned error.
Please report any detected error or additional information regarding this issue.


1 Nothing Seems to Work

No errors, everything looks fine but there is not traffic at all or some particular protocol appears non-responsive?
Time to check your Firewall


2 Cryptic Binding Errors

The process of offering an IP service involves a binding call where the server application tells the OS its intentions of using a particular "socket".
A socket is a network abstraction characterized by a unique combination of the following:

  1. Protocol: A transport protocol (e.g., TCP, UDP), raw IP, or others.
  2. Local Socket Address: Local Network Address and Port Number
  3. Remote Socket Address: Remote Network Address (only required for established TCP sockets)

When an application tries to use a particular socket already used by some other process it usually triggers an OS error.

i.e. Calling Serva on a Vista PC trying to offer SNTP services on every available IP it gives:

The former error tell us specifically where the problem is located but if we call Serva trying to offer SNTP services on just only one IP (i.e. 192.168.20.1) the OS says:

In this particular case the error message is a bit more cryptic not telling us much about who causes the error. On these situations we can just turn Serva services off one-by-one and pinpoint the protocol is causing trouble.
A more methodic approach requires of a command console session running: 

>netstat –ao

In this case we also come to the conclusion SNTP was the Serva offending service. As we can see on the next image the UDP protocol/port 123 pair was already offered on every available interface (IP= 0.0.0.0) of our PC while Serva was trying to bind exactly the same parameters.

The Process ID was 1504, invoking the task manager we can find who is PID=1504; in this case it was W32Time (Windows Time Service)
We can stop W32Time running a command console as administrator by typing 

>net stop w32time

Stopping W32Time frees the taken socket resources. We can now call Serva with the SNTP service on and we'll see that the previous error is gone.
In order to leave everything as it was before we stop Serva and run 

>net start w32time

This was just a troubleshooting example, other protocols and other binding errors can be handled in a similar way.

 

3 Multi-homed hosts and Serva's bound outgoing traffic

When Serva (running on a multi-homed host) binds a protocol to an specific interface IP, it does bind the "listening" and the "talking". But Microsoft does not behave like Linux here; it is known that the binding to an specific IP when sending packets is only honored under Vista and later OSs (with some obscure exceptions). Former OSs (Win2K, XP, etc) have an extra routing layer added by the OS that can finally alter the interface chosen for packet delivery. The way to "solve" this situation (if necessary) involves user defined static routes.