Iam on 6.11.5 for my prod system and experienced a strange issue.

 

I use br0 with fixed ip. My br0 looks like (btw: the code block is missing JSON as format):

 

[
    {
        "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": {}
    }
]

 

If I run containers like bullseye or jammy like:

docker run --name='test' --net='br0' --ip='192.168.178.16' -it ubuntu:jammy /bin/bash

 

then the first IPv6 request (tested with openbssl s_client) fails with "no route to host". Any attempt afterwards works. I never noticed such things since all containers are v6 enabled and they are running. even apt is not throwing errors, but maybe they work another way?

 

I first noticed it by an app which uses libssl and throwing connect errors. digging deeper with openssl s_client showed the above issue.

 

Any experiences with this? Maybe a docker bug which got fixed within new rleases? Did not tested it with latest unraid rc.

I dont know if this is a very specific issue, maybe it is.

 

EDIT: Also happending with latest rc6 and docker 23.0.6:

 

root@4213d6b86d58:/# openssl s_client -6 -connect testsite:443
40879E9DE9140000:error:80000071:system library:BIO_connect:No route to host:../crypto/bio/bio_sock2.c:125:calling connect()
40879E9DE9140000:error:10000067:BIO routines:BIO_connect:connect error:../crypto/bio/bio_sock2.c:127:
connect:errno=113
root@4213d6b86d58:/# openssl s_client -6 -connect testsite:443
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = testsite
verify return:1
...

 

Edited May 31, 20233 yr by KluthR

For anybody to test, Ive created a small docker image which outputs a test. It starts a openssl s_client -6 connect test (forces v6!).

 

Running with:

docker run --rm -e TESTURL=google.com:443 rkluth/ipv6test:latest

uses default host network - all is working! But as soon as br0 comes in, the first connect try fails!

 

docker run --rm --net=br0 -e TESTURL=google.com:443 rkluth/ipv6test:latest

 

The output with my issue looks like:

 

Welcome!
Run 1...
22497312937280:error:02002071:system library:connect:No route to host:../crypto/bio/b_sock2.c:110:
22497312937280:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:111:
connect:errno=113
Run 1 failed
Run2...
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=1 C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
verify return:1
depth=0 CN = *.google.com
verify return:1
DONE
Succeeded!

 

The test requires a IPv6 enabled br0 interface.

 

Can anyone give it a try if the "issue" or whatever this is, exists on other setups too? Any docker pro who can explain this?

EDIT: If you are curious, this is the entryscript: https://pastebin.com/NLFJNveF

 

Thanks!

Edited May 31, 20233 yr by KluthR

Sidenote: The dev from the software from which I noticed the docker behavior commented: https://github.com/john30/ebusd/issues/751#issuecomment-1570529173