It seems the Debian-specific backend patches alter the nm_system_should_modify_resolv_conf() to only FALSE if resolvconf is installed, and TRUE otherwise. This seems correct.
The hook in /etc/NetworkManager/dispatcher.d/01ifupdown triggers ifup-like
behaviour and runs the /etc/network/if-{,pre-}{up,donw}.d scripts using
run-parts. The actual resolvconf invocation is handled there.
The above makes resolvconf work for regular network interface.
The problem is that for VPN connections (e.g. openvpn using n-m using the
tun0 interface) the network-manager-dispatcher does not run the scripts.
I've put a debug script in /etc/NetworkManager/dispatcher.d/02debug with
these contents (uses ts from the moreutils package):
#!/bin/sh -e
echo "$*" |ts >> /tmp/nm-debug.log
Then I bring up WLAN and see this appear in the log file:
May 08 15:40:17 eth1 down
May 08 15:40:17 eth1 post-down
May 08 15:40:17 eth1 pre-up
May 08 15:40:31 eth1 up
Next, I bring up an OpenVPN connection. Result: NOTHING is written to the
log file (i.e. the hook is not invoked).
So: bringing VPN connections up/down doesn't trigger resolvconf at all. I'm
not sure how this can be fixed. Actually, I don't know where resolvconf gets
its data from at all (but that's not really relevant at this point).
Hope this helps a bit.
mvrgr, Wouter
--
:wq mail [EMAIL PROTECTED]
web http://uwstopia.nl
nobody loves me :: it's true :: not like you do -- portishead
signature.asc
Description: Digital signature
