Hi Russ, Russ Allbery <r...@debian.org> (2018-03-14): > Cyril Brulebois <k...@debian.org> writes: > > > I've put up an amd64 build for stretch here: > > https://people.debian.org/~kibi/systemd/ > > > along with the source package. I'm also attaching the source debdiff. > > > I'm not tagging this bug report with +patch yet, as this needs to be > > tested on networks with and without advertised MTU (in case that doesn't > > work in the latter case, reverting the commit introduced in the 9.4 > > point release might be just as good…). > > Thank you! I've built this for one of my systems where I was having this > problem and upgraded systemd, libsystemd0, libpam-systemd, and > libnss-resolve to the updated version. I can confirm that IPv6 is still > working fine on that system on a network that doesn't advertise an MTU, > and I'm not seeing the errors in my logs.
Thanks for the confirmation! I've just received a matching report: - without MTU, current packages: same error as you regarding the lack of data. - without MTU, patched packages: the error goes away, and the interface's MTU is used. - with specific MTU, both current and patched packages: the RA's MTU is used. This seems to confirm two things: - the proposed patch fixes the regression; - the “let's look at the advertised MTU in the RA” feature introduced by the last upload still works fine. So it looks to me we should consider going forward with this extra patch, instead of simply reverting the patch introduced in the last upload. I'll leave the final word to the systemd maintainers, of course. Cheers, -- Cyril Brulebois (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
_______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers