Ebusd Network error on Docker #751
Labels
Comments
|
duplicate of #520 |
|
Hi, I have the same issue: but I dont know if I have the same root cause as above, because the section at the readme states: But this is NOT the case for me: My start command: Running bash inside the ebusd container and test connection to cfg.ebusd.eu with openssl succeded: What could be the issue? |
|
Hi Commifreak, |
|
Since this is the default value, I did not defined it but Ill give it a try. |
|
Tried it - no success. I also tried these seccomp docker params - no change. @john30 Something I can do to debug this further? I dont see the issue. docker info: If its helping: and |
|
Hello john30, I am facing the same issue with the latest version in Docker on a Synology NAS. In both cases I get the issue as described by commifreak. Any hints...? |
|
No news on my side. I dont know if its my docker version or not :/ The docker tag |
|
same issue here. Date is fine. root@se2: |
|
If that helps: curl is running fine (within the container) with contents from cfg.ebusd.eu I googled the error and found similar things for C regarding SSL but I cant check that. Thats something john have to check. Since curl/openssl are working, I dont get why ebusd isnt. |
|
Some news on this? |
|
In my case? Unfortunately no. |
|
Maybe @john30 could take a look this week? 😬 |
|
Did someone found out something new? |
|
@john30 I know your are busy, but could you take another look into this? |
|
did you try with privileged mode as well? if so, was it working that way or is the error message the same? |
=> With priviliged mode: => (same) The date command works in both and returns same output. openssl test within the container: |
|
it seems that this is more a connection timeout issue. please check with the current source that logs this explicitly if detected |
|
I switched to Results to: |
|
please check again with latest devel once it was pushed from commit 2074356 |
|
I used this image: Any chance to enable ssl debug output? |
john30
added a commit
that referenced
this issue
May 30, 2023
|
this library drives me crazy... anyway, with 3669385 there is debug level logging in network area for SSL (as well as error if indicated), so need to activate debug logging using cmdline args or env to have it on when the calls are made |
|
a typical (successful) sequence would look like this btw: |
|
Hmm. Getting exact same output, althpough Iam on the right image. I tried to set
Do I have to do something special? |
|
Okay, I dont know why it isnt working out of the box with env vars - created a interactive shell with latest image and ran
which got me more: The funny thing: If i set my docker network to host, ebusd is working! Setting fixed IP and br0 makes it stop working again BUT the So there is indeed some network issue, but I dont know which. All other containers are working with the same br0 and fixed IP config. Just ebusd wont. Even apt update is working! Installed iproute2 shows: Any thoughts? EDIT: curl is running as well: ebusd wont (same context) :( EDIT2: Just noted: curl is using IPv6. Could v6 be the issue here? |
|
maybe the br0 net is configured specially somehow, have a look with "docker network ls" and then "docker network inspect ..." with the network name. btw: is this really br0? usually docker names it "bridge" EDIT: yes, I also suspect this is related to IPv6. what is the result of curl being forced to IPv4? |
john30
added a commit
that referenced
this issue
May 31, 2023
|
can you give it another try with the image from commit e2a4695 please? |
No, nothing special here: [
{
"Name": "br0",
"Id": "5ec57e4baea4b76618a625d494cd6269967f5cde931e18b0d7d0a728264dfb1f",
"Created": "2023-05-10T07:17:50.118211813+02:00",
"Scope": "local",
"Driver": "macvlan",
"EnableIPv6": true,
"IPAM": {
"Driver": "default",
"Options": {},
"Config": [
{
"Subnet": "192.168.178.0/24",
"Gateway": "192.168.178.1",
"AuxiliaryAddresses": {
"server": "192.168.178.3"
}
},
{
"Subnet": "***masked***",
"Gateway": "***masked***",
"AuxiliaryAddresses": {
"server6": "***masked***"
}
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
_mycontainers_
},
"Options": {
"parent": "br0"
},
"Labels": {}
}
]
Yes, ist br0. This is managed by Unraid.
Yep, I prepare my test right now. btw: Can you imagine, whats wrong with my poist above regarding |
|
The latest devel image results in slightly changed output: |
well it is a little bit special as it uses some names for the IPv6 part instead of numeric addresses (e.g. myv6subnet). maybe you could create a separate network with IPv4 only?
I couldn't reproduce it. maybe your dockerd version interprets the "-e" params specially. you could check by running the same docker run command with bash as the cmd and then using "export|grep EBUSD" to see if the escaping was interpreted correctly. btw: why did you put the env key in quotes? |
so it does not pass the state of writing the client hello. can you do an |
|
Okay, we are getting somewhere: The initial openssl -6 FAILED! Any attempts afterward were successful. With this knowledge: the first ebusd start failed with the known debug output from above. The second ebusd call SUCCEEDED! Timeframe: Try 1 for openssl -6: First try failed, 2nd succeeded Second example for ebusd: I have no idea whats the initial issue and why things like apt and curl working out-of-the-box. EDIT: Any v4 operation works out of the box after container creation. |
|
I believe we can close this (if you are not seeing any solution from your side). I just tried this cases with the |
|
Testing with I continue to put my findings in this ticket, if this is ok. |
|
Still dont know whats the issue, but maybe all other users with THIS issue here could give this a try: I built a small docker image which just starts a
Replace EDIT: If you are curious, this is the entryscript: https://pastebin.com/NLFJNveF |
|
I suspected routing issues in combination with IPv6 already and it seems there is a rather old issue on dockerd with IPv6, at least thats one of the first hits: moby/moby#20559 this hit seems to be interesting as well: https://chameth.com/ipv6-docker-routing/ funny thing is that ebusd does the initial request already two times as a little retry. but that does not seem to be enough then. anyway, I'll force libssl to use IPv4 only. I think thats the best option for now and should not break anything as ebusd relies on IPv4 anyway |
john30
added a commit
that referenced
this issue
May 31, 2023
|
Yep, that fixed the issue! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
I'm running Ebusd on Docker , since V22.1 I have received the following errors during startup of the container:
This goes on in an endless loop until i stop the container.
Docker command :
docker run -d --name=ebusd --restart unless-stopped -p 8888:8888 john30/ebusd:v22.4 -f --scanconfig -d 192.168.255.32:9999 --latency=80 --mqttport=1883 --mqtttopic=ebusd --mqtthost=192.168.255.10Docker is running on Ubuntu 20.04.5 LTS
Actual behavior
The container writes out the above mentioned logs in an endless loop.
Expected behavior
I would expect the container to start and connect to the Ebus adaptor.
ebusd version
22.4
ebusd arguments
See docker cmd
Operating system
Debian 11 (Bullseye) / Ubuntu 20-21 / Raspbian 11 / Raspberry Pi OS 11 (including lite)
CPU architecture
x64
Dockerized
same as ebusd version
Hardware interface
adapter 3.0 WiFi
Related integration
MQTT Home Assistant via mqtt-hassio.cfg
Logs
Not able to get logfiles , because container restarts.
The text was updated successfully, but these errors were encountered: