On 01/01/2021 13:24, 積丹尼 Dan Jacobson wrote:
"CB" == Chris Boot <[email protected]> writes:
CB> I don't know why you think this bug is 'grave'. This does not make your
CB> system unusable (and you've found a workaround), does not cause data
CB> loss, and is not a security hole.
/usr/share/doc/debian/bug-maint-info.txt.gz
grave
makes the package in question unusable or mostly so...
Package, not system.
Right, but the implication is that it's unusable for practically
everyone, not a single use-case. pppd works fine for most people, except
if you want to use it with systemd-resolved.
Anyway, suddenly seemingly 'hanging up the phone' is real bad, and
(hopefully now fixed! We'll see. Thanks.)
The problem here is pppd overwriting /etc/resolv.conf when it should be
under the control of systemd-resolved. My fix stops pppd from doing
that, though in this case it will break your system. I think this is the
right approach though: you weren't using systemd-resolved in your case
anyway (because pppd pointed your resolv.conf away from it), and
systemd-resolved really needs to be told about resolvers from pppd.
On 01/01/2021 15:32, 積丹尼 Dan Jacobson wrote:
Bad news, I will have to figure out how to rewrite
pppd default-asyncmap defaultroute lcp-echo-failure 7 lcp-echo-interval \
50 mtu 1492 noaccomp noauth noipdefault noproxyarp persist plugin \
rp-pppoe.so usepeerdns user [email protected] pty pppoe -I enp1s0 -T 80 \
-m 1452 enp1s0 debug
so it works with 2.4.8-1+2, else no addresses resolve right from the start.
Rewriting that won't help. You'll either need your own ip-up.d script to
tell systemd-resolved about your upstream nameservers... or just disable
systemd-resolved altogether. The latter is in effect what was happening
before anyway, so that's what I'd recommend.
Regards,
Chris
--
Chris Boot
[email protected]
