Arch Linux

How much is this used you reckon? We could wait and see how many people are touched by it before we try wait for available patches?

Also could you write down a way to reproduce :)?

We have no stats about how our great arch users configure their docker, so you know. :)
That remembered, if you have an IPv6 host, your forwarded ports to a container works for IPv4 and IPv6 until now. So, I think it will have impact on folks who use IPv6 (the best of us?) and have no IPv6 stack on containers (IMHO most of them).

The way to reproduce, is well explained in the libnetwork ticket. The ascii schema in this reply helps to catch it quickly: https://github.com/moby/libnetwork/issues/2607#issuecomment-755104810.

Waiting to break people setup to count them doesn't look like a good idea to me. Not to mention, it's sneaky as IPv4 connection still works and service may only be broken on IPv6.

I think discussion around it was a good idea are finished but I will wait the pending patch (2608) to be merged before trying it and eventually release a downstream package.

I was thinking about the people upvoting the ticket and/or complaining on this bug ticket. It should give a good approximation how it touches people.

But yes, waiting for the patch to be merged and see if it fixes the problem before contemplating a downgrade sounds good to me :) Thanks for the work!

The patch has been merged upstream, but I still have the same issue a patched package. This has been reported upstream.

The 20.10.2-2 package was pushed by mistake with others but it doesn't fix this issue.

Our PKGBUILD is broken, we don't build with the libnetwork we fetch in $sources.

$ find -path *bridge/port_mapping.go
./src/moby/vendor/github.com/docker/libnetwork/drivers/bridge/port_mapping.go
./src/libnetwork/drivers/bridge/port_mapping.go

dockerd is built against a libnetwork shipped in its vendor directory. The driver used to call docker-proxy is in it.
docker-proxy binary is built with a libnetwork at another location (the one we pull in sources).

We have the same library in two places, with potentially 2 different versions, to handle the same component which is the docker-proxy.
Not sure if we are broken or it's upstream design...

The 20.10.2-3 package apply the fixes on the correct file.

I don't think it's broken. It's intended from upstream and the commit we use are backported from vendor.conf.

https://github.com/moby/moby/blob/v20.10.2/vendor.conf#L50

I'm more curious about the case of the other components we are pulling. If we can drop the subcomponents because of the vendor then that is IMO better and simplifies the PKGBUILD.

I`m not sure if this is the same problem but after updating from 20.10.2-1 to 20.10.2-3 multiple port bindings fail "driver failed programming external connectivity on endpoint" downgrading the package back to 20.10.2-1 resolves the issue.

Have you created your containers with docker cli?

Could you report this in https://github.com/moby/libnetwork/issues/2607 ?

Not directly, I use docker-compose.

UPDATE:

You already reported it here ? https://github.com/ansible-collections/community.docker/issues/70

This issue is about containers created with ansible.

If your issue is with docker-compose, I think you should mention it on the moby issue.

Sorry my bad, I will report it.

UPDATE:
I tested it with docker cli, the port binding problem exists there too.

There is a new bug report (https://bugs.archlinux.org/task/69367) that seems to be the same problem.

Looks like the docker-proxy daemons for IPv6 are not killed.

I'm building a -4 version, without the patch. Next patched versions will first land in cty-testing.

Is this still a problem?

yes, you can read last comments here: https://github.com/moby/libnetwork/issues/2607

Thanks!