On 10/31/22 12:19, Petr Menšík wrote:

Hello, thank you and Barry as well for your answers

I would suggest using strace to find what exactly it does and what it tries to modify. I expect sources for that client are not available.

Well, digging a little deeper, here's what I've found out:

1) in the default case (described in my initial post), i.e.

/etc/resolv.conf symlinked to systemd-resolved /run/systemd/resolve/stub-resolv.conf
    no dns nor rc.manager directives in NM config
    no F5 client NM profile

The vpn client:

    a) backs up /etc/resolv.conf to /etc/resolv.conf.fp-saved
    b) readlinks the symlink
c) execve's /sbin/resolvconf providing nameservers (thus trying to play along with systemd-resolved) but on the wrong interface on my Fedora (eth0.f5 instead of tun0) [besides with a deprecated and not used arg (-m)]

execve("/sbin/resolvconf", ["/sbin/resolvconf", "-a", "eth0.f5", "-m 0"], 0x7ffd13bf8568 /* 30 vars */ <unfinished ...>

    d) set up tun0 interface and bring it up

-> hence we end up with:

a) /etc/resolv.conf.fp-saved as a regular file, copy of /run/systemd/resolve/stub-resolv.conf b) NM managed tun0 interface without and dns property in its profile nor any disk persistent profile c) unchanded /etc/resolv.conf (still linked to /run/systemd/resolve/stub-resolv.conf

so, systemd-resolved not knowing about vpn nameservers and vpn nameresolution fails without workaround (like resolvectl dns adding the tun0 nameserver for instance)

2) with NM handling /etc/resolv.conf as a regular file, i.e.

   /etc symlink rm-ed

the F5 client consider it a 'legacy' setting and overwrite (which is wrong to me) NM managed /etc/resolv.conf regular file

it restores it when stopped by copying back /etc/resolv.conf.fp-saved

So, basically I'd say there are 2 bugs :

1) legacy handling which seems to consider pre-NM era legacy
2) resolvconf call when systemd-resolved is used (at least on Fedora)

In any case, I don't understand why it does not set the NM profile ipv4.dns property, which would let much more chances for NM and/or resolved to work

Anyway, this leaves 2 unanswered questions, the first of which was my initial one:

1) how could, when all resolv.conf-as-a-file-by-NM conf has been removed (by me) and symlink to stub has been restored (by me) systemd-resolved, with *no trace* of the vpn nameservers in its own /run/systemd/resolv/resolv.conf nor seemingly nowhere else, can be still aware of the vpn nameservers (as described in my initial post scenario) ?

-> is there a persistent systemd-resolved cache on disk somewhere ?

2) when running resolvconf by hand (resolvconf <int>) providing specific interface specific nameservers (on stdin), it seems to update the **global** /run/systemd/resolve/resolv.conf (hence making those nameservers available for all interfaces ?)

-> Is there any other place where the specific ns <-> interface is persited or stored or is this global updating all there is ?

Thanks for your help


Reply via email to