On Sat, 25 Jan 2025 at 09:35, Tianon Gravi <tia...@debian.org> wrote: > > On Sun, 5 Jan 2025 15:07:30 +0000 Rob Murray <rob.mur...@docker.com> wrote: > > Package: docker.io > > Version: 26.1.5+dfsg1 / 26.1.5+dfsg1-4+b1 > > > > Hi all, this is related to https://github.com/moby/moby/issues/49197 - > > "Cannot connect container to custom bridge network: cannot program > > address in sandbox interface because it conflicts with existing > > route". > > > > The upstream moby 26.1.5 uses Go package > > "github.com/vishvananda/netlink v1.2.1-beta.2". The Trixie-packaged > > version seems to be using an updated version, "1.3.0" perhaps. But, > > the "vishvananda/netlink" project didn't follow the "semver" rules in > > this case - its 1.2.1 release included breaking changes. > > > > The cause of the specific issue reported in the moby ticket above is > > described at https://github.com/moby/moby/pull/48368#issuecomment-2307593543 > > - and was addressed in that PR (to ship in moby 28.0). > > > > Another issue with changes in the netlink package was addressed by > > https://github.com/moby/moby/pull/48407. > > Oof, this is clearly not ideal (de-vendoring is never dull, that's for sure)! > > To be clear, do we need to backport the non-vendor bits of > https://github.com/moby/moby/pull/48368 to the 26.1.5 currently in > unstable/testing to fix this? > > Do we actually need the slightly larger set of changes that ended up > in https://github.com/moby/moby/pull/48938? Something else? > > (The latter is what I tried first, and it doesn't apply cleanly to > 26.1.5 as-is, so I guess more digging/work is required. 🙈) > > ♥, > - Tianon > 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
Hi Tianon! Thanks for taking a look. I think it depends on which version of vishvananda/netlink you can use ... The easiest option would be to stick with 1.2.1-beta.2, used by upstream moby 26.x - then no change should be needed to moby. We didn't have any reports of issues caused by the netlink package ... although, of course, that doesn't mean there weren't any issues. The latest tagged version of the netlink package, 1.3.0, includes https://github.com/vishvananda/netlink/pull/1012 to fix an issue in 1.2.1 with timeouts on sockets that became nonblocking in the 1.2.1 release. But, in the 1.2.1 and 1.3.0 releases, the netlink package returns EINTR (with no results) when netlink responses have NLM_F_DUMP_INTR set. It doesn't include https://github.com/vishvananda/netlink/pull/1018 - to make it return "ErrDumpInterrupted" instead of EINTR, with data that may be incomplete, inconsistent, or contain duplicates. In moby 27.x, we're using an un-tagged version of the netlink package that includes both changes. So, https://github.com/moby/moby/pull/48938 depends on that - it won't work with vishvananda/netlink 1.3.0. I guess that's what you found missing "ErrDumpInterrupted"? To use that version of the moby changes, you'll need at-least the version of vishvanada/netlink used in moby 27.x, v1.3.1-0.20240922070040-084abd93d350. If you can't use an untagged version and it has to be 1.3.0, I think you need the non-vendor parts of that first moby PR, plus https://github.com/moby/moby/pull/48407 (to retry on EINTR). I hope that helps - and I think I've persuaded my email client that this thread isn't spam now, so,should spot updates a bit sooner! Cheers, Rob.
