Docker Transmission Module to AWS

I'm spinning up a docker container with Cirrus Link Transmission Module that will connect to AWS IoT. I have tried with both ignition versions 8.1.19 (Transmission 4.0.12) and version 8.1.26 (Transmission 4.0.16). I am getting the same intermittent error that it cannot connect. I can connect using the same versions and SSL certs from my physical host. If I wait long enough, sometimes it will actually connect. This is what the errors look like. Has anyone had success with docker container connection to AWS IoT?

SSLSocketFactoryWrapper	15May2023 08:29:58	Failed to load Security Providers
java.lang.UnsatisfiedLinkError: no conscrypt_openjdk_jni-linux-aarch_64 in java.library.path: [lib, lib/core/gateway]

at java.base/java.lang.ClassLoader.loadLibrary(Unknown Source)

at java.base/java.lang.Runtime.loadLibrary0(Unknown Source)

at java.base/java.lang.System.loadLibrary(Unknown Source)

at org.conscrypt.NativeLibraryUtil.loadLibrary(

at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.base/java.lang.reflect.Method.invoke(Unknown Source)

at org.conscrypt.NativeLibraryLoader$

at org.conscrypt.NativeLibraryLoader$

at java.base/ Method)

at org.conscrypt.NativeLibraryLoader.loadLibraryFromHelperClassloader(

at org.conscrypt.NativeLibraryLoader.loadLibrary(

at org.conscrypt.NativeLibraryLoader.load(

at org.conscrypt.NativeLibraryLoader.loadFirstAvailable(

at org.conscrypt.NativeCryptoJni.init(

at org.conscrypt.NativeCrypto.(

at org.conscrypt.OpenSSLProvider.(

at org.conscrypt.OpenSSLProvider.(

at org.conscrypt.OpenSSLProvider.(

at com.cirruslink.common.mqtt.client.SSLSocketFactoryWrapper.loadProviders(

at com.cirruslink.common.mqtt.client.SSLSocketFactoryWrapper.getSocketFactory(

at com.cirruslink.common.mqtt.client.SSLSocketFactoryWrapper.(

at com.cirruslink.common.mqtt.client.CirrusClient.setMqttConnectOptions(

at com.cirruslink.common.mqtt.client.CirrusClient.setSslProps(

at com.cirruslink.common.mqtt.client.CirrusClient.(

at com.cirruslink.mqtt.transmission.gateway.TransmissionClient.connectToTargetServer(


at java.base/ Source)
TahuClient	15May2023 08:29:56	MT-551b4fc5-82eb-40b5: connect failed due to MqttException
org.eclipse.paho.client.mqttv3.MqttException: MqttException

at org.eclipse.paho.client.mqttv3.internal.ExceptionHelper.createMqttException(

at org.eclipse.paho.client.mqttv3.internal.ClientComms$

at java.base/ Source)

Caused by:

at java.base/ Source)

at java.base/ Source)

at java.base/ Source)

at java.base/ Source)

at org.eclipse.paho.client.mqttv3.internal.TCPNetworkModule.start(

at org.eclipse.paho.client.mqttv3.internal.SSLNetworkModule.start(

at org.eclipse.paho.client.mqttv3.internal.ClientComms$

... 1 common frames omitted

Seems pretty clear. This isn't resolving.

Edit: Redacted from my comment, too.

I wish it were that simple. It is failing first on properly setting the SSL properties and opening SSL socket. The second error is resolving host. As I mentioned if I let the connection sit for 5-10 minutes and try it eventually connects. When I go to disable and enable the connection again I get the same errors (with success ~5-10 minutes later again). Also, I noticed I had my endpoint in the logs above so I went ahead and redacted that.

SSLSocketFactoryWrapper	15May2023 08:29:58	Failed to load Security Providers
java.lang.UnsatisfiedLinkError: no conscrypt_openjdk_jni-linux-aarch_64 in java.library.path: [lib, lib/core/gateway]

Are you purposely using this security provider or is that happening automatically as part of your environment?

Is your container really running on Linux / ARM64?

{ I don't have the power to hide the pre-redaction versions.... @Kevin.Herron ?
Brian's too, please. }

1 Like

On first question: That is happening automatically.

On the second question: I'm running my container on my Mac. Does it not use the containerized SSL Provider? Is there anything I need to do during the build process to make sure that gets loaded?

You probably aren't going to be able to run this on your ARM-based Mac. That security provider doesn't seem to provide Linux/ARM64 native libraries.

1 Like

Got it, good to know. Very weird though that it will eventually connect. I'm assuming if I run this on my Windows machine or non M1 Mac this would work?

I guess?

I'm not really even sure why this security provider is being used. Maybe something about the container image you're using?

The error may also be a red herring since it eventually connects.

FWIW: looks like conscrypt is included in the transmission module's modl file. Probably need Cirrus Link folks to chime in, but it's likely that it is bundled and used in whatever MQTT TLS context by design...

1 Like

Looks like their included conscrypt library doesn't include native libraries for aarch64...

EDIT: looks like there is an open ticket here for adding aarch64 builds to their uber jar... aaaaand Kevin H already covered this.. Sorry! #tooslow

Conscrypt doesn't publish a build with Linux/aarch64 native libraries.

ok, so this is making sense now. I built a gateway backup on my mac and loaded it along with the MQTT modules in docker. This is the build that is giving me issues. I just went ahead and built a blank ephemeral gateway and loaded transmission module. This connects without any issues. I think there is something in the database that is forcing it to use this provider...

I'm going to post this here for posterity's sake. I reached out to Cirrus so hopefully I can get some resolution. If I run the following on my M1 Mac and manually install Transmission version 4.1.12 and configure SSL/AWS endpoint it connects every time without any issue:

docker run -d -p 9088:8088 --name ignition-test inductiveautomation/ignition:8.1.19 \
    -n docker-test1 -a localhost -h 9088 -s 9043

If I run docker-compose and load a gateway backup I get the consrypt errors above. I'm assuming this has something to do with the backup database and what SSL security provider is uses.

Please share the resolution when you get it figured out. Haven’t seen this one before.

This was an issue in that MQTT Transmission used Conscrypt for ALPN support in TLS connections to support Java8 which doesn't have native ALPN support. We've fixed this by upticking the minimum Java level to 11 and simply removing the Conscrypt dependency. This is now in the nightly modules and will be part of the 4.0.17 GA release.