Posts by msell

As part of provisioning brokers send a template configuration similar to:

[Certs]

BrokerCertChain=@BROKER_CA_BUNDLE_FILE@

CertFile=@CLIENT_CERT_FILE@

PrivateKey=@CLIENT_KEY_FILE@

[Brokers]

local=local;8883;localhost;127.0.0.1

external=external;8883;@EXTERNAL_BROKER_HOST@;@EXTERNAL_BROKER_IP@

docker=docker;8883;@DOCKER_BROKER_IP@;@DOCKER_BROKER_IP@

[BrokersWebSockets]

local=local;443;localhost;127.0.0.1

external=external;443;@EXTERNAL_BROKER_HOST@;@EXTERNAL_BROKER_IP@

docker=docker;443;@DOCKER_BROKER_IP@;@DOCKER_BROKER_IP@%

Apologies if i've missed the documentation that describes this capability, but Is it possible send other configuration details to clients? For instance if you wanted all clients connecting a broker to use a custom default keep alive interval (rather than the 30 minute default)?

Based on my understanding, for the python client its not possible to read these other client option values from a file configuraion, they need to be provided by the client separately.

Hi Chris,

Thanks for the very quick response, I'll try out your suggestion and eagerly await the retry feature!

Thank you for your time,

Matt

I have to deploy my client in an environment where it is possible to be shutdown unexpectedly, not allowing for proper cleanup steps to be taken. When the client starts up it automatically registers a few services to the broker so in the event of being shutdown and coming back up means both the original services it registered exist and a new duplicate set of services now exist until the original services TTL expires. Is there a strategy where i could either detect/remove the previously registered services that no longer have a client listening or perhaps re-attach to them if their TTL has not expired rather than creating new ones?

Ok using the setup i mentioned in my first post except with openDXL broker 5.0.0.528 and python client 4.1.0.187 i no longer see the issue. Thank you very much for your help!

I am currently using the 4.1.0.185 python client. I see there is a 4.1.0.187 client available, I'll try updating both the python client and opendxl-broker versions to the latest available.

Unfortunately that didn't work. I tried both what you requested and the same thing with the containers back on the bridge and got the same result. Here are some logs of some services being registered successfully and then getting stuck in case it helps provide any understanding of the issue:

edited: added 2 missing lines to bottom of log

Thank you for your help chris! Apologies for the delay in response. I have tried using the docker host ip directly, having both containers use the host network (using both 127.0.0.1 and the docker host ip) among other things. There problem is still persisting, ive attached the logs for the scenario where both containers are using --network host.

There is only 1 docker host with 2 containers:

OpenDXL broker (version 4.0.0.393) with run command:

docker run --restart=always -d --name opendxl-broker --network myBridge -p 8443:8443 -p 8883:8883 -v /var/lib/opendxl/opendxl-broker:/dxlbroker-volume

The second contain uses currently using python:2.7.15-stretch (using OpenSSL 1.1.0f) as the parent image (though i have also tried an alpine image and installed Python 2.7.15 via apk that used LibreSSL). My python image is built with the certs installed on it and hardcoded to use "opendxl-broker" as the broker address. The certs were created using the opendxl broker's webapp at 8443.

docker run --name myPythonClient --network myBridge -v /var/log:/var/log -p 127.0.0.1:9999:9999 -d myPythonImage

myBridge:

[

{

"Name": "myBridge",

"Id": "d3c88570fdcf6db3772673f40b04743b783ce1615efe2e366fb0ada97af1c059",

"Created": "2018-10-22T01:01:11.55120541-07:00",

"Scope": "local",

"Driver": "bridge",

"EnableIPv6": false,

"IPAM": {

"Driver": "default",

"Options": {},

"Config": [ { "Subnet": "172.18.0.0/16", "Gateway": "172.18.0.1" } ]

},

"Internal": false,

"Attachable": false,

"Containers": {

"52a67298e72d2d230060cf506da2e252978ff22458e3b4761aad5fa9185e0b59": {

"Name": "opendxl-broker",

"EndpointID": "c4cb50d07fcc8fae9ed2c1c7dc60e8d81261e5766ebd793c5413c2f0e0c665b3",

"MacAddress": "02:42:ac:12:00:02",

"IPv4Address": "172.18.0.2/16",

"IPv6Address": ""

},

"52faf4311d655e77c8524affc56ee25a74cb9e96cb51c51cb828eeec51137406": {

"Name": "myPythonImage",

"EndpointID": "b4083be255774a33dbc60002a2fd472555329fc939f57b135fbcc4f0a87e578f",

"MacAddress": "02:42:ac:12:00:04",

"IPv4Address": "172.18.0.4/16",

"IPv6Address": ""

}

},

"Options": {},

"Labels": {}

}

]

On startup the first thing my script is doing with the python client is connecting to the broker and then registering 4-5 services. It connects and then sometimes registers 1 or 2 of the services before getting stuck because it never receives a response from the broker, though im not entirely sure the broker is receiving the original message that it doesn't respond to.

I've setup an OpenDXL broker container and exposed ports 8443 and 8883 and am able to interact with it normally with the python client when the client is running on the hypervisor or another vm. However when I try to use the python client from another docker container i've run into the issue where where I connect to the broker and occasionally 1 or 2 messages after that make it to the broker but all subsequent messages never reach to broker. I have tried adding both containers to the default bridge as well as to a user-defined bridge with the python client using the OpenDXL broker container name as the address. One thing i see in the opendxl logs is when i connect externally from the hypervisor or another vm the broker shows the connecting device's ip address, whereas when i connect from the container i see:

New connection from 172.17.0.1 on port 8883.

[140388717029568] 10/30/18 23:36:58 [I] New client connected from 172.17.0.1 as {138f643c-16a7-4eef-ba2c-2a9a19f485b2} (c1, k1800).

which is actually the gateway address of the bridge network and not the ip of the container running the client. That may be a red herring, but any help in pointing out additional steps that I am missing or doing incorrectly would be appreciated.