On Thu 23 Feb 2023 at 10:44:35 (+0100), daven...@tuxfamily.org wrote: > On 2023-02-22 22:08, David Wright wrote: > > On Wed 22 Feb 2023 at 18:12:29 (+0100), daven...@tuxfamily.org wrote: > > > > > What I want is: setting up /etc/resolv.conf ONLY > > > - at system startup/initial network connexion. > > > - when openconnect is executed and connects to work's VPN > > > - when openconnect is ^C-ed and disconnects from the works VPN > > > (cleaning it's mess in the routing table, interfaces, /etc/resolv's > > > and other netwwork stuff it might have modified, makes sense) > > > > What's the output from ls -l /etc/resolv.conf > > -rw-r--r-- 1 root root 104 23 févr. 09:35 /etc/resolv.conf > > With the ctime changing more or less often, since it is > deleted/recreated by what I suspect to do DHCP requests (see > audit.log)
Being a real file, it's not protected from being modified by any process that wants to. A resolv.conf manager will set up resolv.conf as a symlink to a file that it controls, so that it can manage contention between different processes. > > What's responsible for restoring the previous contents of > > /etc/resolv.conf to your normal network connection when you > > finish "work" and tear down the VPN. > > openconnect does. When it's CTRL-C-ed to disconnect from the workplace > VPN, resolv.conf is reverted back to my home network resolver > Not sure whether vpnc_script just calls the DHCP client (probably > dhclient since it's the only dhcp client preinstalled, at least I'm > aware of) [ … ] > > One way of finding the process is to # chattr +i /etc/resolv.conf > > while you're "at work", so that you get permission errors in the > > logs when it happens. (Remember to chattr -i before you "stop work".) > > Thank you. I'll give it a try, But I won't be on remote work before > next week > Which log file is used for that? > So instead of grepping /var/log/ recursively when the problem occurs. > I'd tail -f the right file to find the "rogue" process right away I don't know. I thought the destination was chosen more by the program than the error type. Perhaps daemon.log and syslog might be good candidates. Of course, after the event you can check them all. > openconnect uses something called vpnc_script. > When openconnects is exc, resolv.conf contains the appropriate info as > well a comment including "VPNC_GENERATED" > > > but I read there's a plug-in for that. Is openconnect correctly > > informing connman when it finishes. > > Whether it informs connmann or cleans after itself without involving > connmann, I don't know and I'm not sure how to check that out. > I'm not familiar with how vpnc_script works and what it does _exactly_ > But it does clean up the config and network config is left in working > state when openconnect disconnects vpnc_script has about eight methods available for setting up and reverting resolv.conf. Which is used depends on the presence of a binary, checked in turn from this list: /etc/openwrt_release modify_resolvconf_openwrt /usr/bin/resolvectl modify_resolved_manager /usr/bin/busctl modify_resolved_manager_old /sbin/resolvconf modify_resolvconf_manager /sbin/netconfig modify_resolvconf_suse_netconfig /sbin/modify_resolvconf modify_resolvconf_suse /usr/sbin/unbound-control modify_resolvconf_unbound otherwise modify_resolvconf_generic Perhaps you could check which of those binaries you have. > > But how do you manage /etc/resolv.conf with connman. I don't use it, Actually I was interested in what sets up your ordinary networking, the one that uses your ISP, when you're not "at work" … > Otherwise, when VPN is disconnected, I DO want /etc/resolv.conf to be > generated according to my home router's DHCP tells the computer … yes, that one. Cheers, David.
