How to bridge the OpenDXL Broker docker container with another container running the python client?

    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.

    Hi-


    Can you provide a bit more information about your environment and setup. Hopefully that will help us to figure out what is happening.


    How many docker hosts are there?

    What are the different containers and where are they hosted?

    How was the client provisioned?

    What is the client doing? (maybe provide the test code if possible)


    Thanks a lot,

    Chris

    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.

    Great, thanks for the details.


    Just to try to simplify things, I would try this without using a bridged network.


    If you provisioned the client configuration using the console, it should contain multiple IP addresses in the configuration file. One of those will be the external IP address of the host. The python client should be able to connect to the broker using the IP address (the host's). Alternatively, if you happen to provision via the console with "localhost" the client should still be able to use the docker gateway which should be something like 172.17.0.1.


    For example:


    Code: Brokers section of DXL Client configuration File
    1. [Brokers]
    2. local=local;8883;localhost;127.0.0.1
    3. external=external;8883;192.168.99.100;192.168.99.100
    4. docker=docker;8883;172.17.0.1;172.17.0.1


    If you could try it without a bridge network, and then post the results (the log of the client), that would be great.


    Thanks a lot,

    Chris

    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.

    Odd, not sure what is happening. Can you please try the following:


    For the "external" entry, replace 127.0.0.1 with the actual IP address of that host. 127.0.0.1 is referring to the container itself.

    Also, remove the "local" line altogether.


    So, the brokers section should appear as follows (with the host IP address being the actual IP address of the Docker host system):


    Code
    1. [Brokers]
    2. external=external;8883;<host-ip-address>;<host-ip-address>
    3. docker=docker;8883;10.141.0.1;10.141.0.1

    Thanks,

    Chris

    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

    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.

    Yeah, that is definitely worth a shot. I updated the basic service sample (see code below) included with the client to allow for setting the number of services to register. With the latest version of the client I am able to register all of the services consistently (without any deadlocks).



    Thanks,

    Chris

    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!