c-gate command port issue with toolkit

Bit of a left-field question here (as I know C-GATE not officially supported on Linux...).
I have had c-gate running on a ubuntu server for quite some time, and it has worked happily.

Recently I wanted to update the config for some input units using toolkit, and the connection has failed:

Toolkit presents the following error "An error has occurred while initializing the secure socket layer - Cannot connect to C-Gate Server).

In my syslog I get the following:

Code:

May 26 09:18:18 fnlctl cgate[3389]: Exception in thread "CommandInterface.interpreter" java.lang.NullPointerException
May 26 09:18:18 fnlctl cgate[3389]: #011at gR.run(ProGuard:6275)
May 26 09:18:18 fnlctl cgate[3389]: #011at java.lang.Thread.run(Thread.java:748)

And in the cgate event.txt I get the following:

Code:

20210526-092123 999 sys Selected client cipher: SSL_NULL_WITH_NULL_NULL
20210526-092123 804 cmd5 - Host:/192.168.1.150 closed command interface from port: 0

Problem I have, is I am not sure when this stopped working - could be up to 6 months ago, so I guess a number of changes have happened in the linux environment (c-gate) or on the windows (toolkit) side with various updates.

What I do know is that c-gate has, and does continue to respond and execute commands successfully from an instance of OpenHAB running on the same server (via localhost/127.0.0.1), so toolkit seems to be the only issue.

I have tried various versions of Java (including zulu-8/zulu-11) with no change in behaviour, and currently running against OpenJDK8

I can remotely initiate a connection to port 20123 from the same machine as toolkit is running on (so I know its not a firewall issue), and taking a sneak peek at the cert presented on the 20123 c-gate port, I can see that its an OpenSSL issued cert, still in its validity window (Albiet not from a trusted issue chain, but I presume that's not an issue for Toolkit...)

Code:

E = [email protected]
CN = Kipper Client
OU = SmartSpace
O = Schneider Electric (Australia) Pty Ltd
L = Adelaide
S = South Australia
C = AU

Signature Algorithm: sha256RSA
Valid to: ‎Monday, ‎24 ‎May ‎2027 4:15:05 p.m.

And lastly, the system running toolkit is in access.txt (and have just changed it to the whole network now):

Code:

##C-Gate Server Access Control File
## This file was written automatically by a command issued to the server
## Created:Tue Oct 05 16:22:26 CST 2004
## File name: C:\clipsal\c-gate\config\access.txt
interface 0:0:0:0:0:0:0:1 program
interface 127.0.0.1 program
interface localhost program
remote 192.168.1.255 program
## End of access control file

Environment:
- Toolkit version 1.15.7 (On windows 10)
- Clipsal C-Gate - v2.11.5 (build 3255) - Running on Ubuntu server 20.02
- Java - openjdk version "1.8.0_292"

Any thoughts/tips would be appreciated. Its pretty much a similar issue as in the old post https://www.cbusforums.com/threads/c-gate-on-raspberry-pi-cant-connect-via-toolkit-ssl-issue.8944/ but I appear to have all the correct Java versions, and toolkit/c-gate version combo's which were put forward as solutions in that thread.

I do have a last resort work-around of copying the tag database back to the local PC, and firing up c-gate locally to make my changes, before copying it back over, but I'm pretty keen to given it a nudge and see if I can make it work remotely again. Cheers

 

Hi
Which version of CGate are you running on the Linux machine?
On my raspberry pi I'm running openjdk-8, CGate v2.11.4 (build 3251) with Toolkit 1.15.7 build 2473 and it connects no problem.

I would be safer to use the local CGate installed with Toolkit for making changes to your CBus unit programming.

 

Hi Daryl - Cheers for the feedback. The environment is as follows:
- Toolkit version 1.15.7 (On windows 10)
- Clipsal C-Gate - v2.11.5 (build 3255) - Running on Ubuntu server 20.02
- Java - openjdk version "1.8.0_292"

Other than the (apparently known?) issue of editing eDLT's using a remote C-Gate (for which there is a workaround), using the remote C-Gate for managing/editing the network with Toolkit seemed to work just fine in the past. (Once I got past all the Linux permission issues for TAG database etc, on the initial setup!!)

I just haven't had the need to change any unit programming until recently (for probably around 6 months), and found that whilst C-Gate responds happily to my automation software, C-Bus toolkit is throwing its toys out of the cot !!!

I was hoping that the error messages may lead to a clue which would help me sift through the haystack that has been created by 6 months of patches/updates on both the Windows (Toolkit) and Linux (C-Gate) systems since toolkit was last used (Funnily enough, Toolkit and C-Gate versions are one key item for which the versions have remained unchanged).

Yeah - I will eventually fallback to using the local C-Gate (and copying the TAG DB back to the Linux server) if I (with some help !!) cant find the root cause/solution....But hopefully I am a little way from reaching that point yet...!!
Cheers - Glen

 

Hey Glen,

Had the same issue as you recently. Windows Toolkit connecting to a Linux C-Gate. Worked fine last time I used it, and no go this time, with the same error as you.

Turns out it was a Java version issue on the Linux box.
Not working:

Code:

[root@hass cgate]# java -version
openjdk version "1.8.0_292"
OpenJDK Runtime Environment (build 1.8.0_292-b10)
OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode)

Downgrading the version of Java seemed to work. The first random older version I tried from Oracle was this:

Code:

[root@hass cgate]# jre/bin/java -version
java version "1.8.0_77"
Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)

The way I did it was download the tar.gz version, extract it into a jre/ subdirectory within C-Gate.
I then modified my startup script to use the older version.
My systemd file:

Code:

[root@hass cgate]# cat /etc/systemd/system/cgate.service
[Unit]
Description=Clipsal C-Gate Service
After=syslog.target network.target

[Service]
Type=simple

User=cgate
Group=cgate

WorkingDirectory=/usr/local/cgate

ExecStart=/usr/local/cgate/jre/bin/java -jar cgate.jar

TimeoutStartSec=240
TimeoutStopSec=240

[Install]
WantedBy=multi-user.target

Voila:

 

Hi Skymaster - Thanks heaps for your response.... It certainly gave me all the clues I needed of where to look and work-around the problem.

Short version, I used the approach you proposed for installing local (non-distro) copies of the JDK, and firing up c-gate under these. I still used zulu-8, and started from a version of approx 1 year ago, and fired up c-gate just via the command line, and like yourself, found it worked just fine.

I then continued to download later versions of Zulu-8, and test them and found that it works fine up to, and including 8.52.0.23. The wheels then come off at version 8.54.0.21, and toolkit stops working (but the local OpenHAB connection still works fine with cgate). Version 8.54.0.21 was released in April 2021, and is the same version as installed on the system via 'apt' repositories.

Looking at the release notes for Zulu 8.54.0.21, it looks like they dropped support for TLS 1.0/1.1, or to quote their release notes:

And given the error messages relating to cipher issues in my original post, my hypothesis is that this is the smoking gun, and that cgate/toolkit are using TLS1.0/1.1.

Also the same for OpenJDK version that I tried, with TLS 1.0/1.1 support disabled: https://bugs.openjdk.java.net/browse/JDK-8258598

Knowing this, I'm pretty sure I could even jump back to the prior Zulu11 version, and things would also work ok there too.

Maybe, if my hypothesis is correct, Clipsal will eventually update to use TLS1.2/1.3 and we can resume using current versions of Java.

But for now, I have accordingly updated my init.d startup script to use the manually installed JDK (and thereby avoid future automatic distro upgrades) , and hopefully all good from here.

Thanks again for your help & clues.

 

Hi Glen,

That makes perfect sense. I didn't dig into it too deeply; my CGate runs HomeAssistant as well and I had recently done a yum update but didn't anything of it at the time, hence stabbing in the dark about Java versions.

But - now that you mention it; I did some packet captures and can see exactly that it's using TLS1.0

The initial client message from Toolkit to C-Gate


And the response from C-Gate back



Now, what's really interesting is that it's requesting to use some half-decent ciphers in there; and the certificates are SHA-256. So something has been update to use more modern encryption standards, however the underlying protocol is still capped.

This will bite people going forward if their C-Gate Java updates; in much the same way ours did (windows or linux) - I'd be curious to know if Clipsal will look at releasing a newer version of Toolkit that supports TLS1.2/1.3

 

Hi Skymaster - Good sleuthing and thanks for confirming my hypothesis - Much appreciated.
I agree - I would be very keen to see them update the support to later versions of TLS, especially given most of the world is rapidly turning off anything below TLS1.2.

One note is that those running C-Gate in a windows environment (as part of a default Tookit install), use a version of JRE installed within the "C:\Clipsal" directory tree, installed with the Clipsal software (Current Version: 1.8.0_91), which won't be touched by any automated system/java updates (and should only updated via any future Toolkit install).

Of course, this comes with the inherent risks of running old versions of Java, including platform support, bug fixes, and unaddressed security vulnerabilities. But for now, at least these users with a standard toolkit deployment on Windows should not be affected by any automated system/Java update.

And with the work-around we have both applied to our linux environments (Manually installed JRE within the context of the C-Gate tree, not maintained via any distro/repository), we should too enjoy a return to relative stability of C-Gate!!

Thanks again for your help.
Cheers

 

@glen_m
@Skymaster
Thanks for posting all that info.
My raspberrypi zero setup recently took a Java update and attempting to connect to the remote CGate came up with the same error ""An error has occurred while initializing the secure socket layer - Cannot connect to C-Gate Server"

Versions from apt logs
Upgrade: openjdk-8-jre-headless:armhf (8u212-b01-1+rpi1, 8u312-b07-1~deb9u1)

I was able to get Toolkit to connect by editing the file "/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/security/java.security"
and removing TLSv1, TLSv1.1 in the line "jdk.tls.disabledAlgorithms="

I do not know the security implications of allowing TLSv1 and TLSv1.1 so if anyone has any further information would be great.

Thanks
Daryl

 

Hi Daryl,

By modifying your java security settings, it means you're allowing these older and potentially vulnerable security suites for encrypted communications. TLS 1.0 and 1.1 have now been deprecated due to the fact that whilst they allow encryption of the data channel, this encryption is weak and can be broken relatively easily (compared to say TLS 1.2, 1.3).

If this machine is dedicated to C-Gate, then as long as C-Gate is not internet facing, there is no major issue, because the worst that could happen is someone (already on your local network) could potentially sniff the traffic between C-Gate and C-Bus Toolkit (yay, what a hack! :-D )
Note that the key here being the attacker is already on your local network, and probably has much more interesting things to gain access to, than controlling your house lights.

Now - if the machine you're modifying Java security on is used for other things, such as internet banking, this would be a bad idea. If, for example, your bank allowed the older security protocols as well, then your machine could be talking to something important, using a lower potentially more vulnerable security stack.
Now, this _shouldnt_ happen because the bank shouldn't allow this communication, nor should a bank be using Java - but you get my point.

All this being said, TLS v1.0 and v1.1 is much more secure than a completely unencrypted connection. It's all risk-analysis for the use case.
In my particular case, I have a virtual machine that's only used for C-Gate and nothing more, so I had no problems changing this setting. In your case, if the Pi is only used internally, and does not access any external systems (through Java) then it's probably perfectly fine for you too.

 

Thanks for the detailed explanation.

 

Thanks Daryl. That worked a treat.

My setup is cgate and cgateweb on a dedicated Pi. The Pi also run Mosquitto (MQTT broker) but not much else. Homeseer is my home automation software running on a Windows PC.

I hope Clipsal update Toolkit to support TSL 1.2/1.3 soon.

Marty

 

Bit of an update - I grabbed the new toolkit version 1.16.0 and installed it....(As an aside, it looks like it still comes bundled with a museum-ready version of java for the c-gate install )

I tried connecting to the remote C-Gate on Ubuntu, and it was still throwing the same error. A packet capture showed that toolkit 1.16.0 is still trying to initiate a TLS1.0 connection.

I haven't got around to upgrading the C-Gate running on my Ubuntu host, to the latest version shipped with Toolkit, but given it's toolkit initiating a connection using TLS1.0, I really doubt that will have any impact on the issue.

Summary: While there will be other reasons to upgrade to the latest (1.16.0) toolkit, removing the use of a seriously deprecated cipher ain't one of them . The 2 work-around options listed in the posts above still are valid however.

 

Hi all,

Having just re-configured my RPi 4 running Homebridge and CGate for my home CBUS (after the SD card sh*t itself during a recent storm), I have been banging my head against a wall for 4 hours having the same problem as the OP. The disabledalgorithms fix above worked a treat! Thank you thank you thank you @Skymaster & @glen_m!! Not sure if i'll be keen to update Toolkit even if they do fix the issue, in case something else breaks!

Thanks again - great detective work

Simon

 

Just came across this one also after getting a few new lights added into a new room.

Editing the java security settings instantly did the trick - I do think this needs a Toolkit update though... not sure of the development effort required in fixing this?

A lot of people are using CGate on Linux, they also need to be able to use Toolkit!

 

I agree, but just for clarity, ultimately the issue is not one of people running toolkit on Linux, it is one of either installing an extremely old Java version (with , or downgrading security in a newer version to work with toolkit...

Why don't Toolkit users running C-Gate on windows have this issue? Because toolkit includes this old version (Circa 2016?) of Java in the windows installation package, and explicitly runs under this version when starting (So even if you have new versions of Java installed (and being patched) on your windows PC, toolkit still will use its 'own' version, unless you edit the startup process/files.

Not fantastic, but given its on a private network behind multiple firewalls, not loosing sleep at night over it...!!!

 

Just a further update - Grabbed the recently released Toolkit 1.16.2 (with C-Gate 2.11.10) & retested - Still no fix in there - Still runs on TLS1.0. Both workarounds above still apply if you want to deploy into a Linux environment...