Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[dave...@tuxfamily.org]

Hello,

========= context =========
For the context, I use a Debian 11 laptop for work. When I work remotely
from home, I have to use a cisco VPN. Good thing is there is
openconnect, which does work, and in teh case of ym work's VPN, it does
wor. cisco's spyware/downloaded binry, namely using the --csd-wrapper
/usr/libexec/openconnect/"

When I start openconnect, it usses some vpnc sript to write a porper,
working, /etc/resolv.conf, with the right (work's) DNS resolver IP in
it. And it works.
That worked flawlessly for months. But some months ago, probably after
an upgrade or something (because I definitely didn't change anything),
something started to screw up with /etc/resolv.conf.

So issue is not openconnect-related, at was just for the context. And to
make it clear that totally disabling DHCP and writing the whole network
config manually is not reasonably doable in my context. Because it's a
laptop, sometime used with VPN, sometimes without it (even from home,
occasionally, like during training on which I need to access external
VMs that are not withelisted workplace's firewalls) so network context
varies sometimes.
===== end of context =====

There is an unidentified process that decides it's ok to delete and
recreate /etc/resolv.conf without asking user/admin,
The problem is, the problematic process is not work's VPN related and
creates the file with wrong resolver's IP. The IP corresponds to my home
router IP, which does has a DNS resolver and it works as it should. BUT
my home's router DNS obviously don't know jack about work internal
servers, on which I work… and work's proxy as well, which when it cannot
be resolved… breaks everything using HTTP.

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)

Here's what I know:
- Whatever process does that seems does what I highly suspect to be DHCP
[1] requests every now and then. Home's router answers giving it's own
address as both gateway and DNS resolver. And said process thinks it's
OK to delete and recreate resolv.conf with the wrong content… breaking
everything work's related while the VPN is still active
- Such requests which varies a lot and inst consistent, can be twice or
tree time in 10 minutes or 3-5 times during one afternoon…). sometimes
it happens the minute after I restart the VPN client to recreate a
working resolv.conf file, sometimes it leaves the file alone for 15,
minutes or even 2-3 hours…
- I never configured anything that to do repetitive/time-random DHCP
requests. Except of course the initial DHCP request the system is first
started and connected in the morning when I satrt my work day, wich is
configurerd by default when you install debian for desktop/laptop/with
DEs and network managers and all the fancy stuff.
- I don't use systemd-resolvd. My OS image (Debian stable, LXDE,
connmann as the default network manager) ships with systemd-resolvd
disabled and I'm totally OK with it
- I do use connmann and didn't replace it with anything else
- The process that deletes and recreates /etc/resolv.conf runs as root.
I used auditd to detect when changes that file… but I can't a get any
process name. I can just see it's root
Here's what tail -f audit.log | grep --color resolv.conf shown what it
happens

------
type=PATH msg=audit(1677072201.558:572): item=3 name="/etc/resolv.conf"
inode=786763 dev=fd:01 mode=0100644 ouid=0 ogid=0 rdev=00:00
nametype=DELETE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0
cap_frootid=0OUID="root" OGID="root"
type=PATH msg=audit(1677072201.558:572): item=4 name="/etc/resolv.conf"
inode=784351 dev=fd:01 mode=0100644 ouid=0 ogid=0 rdev=00:00
nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0
cap_frootid=0OUID="root" OGID="root"
------

I was expecting to see a process name it the audit.log file BUT it
didn't happened so I'm still stuck. so my question is: How to debug that
further, and identify the exact process that screw up with
/etc/resolv.conf file… So from there I could search for a way to prevent
that by modifying the rights config file or whatever…

1. But didn't sniff network packets to confirma or infirm that, because
I might wait for long time for it to happen, making extremely huge pcap
files… Unless I know exactly what to filter out from input to have
compact dumps… If it's not DHCP, aned I filter anything but DHCP, I'll
end up with nothing. If I don't filter anything and it doesn't happen
before 2 or 3 hours, it will take a shitload too much space form my home
partition and would be PITA to use wireshark's search functions and
display filters, and search for specific stuff, that will probably need
several attempts with different search pattern and display filters to
MAYBE find out something. Because I wouldn't know for sure what I'm
looking for… Plus, it obviously would only confirm whether or not it's
DHCP requests without additional nfo I actually need. I prefer to put my
efforts and to time to look for the actual culprit process, not just the
protocol.

[Roberto C. Sánchez]

On Wed, Feb 22, 2023 at 06:12:29PM +0100, dave...@tuxfamily.org wrote:
>
> There is an unidentified process that decides it's ok to delete and recreate
> /etc/resolv.conf without asking user/admin,

I will admit up front that I did not read your message in great detail.
However, overall it seems like you are experiencing something similar to
what I experienced in the past.

Here was what I found and how I solved the problem:

https://lists.debian.org/debian-user/2017/10/msg00896.html

The entire thread is rather large, so I didn't just point you to the
beginning of it, but you might find other parts of the discussion
illuminating as well.

Regards,

-Roberto
--
Roberto C. Sánchez

[Christoph Brinkhaus]

Am Wed, Feb 22, 2023 at 06:12:29PM +0100 schrieb dave...@tuxfamily.org:
>
> ========= context =========
> For the context, I use a Debian 11 laptop for work. When I work remotely
> from home, I have to use a cisco VPN. Good thing is there is openconnect,
> which does work, and in teh case of ym work's VPN, it does wor. cisco's
> spyware/downloaded binry, namely using the --csd-wrapper
> /usr/libexec/openconnect/"

[snip]

> ===== end of context =====

> 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)
>
> Here's what I know:
> - Whatever process does that seems does what I highly suspect to be DHCP [1]
> requests every now and then. Home's router answers giving it's own address
> as both gateway and DNS resolver. And said process thinks it's OK to delete
> and recreate resolv.conf with the wrong content… breaking everything work's
> related while the VPN is still active

If it is DHCP: You might do a countermeasure in
/etc/dhcp/dhclient.conf. On my system I have an entry as below.

interface "wlp4s0" {
supersede domain-name-servers 127.0.0.1;
}

I run unbound as a resolver. The entry in dhcclient.conf prevents that
the entry in /etc/resolv.conf is overwritten.

[snip]

My setup is stoneage like compared to your context.
Anyhow, I hope this is at least useful as a pointer :-).

Kind regards,
Christoph
--
Ist die Katze gesund
schmeckt sie dem Hund.

[Greg Wooledge]

On Wed, Feb 22, 2023 at 06:12:29PM +0100, dave...@tuxfamily.org wrote:
> There is an unidentified process that decides it's ok to delete and recreate
> /etc/resolv.conf without asking user/admin,
> The problem is, the problematic process is not work's VPN related and
> creates the file with wrong resolver's IP. The IP corresponds to my home

> router IP, [...]

Then it's probably the Debian DHCP client, rewriting resolv.conf
according to what your router's DHCP server told it to use.

<https://wiki.debian.org/resolv.conf> has several different strategies
for working around this sort of issue.

Good luck.

[David Wright]

On Wed 22 Feb 2023 at 18:12:29 (+0100), dave...@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

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.

> - I don't use systemd-resolvd. My OS image (Debian stable, LXDE,
> connmann as the default network manager) ships with systemd-resolvd
> disabled and I'm totally OK with it
> - I do use connmann and didn't replace it with anything else
> - The process that deletes and recreates /etc/resolv.conf runs as
> root. I used auditd to detect when changes that file… but I can't a
> get any process name. I can just see it's root

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".)

But how do you manage /etc/resolv.conf with connman. I don't use it,
but I read there's a plug-in for that. Is openconnect correctly
informing connman when it finishes.

> I was expecting to see a process name it the audit.log file BUT it
> didn't happened so I'm still stuck. so my question is: How to debug
> that further, and identify the exact process that screw up with
> /etc/resolv.conf file… So from there I could search for a way to
> prevent that by modifying the rights config file or whatever…

Whatever the "rogue process" is should be informing whatever the
"/etc/resolv.conf controller" is, shouldn't it, rather than being
blocked. (It might be legitimate rather than "rogue".)

Cheers,
David.

[Cindy Sue Causey]

On 2/22/23, dave...@tuxfamily.org <dave...@tuxfamily.org> wrote:
>
> There is an unidentified process that decides it's ok to delete and
> recreate /etc/resolv.conf without asking user/admin,
> The problem is, the problematic process is not work's VPN related and
> creates the file with wrong resolver's IP. The IP corresponds to my home
> router IP, which does has a DNS resolver and it works as it should. BUT
> my home's router DNS obviously don't know jack about work internal
> servers, on which I work… and work's proxy as well, which when it cannot
> be resolved… breaks everything using HTTP.

Hi.. I didn't know where to jump into this so am responding to that
paragraph in its original post. Having just debootstrap'ed again, one
thing I do is verify /etc/resolv.conf's content. The following,
slightly lengthy blurb has begun showing up where I'd never seen it
before. I'm sharing it with hopes maybe it hints at what might be a
trigger for the reset:

++++++++ BEGIN CONTENT FROM NEW, UNALTERED /etc/resolv.conf FILE +++++++++
# This is /run/systemd/resolve/stub-resolv.conf managed by
man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .
++++++++ END CONTENT FROM NEW, UNALTERED /etc/resolv.conf FILE +++++++++

Those last three lines worked for Mint, but they did not work for
Debian. So I defiantly altered that file. I commented those three
lines out, tracked down my ISP's nameserver values,** and plugged them
in. I was able to connect immediately after that.

When I tried to do that with some other distribution, possibly Mint
again, it would reset as is being described in this thread and as is
seemingly implied in resolv.conf's "do not edit" line. I have no clue
why Debian is not resetting now, but I'm VERY grateful it's remaining
stable.

Having now actually read more of that blurb, I didn't follow any
symlinks. Thanks to issues over the years, /etc/resolv.conf is the
first place I go if an Internet connection is not working as expected.

Lastly, I just tried "ls -ld" on that long /run line to
stub-resolv.conf. It's "no such file" so that would explain why it's
not resetting on my end. Resolvectl is also pulling up as not found.

Those all definitely explain why I'm able to type online right now. If
I was feeling brave right now, I would try messing around with doing
what it takes to get resolvectl in control, but I'm not (feeling
brave). :)

Cindy :)

** My ISP's nameserver values were found in connman's GUI, of all
things. Connman has NEVER worked for me. I have no idea why it's
working now. I didn't manually install it. Connman came in
automatically somehow related to the LXQt desktop environment. Just
leaving this here in case it somehow is playing a part in why my
resolv.conf is not resetting. You never know..............

--
Talking Rock, Pickens County, Georgia, USA
* GRUB IS WORKING! Just put ^ in front of metadata_csum_seed in mke2fs.conf! *

[John Conover]

On 2/22/23, dave...@tuxfamily.org <dave...@tuxfamily.org> wrote:
>
> There is an unidentified process that decides it's ok to delete and
> recreate /etc/resolv.conf without asking user/admin,
> The problem is, the problematic process is not work's VPN related and
> creates the file with wrong resolver's IP. The IP corresponds to my home
> router IP, which does has a DNS resolver and it works as it should. BUT
> my home's router DNS obviously don't know jack about work internal
> servers, on which I work… and work's proxy as well, which when it cannot
> be resolved… breaks everything using HTTP.

Might look at:

/etc/network/interfaces.d/setup

as explained in "man interfaces". (That file can/might be changed via
the network symbol in the window manager's configuration bar/menu
system, usually required with root/sudo privileges.)

John

--

John Conover, con...@panix.com, http://www.johncon.com/

[dave...@tuxfamily.org]

Hello

On 2023-02-22 22:08, David Wright wrote:
> On Wed 22 Feb 2023 at 18:12:29 (+0100), dave...@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)

> 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)

>
>> - I don't use systemd-resolvd. My OS image (Debian stable, LXDE,
>> connmann as the default network manager) ships with systemd-resolvd
>> disabled and I'm totally OK with it
>> - I do use connmann and didn't replace it with anything else
>> - The process that deletes and recreates /etc/resolv.conf runs as
>> root. I used auditd to detect when changes that file… but I can't a
>> get any process name. I can just see it's root
>
> 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

>
> But how do you manage /etc/resolv.conf with connman. I don't use it,

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

>
>> I was expecting to see a process name it the audit.log file BUT it
>> didn't happened so I'm still stuck. so my question is: How to debug
>> that further, and identify the exact process that screw up with
>> /etc/resolv.conf file… So from there I could search for a way to
>> prevent that by modifying the rights config file or whatever…
>
> Whatever the "rogue process" is should be informing whatever the
> "/etc/resolv.conf controller" is, shouldn't it, rather than being
> blocked. (It might be legitimate rather than "rogue".)

Yes, I certainly don't want to block the process entirely, I just want
to find some mechanism that works in the following way

"Leave /etc/resolv.conf alone, ONLY IF you're not openconnect/a
vpnc_script AND WHEN openconnect is running"

Otherwise, when VPN is disconnected, I DO want /etc/resolv.conf to be
generated according to my home router's DHCP tells the computer

Thank you for your help either way. It gives me some interesting
pointers :)

>
> Cheers,
> David.

[to...@tuxteam.de]

On Thu, Feb 23, 2023 at 10:44:35AM +0100, dave...@tuxfamily.org wrote:

[...]

> 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?

That depends: it's the perpetrator's choice where to log (or whether
to log at all, sadly).

> 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

You know that you can tail -f more than one file, do you?

I just learnt that from a colleague. Enormously handy.

Cheers
--
t

[dave...@tuxfamily.org]

Hello,

On 2023-02-23 02:59, con...@panix.com wrote:
> On 2/22/23, dave...@tuxfamily.org <dave...@tuxfamily.org> wrote:
>>
>> There is an unidentified process that decides it's ok to delete and
>> recreate /etc/resolv.conf without asking user/admin,
>> The problem is, the problematic process is not work's VPN related and
>> creates the file with wrong resolver's IP. The IP corresponds to my
>> home
>> router IP, which does has a DNS resolver and it works as it should.
>> BUT
>> my home's router DNS obviously don't know jack about work internal

>> servers, on which I work… and work's proxy as well, which when it
>> cannot
>> be resolved… breaks everything using HTTP.

>
> Might look at:
>
> /etc/network/interfaces.d/setup
>
> as explained in "man interfaces". (That file can/might be changed via
> the network symbol in the window manager's configuration bar/menu
> system, usually required with root/sudo privileges.)
>
> John

There's nothing relevant to change in that file. I don't want to have
static IP. And the right interface name is not in it.

I'm not sure whether that file became totally obsoleled, or if it's not
normal that it doesn't contain the expected interface name? has it been
deprecated since debian switched to systemd so-called "predictable"
iface names?

For some reasons, since debian 9 or 10 (id nor 8?), including debian 11
new installs (work laptop has been install slightly more than a year
ago),
that files only contains the eth0 and local interfaces name, while
debian switched to systemd style interfaces names.
I remembrer having slowed down boots because of the that, on my personal
laptop, when debian switched to systemd style names and that file still
referred to eth0 which doesn't exist
So boot process was waiting for eth0 interface until I commented out
that part (eth0 block) of interfaces files.

On the newer work laptop on the other hand, there is that eth0 block,
there's is no eth0 interface on my system (there's enp.* and enx.*
systemd names, instead)
BUT I never had the slow/timeout-waiting boot process unlike the
personal was reinstall from zero instead of upgraded years ago only to
change HDD to SSD, and to change partitioning to encrypted LVM.

So my guess is /etc/network/interface.* has been replaced with something
also. Since it refers to non-exitent interfaces names without breaking
the network or slowing down the boot process.

Also, the switching to systemd styles interfaces names has been
following by a weird behaviour on my personal computer. It has a
"failed" error message at startup, for the network (or is networking? it
never remember the correct name) service, without breaking the network…
it weirdly just works. I never figured out what replaces that service.
If anyone has any idea?

[dave...@tuxfamily.org]

Interesting! I didn't knew that. Thanks for the tip.

I knew about and I just remembered multitail, which I never used that
much, cause can be too noisy… But I guess I'm going to use "grep
resolv.conf"… But if the "rogue" process doesn't log anything… I'll be
stuck… worth trying either way. Thanks

[dave...@tuxfamily.org]

Hi

Unfortunately, I can't use supersede parameter because I need to use
different resolvers at different times/in different contexts.

I would need something more… conditional

IF openconnect is running and has modified resolv.conf, leave that file
alone unless you are openconnect
Otherwise, when there's no VPN active, you can do normal DHCP requests
and accept whatever currently-active network's router/DHCP tells you and
update resolve conf accordingly

[Jeremy Ardley]

As a general comment on resolving name service problems you need to
become acquainted with nsswitch

I have only recently become aware of it. It's central in determining
just how your system looks up lots of things including DNS names.

Some research and reading is required (for me and perhaps most?)

--
Jeremy
(Lists)

[Reco]

Hi.

On Thu, Feb 23, 2023 at 11:31:44AM +0100, dave...@tuxfamily.org wrote:
> > If it is DHCP: You might do a countermeasure in
> > /etc/dhcp/dhclient.conf. On my system I have an entry as below.
> >
> > interface "wlp4s0" {
> > supersede domain-name-servers 127.0.0.1;
>
> Unfortunately, I can't use supersede parameter because I need to use
> different resolvers at different times/in different contexts.
>
> I would need something more… conditional
>
> IF openconnect is running and has modified resolv.conf, leave that
> file alone unless you are openconnect Otherwise, when there's no VPN
> active, you can do normal DHCP requests and accept whatever
> currently-active network's router/DHCP tells you and update resolve
> conf accordingly

openconnect has that helpful --script option, which calls
/usr/share/vpnc-scripts/vpnc-script by default.
All you need is to make a copy of that script, modify dhclient.conf
at "connect" and "disconnect" phases accordingly, and then call your
modified script from openconnect.

Reco

[David Wright]

On Thu 23 Feb 2023 at 10:44:35 (+0100), dave...@tuxfamily.org wrote:
> On 2023-02-22 22:08, David Wright wrote:
> > On Wed 22 Feb 2023 at 18:12:29 (+0100), dave...@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.

[to...@tuxteam.de]

On Thu, Feb 23, 2023 at 11:39:03PM -0600, David Wright wrote:

[...]

> 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.

Thanks for this one. I think this is the most constructive
contribution to this thread.

Cheers
--
t

[dave...@tuxfamily.org]

Hello,

> […]

> 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.

I have they two resolved_manager binaries, but since systemd-resolvd
service is disabled and stopped on my system, I highly doubt these are
used.
It's more likely modify_resolvconf_generic

However, I didn't notice any vnpc_script malfunction. It does what it is
expected to do. I'm like 99% sure the problem is dhclient deleting and
recreating /etc/resolv.conf as it sees fit, multiple times a day, and
deleting whatever vpnc_script has put in that file.

>
>> > 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" …

- ConnMan is used to manually connect to/disconnect from wired, and much
less often wireless (wifi, bluetooth) networks
- dhclient is used for DHCP request
- My OpenWRT router with DHCP is used as gateway for my subnet, answers
to DHCP requests
- Then there's is toward my ISP's all-in-one router/modem + TV set top
box + telephony bullshit (I don't use anything but Interne, but ISP
enforces their "triple play bullshit so I have to do with that all in
one device… There's no alternatives for DOCSIS, Since I can't get FTTH
yet, which my current router doesn't support yet, either way I'm
dependant on ISP router)

[to...@tuxteam.de]

On Fri, Feb 24, 2023 at 10:19:38AM +0100, dave...@tuxfamily.org wrote:

[...]

> However, I didn't notice any vnpc_script malfunction. It does what it is
> expected to do. I'm like 99% sure the problem is dhclient deleting and
> recreating /etc/resolv.conf as it sees fit, multiple times a day, and
> deleting whatever vpnc_script has put in that file.

Instead of 99% suspicions you could just look into your /var/log/syslog:
dhclient does leave enough traces there. Bonus point if you correlate
these timestamps with your resolv.conf mod time :-)

Cheers
--
t

[dave...@tuxfamily.org]

Goode point. Thank you for the reminder :)

I do only partial week remote work, been in the office the last days.
So in order for the problem to happen again, I need to wait monday, only
then I might dig into the log files.

The thing is: at first, I didn't suspect dhclient until recently (after
I started this thread) so I need to wait for the next remote work day.
During my last days of remote work, I just used auditd to see if I can
see process name when the file is deleted/recreated.
The event was captured by auditd but the process name was missing from
the audit.log file, so I had no idea what's to look for., in which log
file(s).

I'm still sure it isn't vpnc_script. vpnc_script leaves identification
comments on the file
And dhclient is more like to know only about what my home's DHCP tells
it, than my work's place DNS resolver, that's why I suspect dhclient.
BUT I will make sure to take some time to dig into the logs monday. Now
that I have an idea what I'm looking for, totally agree logs are better
than suspicion

[to...@tuxteam.de]

On Fri, Feb 24, 2023 at 11:27:40AM +0100, dave...@tuxfamily.org wrote:

> [...] totally agree logs are better than suspicion

But please, don't take my snark all too seriously. On reread I
realize it might have sounded harsher than it was meant.

Cheers
--
t

[Greg Wooledge]

On Fri, Feb 24, 2023 at 10:19:38AM +0100, dave...@tuxfamily.org wrote:

> However, I didn't notice any vnpc_script malfunction. It does what it is
> expected to do. I'm like 99% sure the problem is dhclient deleting and
> recreating /etc/resolv.conf as it sees fit, multiple times a day, and
> deleting whatever vpnc_script has put in that file.

Then use one of the methods listed at <https://wiki.debian.org/resolv.conf>
to address that, and see if it fixes the problem.

The simplest one to test would be
<https://wiki.debian.org/resolv.conf#Configuring_dhclient>. It doesn't
involve installing any new packages.

If your testing is successful (e.g. a whole day goes by and the
resolv.conf file is not unexpectedly altered), then things get a little
bit trickier. If I understand correctly, you're working on a laptop,
and your desired configuration is:

* At boot time, allow the DHCP client to set up resolv.conf.

* Once that has been done, disallow all further modifications of
resolv.conf by the DHCP client.

* Allow modifications of resolv.conf by vpnc_script at any time.

The tricky part here is how to write a function that determines whether
dhclient should be allowed to modify the file ("is it boot time") or not.
Perhaps you could use something awful like "if the system uptime is less
than 5 minutes, allow it".

Another hack that comes to mind would be writing something that removes
the resolv.conf file at shutdown time. Then, the dhclient hook function
would allow dhclient to write the file if and only if it doesn't exist.

Or... the reverse of this. Keep a second file which serves as a flag
indicating that the resolv.conf file has already been configured once.
Remove this flag at boot time (make sure that happens *early*, before
dhclient is started), and then write your dhclient hook function to
allow the modification if and only if the flag file doesn't exist. Then
create the flag file after doing the modification.

I'm not sure which of those is the least bad. Maybe you can come up
with some other ideas.

[David Wright]

On Fri 24 Feb 2023 at 10:19:38 (+0100), dave...@tuxfamily.org wrote:
> > […]
> > 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.
>
> I have they two resolved_manager binaries, but since systemd-resolvd
> service is disabled and stopped on my system, I highly doubt these are
> used.
> It's more likely modify_resolvconf_generic
>
> However, I didn't notice any vnpc_script malfunction. It does what it
> is expected to do. I'm like 99% sure the problem is dhclient deleting
> and recreating /etc/resolv.conf as it sees fit, multiple times a day,
> and deleting whatever vpnc_script has put in that file.

If that's the case, then unfortunately the vnpc_script gives you no
protection against that happening. All it appears to do, when you
connect, is to write:

#@VPNC_GENERATED@ -- this file is generated by vpnc
# and will be overwritten by vpnc
# as long as the above mark is intact"

at the start of resolv.conf, so that when you disconnect, it can check
if that first string is still there and, if it is, restore the previous
contents of the file.

Meanwhile, anything else might overwrite the file, and if it does,
it's likely that the vnpc_script won't even be able to restore the
previous version of the file when you disconnect.

You'll notice that none of the other functions actually reference
resolv.conf itself, but will store the real file elsewhere, and
publish it through a symlink.

> > > > 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" …
>
> - ConnMan is used to manually connect to/disconnect from wired, and
> much less often wireless (wifi, bluetooth) networks
> - dhclient is used for DHCP request

They should work with either of the resolvconf packages that Debian
supplies, resolvconf and openresolv. I use the latter, as iwd documents
that it supports it. I know there are people on this list who use connman.

> - My OpenWRT router with DHCP is used as gateway for my subnet,
> answers to DHCP requests

I do much the same, with my router (two, actually) connected to the
ISP's ethernet connector.

> - Then there's is toward my ISP's all-in-one router/modem + TV set top
> box + telephony bullshit (I don't use anything but Interne, but ISP
> enforces their "triple play bullshit so I have to do with that all in
> one device… There's no alternatives for DOCSIS, Since I can't get FTTH
> yet, which my current router doesn't support yet, either way I'm
> dependant on ISP router)

Everything of ours runs from my router, so the ISP's is just a
glorified modem.

Cheers,
David.

[dave...@tuxfamily.org]

Hello

On 2023-02-24 11:27, dave...@tuxfamily.org wrote:
> On 2023-02-24 10:27, to...@tuxteam.de wrote:
>> On Fri, Feb 24, 2023 at 10:19:38AM +0100, dave...@tuxfamily.org
>> wrote:
>>
>> [...]

> BUT I will make sure to take some time to dig into the logs monday.
> Now that I have an idea what I'm looking for, totally agree logs are
> better than suspicion

I did

- chattr +i /etc/revolv.conf

And when auditd showed a (failed) delete event on /etc/resolv.conf

I grepped "resolv.conf" recursively on /var/log/, and All I've found are
entries in

- /var/log/installer from more than 1 year ago, since the log file is
small, I guess it has never been rotated
- audit.log, since write and append to "/etc/resolv.conf" are audited
- auth.log : authentication related to commands I've used this morning,
which are "auditctl -w /etc/resolv.conf -p wa" and "chattr +i
/etc/revolv.conf"

But whatever process tried to delete "/etc/resolv.conf" whidle it was
immutable, didn't leave traces.
Not even a log for permission error because of the immutable flag. At
least not in /var/log anyway.

[Greg Wooledge]

On Mon, Feb 27, 2023 at 03:14:40PM +0100, dave...@tuxfamily.org wrote:
> I did
>
> - chattr +i /etc/revolv.conf
>
> And when auditd showed a (failed) delete event on /etc/resolv.conf
>
> I grepped "resolv.conf" recursively on /var/log/, and All I've found are
> entries in
>
> - /var/log/installer from more than 1 year ago, since the log file is small,
> I guess it has never been rotated
> - audit.log, since write and append to "/etc/resolv.conf" are audited
> - auth.log : authentication related to commands I've used this morning,
> which are "auditctl -w /etc/resolv.conf -p wa" and "chattr +i
> /etc/revolv.conf"
>
> But whatever process tried to delete "/etc/resolv.conf" whidle it was
> immutable, didn't leave traces.
> Not even a log for permission error because of the immutable flag. At least
> not in /var/log anyway.

I can't say I'm shocked. But you *did* find an entry from auditd, which
presumably has a timestamp. Check to see what was happening right at
that moment in other log files.

In particular, check whether a DHCP client daemon renewed its DHCP lease
at that time.

[David Wright]

On Thu 23 Feb 2023 at 11:23:30 (+0100), dave...@tuxfamily.org wrote:
> On 2023-02-23 02:59, con...@panix.com wrote:
> > On 2/22/23, dave...@tuxfamily.org <dave...@tuxfamily.org> wrote:
> > >
> > > There is an unidentified process that decides it's ok to delete and
> > > recreate /etc/resolv.conf without asking user/admin,
> > > The problem is, the problematic process is not work's VPN related and
> > > creates the file with wrong resolver's IP. The IP corresponds
> > > to my home
> > > router IP, which does has a DNS resolver and it works as it
> > > should. BUT
> > > my home's router DNS obviously don't know jack about work internal
> > > servers, on which I work… and work's proxy as well, which
> > > when it cannot
> > > be resolved… breaks everything using HTTP.
> >
> > Might look at:
> >
> > /etc/network/interfaces.d/setup
> >
> > as explained in "man interfaces". (That file can/might be changed via
> > the network symbol in the window manager's configuration bar/menu
> > system, usually required with root/sudo privileges.)
>

> There's nothing relevant to change in that file. I don't want to have
> static IP. And the right interface name is not in it.
>
> I'm not sure whether that file became totally obsoleled, or if it's
> not normal that it doesn't contain the expected interface name? has it
> been deprecated since debian switched to systemd so-called
> "predictable" iface names?
>
> For some reasons, since debian 9 or 10 (id nor 8?), including debian
> 11 new installs (work laptop has been install slightly more than a
> year ago),
> that files only contains the eth0 and local interfaces name, while
> debian switched to systemd style interfaces names.
> I remembrer having slowed down boots because of the that, on my
> personal laptop, when debian switched to systemd style names and that
> file still referred to eth0 which doesn't exist
> So boot process was waiting for eth0 interface until I commented out
> that part (eth0 block) of interfaces files.
>
> On the newer work laptop on the other hand, there is that eth0 block,
> there's is no eth0 interface on my system (there's enp.* and enx.*
> systemd names, instead)
> BUT I never had the slow/timeout-waiting boot process unlike the
> personal was reinstall from zero instead of upgraded years ago only to
> change HDD to SSD, and to change partitioning to encrypted LVM.

What are these enp… (waste of time hiding that name) and enx…
interfaces (and any others), and what are they used for.

> So my guess is /etc/network/interface.* has been replaced with
> something also. Since it refers to non-exitent interfaces names
> without breaking the network or slowing down the boot process.
>
> Also, the switching to systemd styles interfaces names has been
> following by a weird behaviour on my personal computer. It has a
> "failed" error message at startup, for the network (or is networking?
> it never remember the correct name) service, without breaking the
> network… it weirdly just works. I never figured out what replaces that
> service. If anyone has any idea?

Different installation scripts and/or individual sysadmins can place
files with a variety of names in /etc/network/interface.d/. So their
removal can be rather sporadic: Debian won't know their names, and
deinstallation scripts might leave them, if they get run at all.

It's worrying that such files are there if they have the wrong
interface names in them. It might suggest ancient cruft or, just
as easily, network installation scripts that are broken, or designed
for a different system/distribution.

What's the output from ls -lR /etc/network* /etc/systemd/network*

Cheers,
David.

[dave...@tuxfamily.org]

On 2023-02-28 05:27, David Wright wrote:
> On Thu 23 Feb 2023 at 11:23:30 (+0100), dave...@tuxfamily.org wrote:
>> On 2023-02-23 02:59, con...@panix.com wrote:
>>
>> […]
>>

>> On the newer work laptop on the other hand, there is that eth0 block,
>> there's is no eth0 interface on my system (there's enp.* and enx.*
>> systemd names, instead)
>> BUT I never had the slow/timeout-waiting boot process unlike the
>> personal was reinstall from zero instead of upgraded years ago only to
>> change HDD to SSD, and to change partitioning to encrypted LVM.
>
> What are these enp… (waste of time hiding that name) and enx…
> interfaces (and any others), and what are they used for.
>

It's the systemd-style so-called "predictable" interfaces names.
Replacing the older the eth0, wlan0, and so on…

ens-something (annoying name made of multiple letters and digits) is the
new name for eth0
wlx-something or wlp-something for wlan0
enx-insert-long-hexadecimal-number-here is well… I have no damn idea.

Seen this last one only my work's computer, not personal one. Much
newer, maybe have some optional network hardware?
Not sure, but it's not virtual interface for the VPN. which is still
named tun0 as it used to be before systemd.
And the unknown interface is still around even without the VPN process
running

And it's not really hiding. it's just a name I can never fully remember
and didn't bother to check full name. It doesn't really matter.
What matters is the interface is not called eth0 anymore, but is
instead called ens-whatever-thefullname-is. And the interface name used
in
/etc/network/interfaces.d/setup refers to a network interface which
doen't exist anymore

Yet it does NOT break the network, that why I think something else
replaced.
Otherwise, I fail to see how it would work while referencing to the
wrong interface name.

(Also, the new name for wlan0 interface is "wlx" followed by an UID *on
some* systems. not all
So it actually does make sense to hide it, for such systems)

>> So my guess is /etc/network/interface.* has been replaced with
>> something also. Since it refers to non-exitent interfaces names
>> without breaking the network or slowing down the boot process.
>>
>> Also, the switching to systemd styles interfaces names has been
>> following by a weird behaviour on my personal computer. It has a
>> "failed" error message at startup, for the network (or is networking?
>> it never remember the correct name) service, without breaking the
>> network… it weirdly just works. I never figured out what replaces that
>> service. If anyone has any idea?
>
> Different installation scripts and/or individual sysadmins can place
> files with a variety of names in /etc/network/interface.d/. So their
> removal can be rather sporadic: Debian won't know their names, and
> deinstallation scripts might leave them, if they get run at all.
>
> It's worrying that such files are there if they have the wrong
> interface names in them. It might suggest ancient cruft or, just
> as easily, network installation scripts that are broken, or designed
> for a different system/distribution.
>
> What's the output from ls -lR /etc/network* /etc/systemd/network*

Here's the output.

---

ls -lR /etc/network* /etc/systemd/network*
-rw-r--r-- 1 root root 60 9 oct. 2021 /etc/networks
-rw-r--r-- 1 root root 609 2 févr. 2021 /etc/systemd/networkd.conf

/etc/network:
total 24
drwxr-xr-x 2 root root 4096 21 févr. 15:52 if-down.d
drwxr-xr-x 2 root root 4096 2 déc. 2021 if-post-down.d
drwxr-xr-x 2 root root 4096 2 déc. 2021 if-pre-up.d
drwxr-xr-x 2 root root 4096 21 févr. 15:52 if-up.d
-rw-r--r-- 1 root root 321 2 déc. 2021 interfaces
drwxr-xr-x 2 root root 4096 2 déc. 2021 interfaces.d

/etc/network/if-down.d:
total 8
-rwxr-xr-x 1 root root 1015 6 févr. 2021 avahi-autoipd
-rwxr-xr-x 1 root root 1677 13 janv. 2022 clamav-freshclam-ifupdown
lrwxrwxrwx 1 root root 32 2 déc. 2021 wpasupplicant ->
../../wpa_supplicant/ifupdown.sh

/etc/network/if-post-down.d:
total 4
-rwxr-xr-x 1 root root 1409 7 mars 2020 wireless-tools
lrwxrwxrwx 1 root root 32 2 déc. 2021 wpasupplicant ->
../../wpa_supplicant/ifupdown.sh

/etc/network/if-pre-up.d:
total 12
-rwxr-xr-x 1 root root 344 30 juin 2016 ethtool
-rwxr-xr-x 1 root root 4191 7 mars 2020 wireless-tools
lrwxrwxrwx 1 root root 32 2 déc. 2021 wpasupplicant ->
../../wpa_supplicant/ifupdown.sh

/etc/network/if-up.d:
total 12
-rwxr-xr-x 1 root root 923 6 févr. 2021 avahi-autoipd
-rwxr-xr-x 1 root root 1677 13 janv. 2022 clamav-freshclam-ifupdown
-rwxr-xr-x 1 root root 1685 30 juin 2016 ethtool
lrwxrwxrwx 1 root root 32 2 déc. 2021 wpasupplicant ->
../../wpa_supplicant/ifupdown.sh

/etc/network/interfaces.d:
total 4
-rw-r--r-- 1 root root 63 9 oct. 2021 setup

/etc/systemd/network:
total 0

---

Not sue if it contains anything DHCP client related
Beside the /etc/network/interfaces.d/setup which contains only local
interface and eth0
But again. I don't to fully stop using DHCP, which is would be the most
obvious thing I could do on the setup file if it were used.

I just don't want the DHCP client send requests to my home's network
instead of sending requests through the VPN route
so the workplace's DHCP sees and answers to the requests, instead of
home router answering to these requests

I fail to see why the DHCP client would send it requests to 192.168.1.1
(my home's gateway) instead of using the VPN interface/route/whatever.
dhclient must have some wrong conf, but I never changed the default
conf, So I have no idea what part may be wrong or what's missing

>
> Cheers,
> David.

[Tixy]

On Tue, 2023-02-28 at 16:05 +0100, dave...@tuxfamily.org wrote:
>
> It's the systemd-style so-called "predictable" interfaces names.
> Replacing the older the eth0, wlan0, and so on…
>
> ens-something (annoying name made of multiple letters and digits) is the
> new name for eth0

Or eno<NUMBER> for ethernet too. My ethernet started out as eno2 when I
did the initial install and this changed to eno1 when I disabled the
onboard wireless in the bios.

-- 
Tixy

[David Wright]

Yes, sorry, I won't bother with understanding what interfaces are
present on which systems, and which ones are used for what, when.
(If you reread my question above, you'll see that I didn't ask you
to reveal the MAC address of your wifi, BTW.)

> > > So my guess is /etc/network/interface.* has been replaced with
> > > something also. Since it refers to non-exitent interfaces names
> > > without breaking the network or slowing down the boot process.
> > >
> > > Also, the switching to systemd styles interfaces names has been
> > > following by a weird behaviour on my personal computer. It has a
> > > "failed" error message at startup, for the network (or is networking?
> > > it never remember the correct name) service, without breaking the
> > > network… it weirdly just works. I never figured out what replaces that
> > > service. If anyone has any idea?
> >
> > Different installation scripts and/or individual sysadmins can place
> > files with a variety of names in /etc/network/interface.d/. So their
> > removal can be rather sporadic: Debian won't know their names, and
> > deinstallation scripts might leave them, if they get run at all.
> >
> > It's worrying that such files are there if they have the wrong
> > interface names in them. It might suggest ancient cruft or, just
> > as easily, network installation scripts that are broken, or designed
> > for a different system/distribution.
> >
> > What's the output from ls -lR /etc/network* /etc/systemd/network*
>
> Here's the output.
>

[ … ]

>
> Not sue if it contains anything DHCP client related
> Beside the /etc/network/interfaces.d/setup which contains only local
> interface and eth0

Well, it looks like cruft from an earlier installation of networking;
and a couple of months later, you installed ifupdown and wpasupplicant,
by the looks of things. I don't know whether /etc/network/interfaces
itself would interfere with however connman is configured.

> But again. I don't to fully stop using DHCP, which is would be the
> most obvious thing I could do on the setup file if it were used.
>
> I just don't want the DHCP client send requests to my home's network
> instead of sending requests through the VPN route
> so the workplace's DHCP sees and answers to the requests, instead of
> home router answering to these requests
>
> I fail to see why the DHCP client would send it requests to
> 192.168.1.1 (my home's gateway) instead of using the VPN
> interface/route/whatever.
> dhclient must have some wrong conf, but I never changed the default
> conf, So I have no idea what part may be wrong or what's missing

I had thought that it might be possible to configure a package like
openresolv to manage the contention between the configurations, but
judging what I've learned about your networking setup, it's probably
easier just to hack it, using the method at the bottom of the wiki
page, simply making resolv.conf immutable when your vpn starts up,
and mutable when it stops, using Reco's suggestion. That should save
you bothering with how the rest of your configuration is set up.
And do remember to make the file mutable at boot time, in case your
computer should crash while it's immutable.

Cheers,
David.

[dave...@tuxfamily.org]

On 2023-03-02 00:24, David Wright wrote:
> On Tue 28 Feb 2023 at 16:05:14 (+0100), dave...@tuxfamily.org wrote:
>> On 2023-02-28 05:27, David Wright wrote:
>> > On Thu 23 Feb 2023 at 11:23:30 (+0100), dave...@tuxfamily.org wrote:
>> > > On 2023-02-23 02:59, con...@panix.com wrote:
> [ … ]
>

> Well, it looks like cruft from an earlier installation of networking;
> and a couple of months later, you installed ifupdown and wpasupplicant,
> by the looks of things. I don't know whether /etc/network/interfaces
> itself would interfere with however connman is configured.
>

This system never had any debian 10 or lower. It has been issued to my
by $worksplace
in december 2021, initially running windows.

I erased the full disk and installed à "default" (official image) debian
11, from an LXDE live USB image
It has never had any interface named eth0. I still fail to see why setup
conf would refer to eth0 at all

Then I few month later, I finally took the time to debug why WiFi card
didn't work/what firmware is needed
Debian's firmware packaged started supporting the WLAN/WiFi card
after I installed my system.

So then I installed the firmware. I most likely installed wpasuppicant
the same day, and tested it worked.

Not sure about ifup thought. Doesn't seem to be a wpasupplicant
dependency.

akb@akira:~$ LC_ALL=C aptitude why ifupdown
p netscript-2.4 Provides ifupdown
p netscript-2.4 Depends bridge-utils (>= 0.9.3)
p bridge-utils Suggests ifupdown
akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
p netscript-2.4 Provides ifupdown

Why openresolv wouldn't work?

>
> Cheers,
> David.

[dave...@tuxfamily.org]

Hello

On 2023-02-24 10:19, dave...@tuxfamily.org wrote:
> Hello,
>
>> […]

>>
>>> 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.

I finally had the time to dig into the logs from two days ago, when the
problem happens again
It seems that dhclient does it requests trying different interfaces
EXCEPT tun0 (see syslog below)

I looked into /etc/dhcp/dhclient.conf, which mostly commented. In the
non-commented part shown below
I don't see anything related to which interfaces are to be used as
arguments when dhclient is executed
But I'm not a dhclient expert.

At boot time/without VPN, dhclient is executed with enp.* interface
accondinng to systemctl/ps -eFH.
But It still tries different interfaces according to logs. And I have no
idea how it detects
which interfaces to use for it requests and why it doesn't detect tun0.
Maybe because tun0 is not yet exposed by the system at boot time when
dhclient is started?

It stills try wlan interface even if it is down, which is weird, but
doesn't seem to do harm except
spamming syslog and spending a few additional seconds before trying
another interface.

------------

dave@debian-laptop:~$ cat /etc/dhcp/dhclient.conf
-
send host-name = gethostname();
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, domain-search, host-name,
dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn,
dhcp6.sntp-servers,
netbios-name-servers, netbios-scope, interface-mtu,
rfc3442-classless-static-routes, ntp-servers;
-
------------
dave@debian-laptop:~$ systemctl status

├─if...@enp2s0f0.service
│ └─1093 /sbin/dhclient -4 -v -i -pf
/run/dhclient.enp2s0f0.pid -lf /var/lib/dhcp/dhclient.enp2s0f0.leases -I
-df /var/lib/dhcp/dhclient6.enp2s0f0.leases enp2s0f0

------------


dave@debian-laptop:~$ sudo ausearch --interpret --file /etc/resolv.conf
----
type=PROCTITLE msg=audit(28/02/2023 14:30:57.787:658) : proctitle=mv -f
/etc/resolv.conf.dhclient-new.46082 /etc/resolv.conf
type=PATH msg=audit(28/02/2023 14:30:57.787:658) : item=3
name=/etc/resolv.conf inode=786809 dev=fd:01 mode=file,644 ouid=root
ogid=root rdev=00:00 nametype=DELETE cap_fp=none cap_fi=none cap_fe=0
cap_fver=0 cap_frootid=0
type=PATH msg=audit(28/02/2023 14:30:57.787:658) : item=2
name=/etc/resolv.conf.dhclient-new.46082 inode=786811 dev=fd:01
mode=file,644 ouid=root ogid=root rdev=00:00 nametype=DELETE cap_fp=none
cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(28/02/2023 14:30:57.787:658) : item=1 name=/etc/
inode=783361 dev=fd:01 mode=dir,755 ouid=root ogid=root rdev=00:00
nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
cap_frootid=0
type=PATH msg=audit(28/02/2023 14:30:57.787:658) : item=0 name=/etc/
inode=783361 dev=fd:01 mode=dir,755 ouid=root ogid=root rdev=00:00
nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
cap_frootid=0
type=CWD msg=audit(28/02/2023 14:30:57.787:658) : cwd=/
type=SYSCALL msg=audit(28/02/2023 14:30:57.787:658) : arch=x86_64
syscall=rename success=no exit=EPERM(Opération non permise)
a0=0x7ffc38ee0a9e a1=0x7ffc38ee0ac2 a2=0x0 a3=0xfffffffffffffa4d items=4
ppid=46082 pid=46093 auid=unset uid=root gid=root euid=root suid=root
fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=mv
exe=/usr/bin/mv subj=unconfined key=(null)
----

Note : exit=EPERM can be ignored, because it happened while I made
/etc/resolv.conf immutable

------------

dave@debian-laptop:~$ less /var/log/syslog
Feb 28 14:30:48 debian-laptop dhclient[2016]: DHCPDISCOVER on wlp3s0 to
255.255.255.255 port 67 interval 3
Feb 28 14:30:51 debian-laptop dhclient[39759]: DHCPDISCOVER on
enx8c8caa616f43 to 255.255.255.255 port 67 interval 5
Feb 28 14:30:51 debian-laptop dhclient[2016]: DHCPDISCOVER on wlp3s0 to
255.255.255.255 port 67 interval 4
Feb 28 14:30:55 debian-laptop dhclient[2016]: DHCPDISCOVER on wlp3s0 to
255.255.255.255 port 67 interval 11
Feb 28 14:30:56 debian-laptop dhclient[39759]: DHCPDISCOVER on
enx8c8caa616f43 to 255.255.255.255 port 67 interval 9
Feb 28 14:30:57 debian-laptop dhclient[1003]: DHCPREQUEST for
192.168.1.192 on enp2s0f0 to 192.168.1.1 port 67
Feb 28 14:30:57 debian-laptop dhclient[1003]: DHCPACK of 192.168.1.192
from 192.168.1.1
Feb 28 14:30:57 debian-laptop connmand[1038]: enp2s0f0 {add} address
192.168.1.192/24 label enp2s0f0 family 2
Feb 28 14:30:57 debian-laptop avahi-daemon[1034]: Registering new
address record for 192.168.1.192 on enp2s0f0.IPv4.
Feb 28 14:30:57 debian-laptop dhclient[1003]: bound to 192.168.1.192 --
renewal in 17866 seconds.
Feb 28 14:31:05 debian-laptop dhclient[39759]: DHCPDISCOVER on
enx8c8caa616f43 to 255.255.255.255 port 67 interval 12
Feb 28 14:31:06 debian-laptop dhclient[2016]: DHCPDISCOVER on wlp3s0 to
255.255.255.255 port 67 interval 11
Feb 28 14:31:17 debian-laptop dhclient[39759]: DHCPDISCOVER on
enx8c8caa616f43 to 255.255.255.255 port 67 interval 14
Feb 28 14:31:17 debian-laptop systemd[1]: Started Run anacron jobs.
Feb 28 14:31:17 debian-laptop anacron[46104]: Anacron 2.3 started on
2023-02-28
Feb 28 14:31:17 debian-laptop anacron[46104]: Normal exit (0 jobs run)
Feb 28 14:31:17 debian-laptop systemd[1]: anacron.service: Succeeded.
Feb 28 14:31:17 debian-laptop dhclient[2016]: DHCPDISCOVER on wlp3s0 to
255.255.255.255 port 67 interval 13
Feb 28 14:31:24 debian-laptop dhclient[39759]: DHCPDISCOVER on wlp3s0 to
255.255.255.255 port 67 interval 8
Feb 28 14:31:30 debian-laptop dhclient[2016]: DHCPDISCOVER on wlp3s0 to
255.255.255.255 port 67 interval 8
Feb 28 14:31:31 debian-laptop dhclient[39759]: DHCPDISCOVER on
enx8c8caa616f43 to 255.255.255.255 port 67 interval 16
Feb 28 14:31:32 debian-laptop dhclient[39759]: DHCPDISCOVER on wlp3s0 to
255.255.255.255 port 67 interval 17
Feb 28 14:31:37 debian-laptop rtkit-daemon[1368]: Supervising 18 threads
of 8 processes of 1 users.
Feb 28 14:31:37 debian-laptop rtkit-daemon[1368]: Supervising 18 threads
of 8 processes of 1 users.
Feb 28 14:31:38 debian-laptop dhclient[2016]: DHCPDISCOVER on wlp3s0 to
255.255.255.255 port 67 interval 11
Feb 28 14:31:47 debian-laptop dhclient[39759]: DHCPDISCOVER on
enx8c8caa616f43 to 255.255.255.255 port 67 interval 5
Feb 28 14:31:49 debian-laptop dhclient[2016]: No DHCPOFFERS received.
Feb 28 14:31:49 debian-laptop dhclient[2016]: No working leases in
persistent database - sleeping.
Feb 28 14:31:49 debian-laptop dave:
/etc/dhcp/dhclient-exit-hooks.d/zzz_avahi-autoipd returned non-zero exit
status 1
Feb 28 14:31:49 debian-laptop dhclient[39759]: DHCPDISCOVER on wlp3s0 to
255.255.255.255 port 67 interval 19
Feb 28 14:31:52 debian-laptop dhclient[39759]: No DHCPOFFERS received.
Feb 28 14:31:52 debian-laptop dhclient[39759]: No working leases in
persistent database - sleeping.
Feb 28 14:31:52 debian-laptop dave:
/etc/dhcp/dhclient-exit-hooks.d/zzz_avahi-autoipd returned non-zero exit
status 1
Feb 28 14:32:08 debian-laptop dhclient[39759]: DHCPDISCOVER on wlp3s0 to
255.255.255.255 port 67 interval 15
Feb 28 14:32:23 debian-laptop dhclient[39759]: DHCPDISCOVER on wlp3s0 to
255.255.255.255 port 67 interval 2
Feb 28 14:32:25 debian-laptop dhclient[39759]: No DHCPOFFERS received.
Feb 28 14:32:25 debian-laptop dhclient[39759]: No working leases in
persistent database - sleeping.
Feb 28 14:32:25 debian-laptop dave:
/etc/dhcp/dhclient-exit-hooks.d/zzz_avahi-autoipd returned non-zero exit
status 1
Feb 28 14:32:48 debian-laptop dhclient[39759]: DHCPDISCOVER on
wlp3s0:avahi to 255.255.255.255 port 67 interval 8
Feb 28 14:32:56 debian-laptop dhclient[39759]: DHCPDISCOVER on
wlp3s0:avahi to 255.255.255.255 port 67 interval 11
Feb 28 14:33:07 debian-laptop dhclient[39759]: DHCPDISCOVER on
wlp3s0:avahi to 255.255.255.255 port 67 interval 12

------------

[Greg Wooledge]

On Thu, Mar 02, 2023 at 10:32:41AM +0100, dave...@tuxfamily.org wrote:
> This system never had any debian 10 or lower. It has been issued to my by
> $worksplace
> in december 2021, initially running windows.

> akb@akira:~$ LC_ALL=C aptitude why ifupdown
> p netscript-2.4 Provides ifupdown
> p netscript-2.4 Depends bridge-utils (>= 0.9.3)
> p bridge-utils Suggests ifupdown
> akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
> p netscript-2.4 Provides ifupdown

unicorn:~$ apt-cache show netscript-2.4
[...]
Description-en: Linux 2.4/2.6/3.x router/firewall/VM host network config system.
This is a router and firewall network configuration system. It is specific to
the 2.4.x and 2.6.x kernel series. This system is in production use, even
though this is an experimental version.
[...]
DON'T use this on a pure server - it is VERY useful for a Virtual Machine
server with complex networking needs. This is because of its comprehensive
network configuration capabilities. Thus it is a tempting replacement
when you have to rip out NetworkManager on a server.


That sounds pretty terrifying to me. I'm surprised it works *at all*
with a Debian 11 (or higher? you didn't say what you *are* running,
only what you're *not* running) kernel.

[dave...@tuxfamily.org]

Obviously NOT those old kernels. I'm runnning kernel 5.10

~$ uname -r
5.10.0-21-amd64

Why is this paquet installed at all then?

[dave...@tuxfamily.org]

dpkg -l netscript-2.4 or even dpkg -l | grep netscript

Don't return anything… Not sure why "aptitude why ifupdown" mentions
netscript-2.4 at all

[Greg Wooledge]

On Thu, Mar 02, 2023 at 02:01:57PM +0100, dave...@tuxfamily.org wrote:

> > > > akb@akira:~$ LC_ALL=C aptitude why ifupdown
> > > > p netscript-2.4 Provides ifupdown
> > > > p netscript-2.4 Depends bridge-utils (>= 0.9.3)
> > > > p bridge-utils Suggests ifupdown
> > > > akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
> > > > p netscript-2.4 Provides ifupdown

> dpkg -l netscript-2.4 or even dpkg -l | grep netscript
>
> Don't return anything… Not sure why "aptitude why ifupdown" mentions
> netscript-2.4 at all

Oh, that's reassuring. And also confusing.

Man, I really wish the aptitude(8) man page would explain how to read
the output of "why". What does the "p" mean? Purged? There's nothing
in the man page that explains the symbols in the first 3 columns, as
far as I can find.

I have *no* idea how to interpret this:

unicorn:~$ aptitude why ifupdown

p netscript-2.4 Provides ifupdown
p netscript-2.4 Depends bridge-utils (>= 0.9.3)
p bridge-utils Suggests ifupdown

unicorn:~$ dpkg -l ifupdown | tail -n1
ii ifupdown 0.8.36 amd64 high level tools to configure network interfaces

Maybe "aptitude why" simply can't handle packages that are part of
the base system ("Essential", or priority "required" or "important"),
or which have been manually installed and aren't part of a dependency...?

unicorn:~$ aptitude why bash
i bash-builtins Depends bash (= 5.1-2+deb11u1)
unicorn:~$ aptitude why dpkg
i google-chrome-stable PreDepends dpkg (>= 1.14.0)
unicorn:~$ aptitude why abcde
Manually installed, current version 2.9.3-1, priority optional
No dependencies require to install abcde

OK, I guess it handles manually installed packages. But not base
system packages... at least not in a way one would expect.

In any case, ifupdown is an "important" package, and should be present
on almost all Debian systems, regardless of what "aptitude why" says
about it.

unicorn:~$ dpkg -s ifupdown | grep Prio
Priority: important

[dave...@tuxfamily.org]

On 2023-03-02 14:19, Greg Wooledge wrote:
> On Thu, Mar 02, 2023 at 02:01:57PM +0100, dave...@tuxfamily.org wrote:
>
>> > > > akb@akira:~$ LC_ALL=C aptitude why ifupdown
>> > > > p netscript-2.4 Provides ifupdown
>> > > > p netscript-2.4 Depends bridge-utils (>= 0.9.3)
>> > > > p bridge-utils Suggests ifupdown
>> > > > akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
>> > > > p netscript-2.4 Provides ifupdown
>
>> dpkg -l netscript-2.4 or even dpkg -l | grep netscript
>>
>> Don't return anything… Not sure why "aptitude why ifupdown" mentions
>> netscript-2.4 at all
>
> Oh, that's reassuring. And also confusing.
>
> Man, I really wish the aptitude(8) man page would explain how to read
> the output of "why". What does the "p" mean? Purged? There's nothing
> in the man page that explains the symbols in the first 3 columns, as
> far as I can find.

I wonder if aptitude just uses the dpkg-query abbreviations,
so "purged" seems a reasonable guess. But yeah, it would be
much more helpful if aptitude(8) man was not that ambiguous
about those abbreviations

Good to know. I'd except it to be installed by default by the way.
Looking again at files in /etc/network, there are

drwxr-xr-x 2 root root 4096 2 déc. 2021 if-post-down.d
drwxr-xr-x 2 root root 4096 2 déc. 2021 if-pre-up.d

The laptop was installed on the 2nd December 2021, so the files existed
from day one,
But if-down.d and if-up.d content was updated later.
Must by the reason why someone (don't remember their name) on this
thread suggested I have installed
ifupdown a few months laters.

[David]

On Fri, 3 Mar 2023 at 00:19, Greg Wooledge <gr...@wooledge.org> wrote:

> Man, I really wish the aptitude(8) man page would explain how to read
> the output of "why". What does the "p" mean? Purged? There's nothing
> in the man page that explains the symbols in the first 3 columns, as
> far as I can find.

Yeah. It does mean purged, or never installed.

p - the package and all its configuration files were removed, or the
package was never installed.

>From here (Buster):
grep -A 16 'Figure.2\.9\.' /usr/share/aptitude/README

[David]

On Fri, 3 Mar 2023 at 02:18, <dave...@tuxfamily.org> wrote:
> On 2023-03-02 14:19, Greg Wooledge wrote:
> > On Thu, Mar 02, 2023 at 02:01:57PM +0100, dave...@tuxfamily.org wrote:

> >> > > > akb@akira:~$ LC_ALL=C aptitude why ifupdown
> >> > > > p netscript-2.4 Provides ifupdown
> >> > > > p netscript-2.4 Depends bridge-utils (>= 0.9.3)
> >> > > > p bridge-utils Suggests ifupdown
> >> > > > akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
> >> > > > p netscript-2.4 Provides ifupdown
> >
> >> dpkg -l netscript-2.4 or even dpkg -l | grep netscript
> >>
> >> Don't return anything… Not sure why "aptitude why ifupdown" mentions
> >> netscript-2.4 at all

You could try 'aptitude -v why' to add verbosity.

/usr/share/aptitude/README has some discussion about
the behaviour of 'why' and 'why-not'. Under the heading
'why, why-not'.

[Curt]

On 2023-03-02, David <bounci...@gmail.com> wrote:
> On Fri, 3 Mar 2023 at 00:19, Greg Wooledge <gr...@wooledge.org> wrote:
>
>> Man, I really wish the aptitude(8) man page would explain how to read
>> the output of "why". What does the "p" mean? Purged? There's nothing
>> in the man page that explains the symbols in the first 3 columns, as
>> far as I can find.
>
> Yeah. It does mean purged, or never installed.
>
> p - the package and all its configuration files were removed, or the
> package was never installed.

Those seem like antithetical concepts.

>>From here (Buster):
> grep -A 16 'Figure.2\.9\.' /usr/share/aptitude/README
>
>

--

[David Wright]

On Thu 02 Mar 2023 at 17:23:23 (-0000), Curt wrote:
> On 2023-03-02, David <bounci...@gmail.com> wrote:
> > On Fri, 3 Mar 2023 at 00:19, Greg Wooledge <gr...@wooledge.org> wrote:
> >
> >> Man, I really wish the aptitude(8) man page would explain how to read
> >> the output of "why". What does the "p" mean? Purged? There's nothing
> >> in the man page that explains the symbols in the first 3 columns, as
> >> far as I can find.

It's easy to miss, because the key to the letters is given in running
text a hundred lines away. (man chmod is a loathsome example of this
format.) The reference below is much better, as the figure is a table
(as well as being comprehensive).

> > Yeah. It does mean purged, or never installed.
> >
> > p - the package and all its configuration files were removed, or the
> > package was never installed.
>
> Those seem like antithetical concepts.

The state is identical in both cases, hence using the same letter.
OTOH the paths to that state can be different, and that's significant
because installing and then purging a package can have side-effects
on the system that don't get reverted to the inital state, eg the
installation of Depends/Recommends.

> >>From here (Buster):
> > grep -A 16 'Figure.2\.9\.' /usr/share/aptitude/README

and bullseye.

Cheers,
David.

[to...@tuxteam.de]

On Thu, Mar 02, 2023 at 12:14:14PM -0600, David Wright wrote:
> On Thu 02 Mar 2023 at 17:23:23 (-0000), Curt wrote:
> > On 2023-03-02, David <bounci...@gmail.com> wrote:

[...]

> > Those seem like antithetical concepts.
>
> The state is identical in both cases, hence using the same letter.
> OTOH the paths to that state can be different, and that's significant
> because installing and then purging a package can have side-effects
> on the system that don't get reverted to the inital state, eg the
> installation of Depends/Recommends.

Heh, you stole my thoughts. I was going "hm, the node in the state
diagram is the same, just the edges are different" :-)

Cheers
--
t

[Tim Woodall]

On Thu, 2 Mar 2023, dave...@tuxfamily.org wrote:

> Hello
>
> On 2023-02-24 10:19, dave...@tuxfamily.org wrote:
>> Hello,
>>

>>> [?]

>>>
>>>> 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.
>
> I?finally had the time to dig into the logs from two days ago, when the

> problem happens again
> It seems that dhclient does it requests trying different interfaces EXCEPT
> tun0 (see syslog below)
>

New to this thread, so might be totally off-piste but openvpn has hooks
to run scripts like this:

script-security 2
route-up "/etc/network/scripts/openvpn-tun0-up"
route-pre-down "/etc/network/scripts/openvpn-tun0-down"
client-connect "/etc/network/scripts/openvpn-client-connect"
client-disconnect "/etc/network/scripts/openvpn-client-disconnect"

This is server side but the route-up/pre-down work client side too.

Presumably you can do something here to renew dhcp leases or restore
resolv.conf.

I'd assume whatever vpn you're using will have similar hooks, or
possibly you xan use the default ones in /etc/network?

Tim

[David Wright]

On Thu 02 Mar 2023 at 10:32:41 (+0100), dave...@tuxfamily.org wrote:
> On 2023-03-02 00:24, David Wright wrote:
> > On Tue 28 Feb 2023 at 16:05:14 (+0100), dave...@tuxfamily.org wrote:
> > > On 2023-02-28 05:27, David Wright wrote:
> > > > On Thu 23 Feb 2023 at 11:23:30 (+0100), dave...@tuxfamily.org wrote:
> > > > > On 2023-02-23 02:59, con...@panix.com wrote:
> > [ … ]
> >
> > Well, it looks like cruft from an earlier installation of networking;
> > and a couple of months later, you installed ifupdown and wpasupplicant,
> > by the looks of things. I don't know whether /etc/network/interfaces
> > itself would interfere with however connman is configured.
> >
>
> This system never had any debian 10 or lower. It has been issued to my
> by $worksplace
> in december 2021, initially running windows.
>
> I erased the full disk and installed à "default" (official image)
> debian 11, from an LXDE live USB image

I know nothing about LXDE (or other DEs).

> It has never had any interface named eth0. I still fail to see why
> setup conf would refer to eth0 at all

Some clues are the setup's contents, other files on the system with
contemporaneous timestamps, /var/log/installer/syslog's contents, and so on.

> Then I few month later, I finally took the time to debug why WiFi card
> didn't work/what firmware is needed
> Debian's firmware packaged started supporting the WLAN/WiFi card
> after I installed my system.
>
> So then I installed the firmware. I most likely installed wpasuppicant
> the same day, and tested it worked.
>
> Not sure about ifup thought. Doesn't seem to be a wpasupplicant
> dependency.
>
> akb@akira:~$ LC_ALL=C aptitude why ifupdown
> p netscript-2.4 Provides ifupdown
> p netscript-2.4 Depends bridge-utils (>= 0.9.3)
> p bridge-utils Suggests ifupdown
> akb@akira:~$ LC_ALL=C aptitude why netscript-2.4
> p netscript-2.4 Provides ifupdown

This suggests that you or the installer installed ifupdown, and that
it's a top-level package. I would have expected a response more like:

$ aptitude why apt-file
Manually installed, current version 3.2.2, priority optional
No dependencies require to install apt-file
$

but I guess the Provides has some influence. Both ifupdown2 and
netscript can be used instead of ifupdown, though the latter is
for a more specialised scenario.

It's always possible that ifupdown was installed as an alternative
to connman, which is also in the Live image. I don't know which gets
started by default, either in Live, or the subsequent installation
from Live.

> Why openresolv wouldn't work?

That doesn't parse, and without any context, I don't know what it means.

Cheers,
David.

[David Wright]

On Thu 02 Mar 2023 at 11:44:17 (+0100), dave...@tuxfamily.org wrote:
>
> I finally had the time to dig into the logs from two days ago, when
> the problem happens again
> It seems that dhclient does it requests trying different interfaces
> EXCEPT tun0 (see syslog below)
>
> I looked into /etc/dhcp/dhclient.conf, which mostly commented. In the
> non-commented part shown below
> I don't see anything related to which interfaces are to be used as
> arguments when dhclient is executed
> But I'm not a dhclient expert.
>
> At boot time/without VPN, dhclient is executed with enp.* interface
> accondinng to systemctl/ps -eFH.
> But It still tries different interfaces according to logs. And I have
> no idea how it detects
> which interfaces to use for it requests and why it doesn't detect tun0.
> Maybe because tun0 is not yet exposed by the system at boot time when
> dhclient is started?
>
> It stills try wlan interface even if it is down, which is weird, but
> doesn't seem to do harm except
> spamming syslog and spending a few additional seconds before trying
> another interface.

It's not clear what the status of your vpn was when the logs were
written, AFAICT. It's obviously not soon after booting, as you have
processes running with PIDs in the 40,000s.

It would make sense to start and stop the vnc from a terminal in which
script (bsdutils) was running, preferably with -T to add timestamps to
each command. You could then reconcile the logs with what you were doing.

> ------------
> dave@debian-laptop:~$ systemctl status
>
> ├─if...@enp2s0f0.service
> │ └─1093 /sbin/dhclient -4 -v -i -pf
> /run/dhclient.enp2s0f0.pid -lf /var/lib/dhcp/dhclient.enp2s0f0.leases
> -I -df /var/lib/dhcp/dhclient6.enp2s0f0.leases enp2s0f0
>
> ------------

I don't know why ifupdown is running, as I thought you were
controlling the network with connman.

This appears to show mv -f /etc/resolv.conf.dhclient-new.46082 /etc/resolv.conf
failing, as expected.

> ------------
>
> dave@debian-laptop:~$ less /var/log/syslog
> Feb 28 14:30:48 debian-laptop dhclient[2016]: DHCPDISCOVER on wlp3s0
> to 255.255.255.255 port 67 interval 3
> Feb 28 14:30:51 debian-laptop dhclient[39759]: DHCPDISCOVER on
> enx8c8caa616f43 to 255.255.255.255 port 67 interval 5
> Feb 28 14:30:51 debian-laptop dhclient[2016]: DHCPDISCOVER on wlp3s0
> to 255.255.255.255 port 67 interval 4
> Feb 28 14:30:55 debian-laptop dhclient[2016]: DHCPDISCOVER on wlp3s0
> to 255.255.255.255 port 67 interval 11
> Feb 28 14:30:56 debian-laptop dhclient[39759]: DHCPDISCOVER on
> enx8c8caa616f43 to 255.255.255.255 port 67 interval 9
> Feb 28 14:30:57 debian-laptop dhclient[1003]: DHCPREQUEST for
> 192.168.1.192 on enp2s0f0 to 192.168.1.1 port 67
> Feb 28 14:30:57 debian-laptop dhclient[1003]: DHCPACK of 192.168.1.192
> from 192.168.1.1
> Feb 28 14:30:57 debian-laptop connmand[1038]: enp2s0f0 {add} address
> 192.168.1.192/24 label enp2s0f0 family 2
> Feb 28 14:30:57 debian-laptop avahi-daemon[1034]: Registering new
> address record for 192.168.1.192 on enp2s0f0.IPv4.
> Feb 28 14:30:57 debian-laptop dhclient[1003]: bound to 192.168.1.192
> -- renewal in 17866 seconds.

One might expect this to be where mv -f fails.

There seems to be a process, 1003, that succeeds in obtaining an
IP address of 192.168.1.192 on ethernet, and another, 2016, that
has set up the wireless interface, but presumably has no
connection to the DHCP server. These processes have been running
since soon after booting, perhaps within seconds.

The third process, 39759, is obviously much more recent, and is
trying to get an address for the interface enx8c…, but also the
wifi interface at the same time as PID 2016. Perhaps this
process was started when connecting or disconnecting the vpn, IDK.

In any case, when both 2016 (at 31:49) and 39759 (at 32:25) fail
to get leases, it looks as if avahi-autoipd kicks in, and 39759
starts sending to the link-local address.

All this is guesswork: I don't run ifupdown, dhclient or
avahi-autoipd, so my logs aren't comparable in many respects.
Also, the immutable resolv.conf might cause subsequent commands
that consult it to go awry.

Cheers,
David.

[Max Nikulin]

On 03/03/2023 10:08, Tim Woodall wrote:
> New to this thread, so might be totally off-piste but openvpn has hooks
> to run scripts like this:

...

> This is server side but the route-up/pre-down work client side too.
>
> Presumably you can do something here to renew dhcp leases or restore
> resolv.conf.

Perhaps the opposite. dhclient running for enp2s0f0 should detect that
VPN is active and to avoid overwriting DNS settings that direct requests
to tun0.

[Tim Woodall]

The hook can create and delete a file like rhis:
tim@dirac:/etc/dhcp (none)$ cat dhclient-enter-hooks.d/nodnsupdate
make_resolv_conf() {
:
}

[Max Nikulin]

I agree that VPN script may add and remove dhclient hook or may write
some file in /run that is read by dhclient hook. They should cooperate
in some way. In more versatile configuration domain resolution may be
per-interface. E.g. hosts from the corporate domain are resolved through
tun0, other sites through enp2s0f0.

[David Wright]

This is the job that packages like openresolv are designed
to do. BTW if you look up that package in apt's lists, note
that this is a case where you need man's section number, because
man 8 resolvconf without the 8 will give you a systemd page.

Cheers,
David.

[dave...@tuxfamily.org]

Hello

The VPN was obviously running at that time.

IF the VPN was not running the 28th february (almost allday, including
around 14:30), it wouldn't make sense to
- make /etc/resolv.conf immutable so dhlient doesn't overwrite it while
my home's resolver address
- complain about dhclient ignoring tun0, which obviously exists only
when the vpn is running
- searching for logs for the 28th february around 14:30

I never said those logs were soon after running. I'd love to start my
workday after 14:00/2 pm… but obviously it not the case.
These logs are from after dhcp leases ends and dhlicent tries to
overwrite resolv.conf.
Several hours after openconnect is executed (around 9:00 am).

I said when the system boots, before the VPN is up and ruuning, I can
see dhclient has only one (eth0/ens-whatever_its-name_is) as an argument
So I don't how dhclient determines what interfaces to use, and why it
ignores tun0 BUT still detects and try to use ALL other interfaces, even
when there down/not used

>
> It would make sense to start and stop the vnc from a terminal in which
> script (bsdutils) was running, preferably with -T to add timestamps to
> each command. You could then reconcile the logs with what you were
> doing.

I guess you mean vpnc, or vpn? not vnc? or am I misinterpreting?

vpnc_script is started by openconnect (vpn client for cisco, among other
things). OpenConnect is executed from terminal
OpenConnect has timestamp but there is no output from openconnect when
/etc/resolv is overwritten by dhclient. As OpenConnect doesn't know
about it when it happens

That why I used auditd and ausearch with timestamp, and reconciled logs
from auditd
showing a process failing (as expected) to overwrite /etc/resolv.conf
with logs from syslog showing dhclient trying to renew DHCP leases

Around 9:00 am, openconnect is executed manually from the terminal and
works as expected.
Right after the VPN is connected, I make resolv.conf file immutable and
tell auditd to monitor write or append actions to this file

Everything works until around 14:30, dhclient tries to overwrites
/etc/resolv and fails as expect.
Auditd logs that action. The VPN is still running. I ^C openconnect only
at the end of the day
(unless something breaks, like temporary network issues forcing me to
reconnect)

At that moment, things still works just because I made /etc/resolv.conf
But it's annoying to have to think about adding/removing the immutable
flag each time…

>
>> ------------
>> dave@debian-laptop:~$ systemctl status
>>
>> ├─if...@enp2s0f0.service
>> │ └─1093 /sbin/dhclient -4 -v -i -pf
>> /run/dhclient.enp2s0f0.pid -lf /var/lib/dhcp/dhclient.enp2s0f0.leases
>> -I -df /var/lib/dhcp/dhclient6.enp2s0f0.leases enp2s0f0
>>
>> ------------
>
> I don't know why ifupdown is running, as I thought you were
> controlling the network with connman.

That's the default debian behaviour.
A colleague with debian stable and LXQT (therefore connmann as well,
just like for LXDE, which I use)
also has ifup running as parent process of dhclient. ifupdown is
installed by default.

It is not what bothers me… making /etc/resolv.conf immutable is just a
temporary work around, but necessary until I have a working solution

No it wasn't, the vpn was connected hours before that. and disconnected
hours after that.
This is exactly my point, thus the topic name "Forcing dhclient to not
ignore tun0 interface when it's available"

vpn is up and running, tun0 is available and being used by almost
everything on the coputer and it is working
BUT dhclient sends dhcp requests throught all interfaces, even
unused/down ones, except tun0

Wireless interface is down, disabled in the software level (not physical
killswitch). I fail to see why
dhclient try to use it to send DHCP requests at all, while the interface
is down.

It blindly tries litteraly all interfaces except, interface tun0 and
tun0 IS available at that time

dhclient even tries the weird long hexadecimal name interface, the one
starting with enx8c.
I just learned (yesterday actually) from a colleague that the work's
issued laptop has a 4G modem.
I don't use it, there's no SIM card in it, and the interface is down.
enx8c being I namenclature I never seen before, on other laptops, I
never used it or seen it UP on my work's laptop and it has "NO CARRIER"
So my guess enx8c is the 4G modem

>
> In any case, when both 2016 (at 31:49) and 39759 (at 32:25) fail
> to get leases, it looks as if avahi-autoipd kicks in, and 39759
> starts sending to the link-local address.
>
> All this is guesswork: I don't run ifupdown, dhclient or
> avahi-autoipd, so my logs aren't comparable in many respects.
> Also, the immutable resolv.conf might cause subsequent commands
> that consult it to go awry.

I wouldn't make it immutable temprarily, if I wasn't forced to
Until I find a working solution, I have no choice when it comes to
making resolv.conf immutable
Sometimes dhclient overwrites several times in 20 minutes… or a few
secondes after I stop openclient,
and execute it again, so it rewrites proper /etc/resolv.conf… which then
doesn't last depending on timing…

>
> Cheers,
> David.

[Kamil Jońca]

David Wright <deb...@lionunicorn.co.uk> writes:

[...]

>
> This is the job that packages like openresolv are designed
> to do. BTW if you look up that package in apt's lists, note
> that this is a case where you need man's section number, because
> man 8 resolvconf without the 8 will give you a systemd page.

+1

I have configured resolvconf + some scripts in my (dhcp,openvpn,ipsec)
configurations
and they take care to properly preparing name resolution during
different situations.

KJ




--
http://wolnelektury.pl/wesprzyj/teraz/

[David Wright]

I'm writing from what I've gleaned from the logs. You're writing from
the viewpoint of running the machine. If you'd originally written some
of what's below, I wouldn't have had to. Why do I have to? Because
there's no point in my writing anything unless I give the assumptions
on which it's based, enabling you to correct any false assumptions.

> IF the VPN was not running the 28th february (almost allday, including
> around 14:30), it wouldn't make sense to
> - make /etc/resolv.conf immutable so dhlient doesn't overwrite it
> while my home's resolver address
> - complain about dhclient ignoring tun0, which obviously exists only
> when the vpn is running
> - searching for logs for the 28th february around 14:30
>
> I never said those logs were soon after running.

Nor me. I presumed that they weren't, and wrote that down in case
my presumption was incorrect.

> I'd love to start my
> workday after 14:00/2 pm… but obviously it not the case.
> These logs are from after dhcp leases ends and dhlicent tries to
> overwrite resolv.conf.
> Several hours after openconnect is executed (around 9:00 am).
>
> I said when the system boots, before the VPN is up and ruuning, I can
> see dhclient has only one (eth0/ens-whatever_its-name_is) as an
> argument
> So I don't how dhclient determines what interfaces to use, and why it
> ignores tun0 BUT still detects and try to use ALL other interfaces,
> even when there down/not used
>
> >
> > It would make sense to start and stop the vnc from a terminal in which
> > script (bsdutils) was running, preferably with -T to add timestamps to
> > each command. You could then reconcile the logs with what you were
> > doing.
>
> I guess you mean vpnc, or vpn? not vnc? or am I misinterpreting?

Yes, I used vpnc as a shorthand for starting your VPN session. I know
openconnect only as a package name, and I had no idea whether you
start it in a GUI (assuming X is running) or with some terminal command.
So again, I'm second-guessing pretty much what you already do.

Yes, this keyboard doesn't have a good touch, so I often have to add
missing letters while I read through what I've written.

> vpnc_script is started by openconnect (vpn client for cisco, among
> other things). OpenConnect is executed from terminal
> OpenConnect has timestamp but there is no output from openconnect when
> /etc/resolv is overwritten by dhclient. As OpenConnect doesn't know
> about it when it happens
>
> That why I used auditd and ausearch with timestamp, and reconciled
> logs from auditd
> showing a process failing (as expected) to overwrite /etc/resolv.conf
> with logs from syslog showing dhclient trying to renew DHCP leases
>
> Around 9:00 am, openconnect is executed manually from the terminal and
> works as expected.
> Right after the VPN is connected, I make resolv.conf file immutable
> and tell auditd to monitor write or append actions to this file
>
> Everything works until around 14:30, dhclient tries to overwrites
> /etc/resolv and fails as expect.
> Auditd logs that action. The VPN is still running. I ^C openconnect
> only at the end of the day
> (unless something breaks, like temporary network issues forcing me to
> reconnect)
>
> At that moment, things still works just because I made /etc/resolv.conf
> But it's annoying to have to think about adding/removing the immutable
> flag each time…

As you start your VPN in a terminal, it would be easy to script it.
Perhaps something like:

connect
(sleep 5; chattr)

where 5 is tuned to how much time before the connection settles.

chattr; disconnect

is obviously simpler.

> > > ------------
> > > dave@debian-laptop:~$ systemctl status
> > >
> > > ├─if...@enp2s0f0.service
> > > │ └─1093 /sbin/dhclient -4 -v -i -pf
> > > /run/dhclient.enp2s0f0.pid -lf /var/lib/dhcp/dhclient.enp2s0f0.leases
> > > -I -df /var/lib/dhcp/dhclient6.enp2s0f0.leases enp2s0f0
> > >
> > > ------------
> >
> > I don't know why ifupdown is running, as I thought you were
> > controlling the network with connman.
>
> That's the default debian behaviour.
> A colleague with debian stable and LXQT (therefore connmann as well,
> just like for LXDE, which I use)
> also has ifup running as parent process of dhclient. ifupdown is
> installed by default.

It might help to clean up your networking then. ConnMan should be able
to run wpasupplicant, and AFAIK can do its own DHCP.

I have an ancient laptop running systemd-networkd and wpasupplicant
for its ethernet and wifi. My other wifis use iwd. So I've removed
ifupdown, isc-dhcp-*, and avahi-autoipd from all my machines as
none of these is now required. All part of a cleanup following the
demise of wicd in bullseye.

So you wrote, 35 lines above. But at the top you wrote, "showing a

process failing (as expected) to overwrite /etc/resolv.conf with logs

from syslog showing dhclient trying to renew DHCP leases". So this
is an expected DHCP as the lease has expired. Aren't we interested
in your "popup" DHCPs that occur sometimes just minutes apart.

Well, that was a guess I got wrong. I wouldn't have had to try
guessing if you'd explained what you were doing in the post, rather
than leaving it until we've attempted to decode it, unravelling
all these interspersed DHCP runs.

For all I know, you could have been downing the VPN for coffee-,
lunch- and tea-time.

> This is exactly my point, thus the topic name "Forcing dhclient to not
> ignore tun0 interface when it's available"

I hadn't got to that yet. I was still looking at your "popup"
problem. But OK, let's look at that.

> vpn is up and running, tun0 is available and being used by almost
> everything on the coputer and it is working
> BUT dhclient sends dhcp requests throught all interfaces, even
> unused/down ones, except tun0
>
> Wireless interface is down, disabled in the software level (not
> physical killswitch). I fail to see why
> dhclient try to use it to send DHCP requests at all, while the
> interface is down.
>
> It blindly tries litteraly all interfaces except, interface tun0 and
> tun0 IS available at that time
>
> dhclient even tries the weird long hexadecimal name interface, the one
> starting with enx8c.
> I just learned (yesterday actually) from a colleague that the work's
> issued laptop has a 4G modem.
> I don't use it, there's no SIM card in it, and the interface is down.
> enx8c being I namenclature I never seen before, on other laptops, I
> never used it or seen it UP on my work's laptop and it has "NO
> CARRIER"
> So my guess enx8c is the 4G modem

Presumably one of the hardware enuerators could confirm that;
inxi, lshw and so on.

> > In any case, when both 2016 (at 31:49) and 39759 (at 32:25) fail
> > to get leases, it looks as if avahi-autoipd kicks in, and 39759
> > starts sending to the link-local address.
> >
> > All this is guesswork: I don't run ifupdown, dhclient or
> > avahi-autoipd, so my logs aren't comparable in many respects.
> > Also, the immutable resolv.conf might cause subsequent commands
> > that consult it to go awry.
>
> I wouldn't make it immutable temprarily, if I wasn't forced to
> Until I find a working solution, I have no choice when it comes to
> making resolv.conf immutable
> Sometimes dhclient overwrites several times in 20 minutes… or a few
> secondes after I stop openclient,
> and execute it again, so it rewrites proper /etc/resolv.conf… which
> then doesn't last depending on timing…

As I wrote a while back, I think you need to install a resolv.conf
manager like openresolv. (I'm thinking of trying to configure
systemd-resolved again, which I think I screwed up last time.)
The idea is that addresses on your 192.168.1.0 network are
resolved locally even while your VPN is up, but addresses outside
that are resolved by the "works" nameservers through the tunnel.

Cheers,
David.

[dave...@tuxfamily.org]

Hello

On 2023-03-03 06:22, Max Nikulin wrote:
> On 03/03/2023 10:08, Tim Woodall wrote:
>> New to this thread, so might be totally off-piste but openvpn has
>> hooks
>> to run scripts like this:
> ...
>> This is server side but the route-up/pre-down work client side too.

Since it's workplace's VPN, which I don't have access to, I can't do
anything which requires server-side access.
Plus, it's a Cisco VPN. I don't anythig aout cisco stuff. I'm more
familiar with openVPN

>>
>> Presumably you can do something here to renew dhcp leases or restore
>> resolv.conf.
>
> Perhaps the opposite. dhclient running for enp2s0f0 should detect that
> VPN is active and to avoid overwriting DNS settings that direct
> requests to tun0.

Yes, indeed. I want dhclient to NOT overwrite /etc/resolv.conf when VPN
is active. OR to use tun05 when it tries to renew the lease

One person at work suggested to use resolvectl/resolvconf but after
looking at it, I noticed it requires using sytemd-resolved, which
I don't use.
As an alternative, there is openresolv, which seems work without
resolved. But I failed to find any document on how to useit with
openconnect.
The official website config page only gives parameters for some
well-known local resolvers, including unbound.
If anyone has a good documention on how to configure openresolv
correctly to use it with openconnect.

Thing is : years ago I used to use OpenVPN on debian on another
computer, the DHCP client was also dhclient
but I didn't to do any extra configuration, it just worked… The only
differences was an older debian version,
as the stable batk them was like Debian 7 or 8, and I was using wicd
instead. So the network stuff probably changed since then

Therefore I have no damn idea on how to configure stuff like openresolv.

[dave...@tuxfamily.org]

I agree about cooperation. BUT It would be much easier if everything is
resolved through workplace's resolver whenever openconnect is active.

If I have to specify all the domains I want to be resolved using tun0
interface,
It would be annoying to configure and error-prone. Because there
multiple "private"
different domains, in additions to private subdomains, of
publicly-accessible "parent" domains.

Not to mention redirections for SSO/authentication (depending on the
tool/server/where's it hosted, it not the same LDAP server),
or tools which multiple servers but without load-balancer/unique URL for
access. You just arrive on one of the servers.
Some kind of load balancing but different FQDN for each server of the
pool.

And some tools have literally multiples redirections before the home
page, across different domains and subdomains

[David Wright]

On Mon 06 Mar 2023 at 13:17:23 (+0100), dave...@tuxfamily.org wrote:
> On 2023-03-03 06:22, Max Nikulin wrote:
> > On 03/03/2023 10:08, Tim Woodall wrote:
> > > New to this thread, so might be totally off-piste but openvpn
> > > has hooks
> > > to run scripts like this:
> > ...
> > > This is server side but the route-up/pre-down work client side too.
>
> Since it's workplace's VPN, which I don't have access to, I can't do
> anything which requires server-side access.
> Plus, it's a Cisco VPN. I don't anythig aout cisco stuff. I'm more
> familiar with openVPN
>
> > >
> > > Presumably you can do something here to renew dhcp leases or restore
> > > resolv.conf.
> >
> > Perhaps the opposite. dhclient running for enp2s0f0 should detect that
> > VPN is active and to avoid overwriting DNS settings that direct
> > requests to tun0.
>
> Yes, indeed. I want dhclient to NOT overwrite /etc/resolv.conf when
> VPN is active. OR to use tun05 when it tries to renew the lease
>
> One person at work suggested to use resolvectl/resolvconf but after
> looking at it, I noticed it requires using sytemd-resolved, which
> I don't use.

Package: resolvconf
Depends: lsb-base (>= 4.1+Debian3), debconf (>= 0.5) | debconf-2.0

AIUI systemd-resolved is a replacement for openresolv, and it's
systemd-networkd that can work alongside openresolv.

> As an alternative, there is openresolv, which seems work without
> resolved. But I failed to find any document on how to useit with
> openconnect.

Yes, no dependencies.

Openconnect will supply openresolv with the information it needs
when the vpnc-script that we discussed earlier runs. It's at the
function "modify_resolvconf_manager", around line 690.

> The official website config page only gives parameters for some
> well-known local resolvers, including unbound.

It also covers Bind, named (a part of bind), and dnsmasq
(mentioned in that script). All these are in Debian.

> If anyone has a good documention on how to configure openresolv
> correctly to use it with openconnect.

I see that the openresolv wiki at Arch has a section on openconnect.
Obviously you may need to "bend" their pages when consulting them
for Debian.

> Thing is : years ago I used to use OpenVPN on debian on another
> computer, the DHCP client was also dhclient
> but I didn't to do any extra configuration, it just worked… The only
> differences was an older debian version,
> as the stable batk them was like Debian 7 or 8, and I was using wicd
> instead. So the network stuff probably changed since then
>
> Therefore I have no damn idea on how to configure stuff like openresolv.

Cheers,
David.

[David Wright]

On Mon 06 Mar 2023 at 13:34:52 (+0100), dave...@tuxfamily.org wrote:
> On 2023-03-03 16:00, Max Nikulin wrote:
> > On 03/03/2023 13:29, Tim Woodall wrote:
> > > On Fri, 3 Mar 2023, Max Nikulin wrote:
> > > >
> > > > dhclient running for enp2s0f0 should detect that VPN is
> > > > active and to avoid overwriting DNS settings that direct
> > > > requests to tun0.
> > > >
> > > The hook can create and delete a file like rhis:
> > > tim@dirac:/etc/dhcp (none)$ cat dhclient-enter-hooks.d/nodnsupdate
> > > make_resolv_conf() {
> > >         :
> > > }
> >
> > I agree that VPN script may add and remove dhclient hook or may write
> > some file in /run that is read by dhclient hook. They should cooperate
> > in some way. In more versatile configuration domain resolution may be
> > per-interface. E.g. hosts from the corporate domain are resolved
> > through tun0, other sites through enp2s0f0.
>
> I agree about cooperation. BUT It would be much easier if everything
> is resolved through workplace's resolver whenever openconnect is
> active.

I don't see how your workplace's resolver can resolve addresses on
your own LAN.

> If I have to specify all the domains I want to be resolved using tun0
> interface,
> It would be annoying to configure and error-prone. Because there
> multiple "private"
> different domains, in additions to private subdomains, of
> publicly-accessible "parent" domains.

I was under the impression that the fifty-odd functions in the
vpnc-script we discussed earlier had a role in setting your
resolvers and routing for the tunnel with the environment parameters.

> Not to mention redirections for SSO/authentication (depending on the
> tool/server/where's it hosted, it not the same LDAP server),
> or tools which multiple servers but without load-balancer/unique URL
> for access. You just arrive on one of the servers.
> Some kind of load balancing but different FQDN for each server of the
> pool.
>
> And some tools have literally multiples redirections before the home
> page, across different domains and subdomains

I'm guessing that you're talking here about stuff at the other
end of the tunnel? Presumably they have sysadmins setting that up.

Cheers,
David.

[Max Nikulin]

On 06/03/2023 19:17, davenull wrote:
> On 2023-03-03 06:22, Max Nikulin wrote:
>>
>> Perhaps the opposite. dhclient running for enp2s0f0 should detect that
>> VPN is active and to avoid overwriting DNS settings that direct
>> requests to tun0.
>
> Yes, indeed. I want dhclient to NOT overwrite /etc/resolv.conf when VPN
> is active. OR to use tun05 when it tries to renew the lease

...

> If anyone has a good documention on how to configure openresolv
> correctly to use it with openconnect.

People suggested openvpn scripts and dhclient hooks in this thread. It
should be enough to write a couple of scripts that conditionally update
resolv.conf. I am not sure that it is possible to provide configuration
that would work out of the box. If you are seeking a ready to use
recipe, perhaps you should ask openvpn community.

I used network-manager-openconnect-gnome for some time and it was enough
to fill some fields in a GUI form for minimal working configuration.

[dave...@tuxfamily.org]

Hello

On 2023-03-07 05:01, David Wright wrote:
> On Mon 06 Mar 2023 at 13:17:23 (+0100), dave...@tuxfamily.org wrote:
>> On 2023-03-03 06:22, Max Nikulin wrote:
>> > On 03/03/2023 10:08, Tim Woodall wrote:
>> > > New to this thread, so might be totally off-piste but openvpn
>> > > has hooks
>> > > to run scripts like this:
>> > ...
>> > > This is server side but the route-up/pre-down work client side too.
>>
>> Since it's workplace's VPN, which I don't have access to, I can't do
>> anything which requires server-side access.

>> Plus, it's a Cisco VPN. I don't anything aout cisco stuff. I'm more

Yes. but I don't need any of these, or other local (at in localhost)
resolver.
So that official page isn't helpful in my case.

>
>> If anyone has a good documention on how to configure openresolv
>> correctly to use it with openconnect.
>
> I see that the openresolv wiki at Arch has a section on openconnect.
> Obviously you may need to "bend" their pages when consulting them
> for Debian.
>

Will check that out. I just realized "resolvconf" command in the script
given
in openconnect's Arch wiki page is not necessarily resolvclt and might
as well
refer to openconnect. When I searched for keybould with both openresolv
and openconnect,
all I've found was a (still open) 3 years issue on openconnect't gitlab.

I'll give it a try and see what's to adjust for debian, once workload
allows that.

[dave...@tuxfamily.org]

On 2023-03-07 05:01, David Wright wrote:

> On Mon 06 Mar 2023 at 13:34:52 (+0100), dave...@tuxfamily.org wrote:
>> On 2023-03-03 16:00, Max Nikulin wrote:
>> > On 03/03/2023 13:29, Tim Woodall wrote:
>> > > On Fri, 3 Mar 2023, Max Nikulin wrote:
>> > > >
>> > > > dhclient running for enp2s0f0 should detect that VPN is
>> > > > active and to avoid overwriting DNS settings that direct
>> > > > requests to tun0.
>> > > >
>> > > The hook can create and delete a file like rhis:
>> > > tim@dirac:/etc/dhcp (none)$ cat dhclient-enter-hooks.d/nodnsupdate
>> > > make_resolv_conf() {
>> > > :
>> > > }
>> >
>> > I agree that VPN script may add and remove dhclient hook or may write
>> > some file in /run that is read by dhclient hook. They should cooperate
>> > in some way. In more versatile configuration domain resolution may be
>> > per-interface. E.g. hosts from the corporate domain are resolved
>> > through tun0, other sites through enp2s0f0.
>>
>> I agree about cooperation. BUT It would be much easier if everything
>> is resolved through workplace's resolver whenever openconnect is
>> active.
>
> I don't see how your workplace's resolver can resolve addresses on
> your own LAN.

Well, I meant resolving anything on the Internet + work's private
network. Not on my LAN

It obviously can't resolve hostnames on my LAN, but for the time being,
there's actually nothing on LAN I'd want to resolve.

I have a network printer which I use once in a while, but it configured
in CUPS by IP, not by (its 3 km long, weird,) hostname.
And I don't use it often enough (so it's mostly off to save electricity)
to spend time
to create/test (then script) a route specifically for anything
192.168.1.0/192.0168.0.0 while the VPN is on.
So for the printer is inaccessible either way when the VPN is on

The printer being only thing on my which I might need to resolve… maybe
one day.
But it has a weird hostname harder to remember than it's IP (not sure if
I can change the hostname for something human-readable…,
still learning about its capabilities and menus),
And I don't use it daily. So I'm OK with not being able to print with
VPN connected

Granted, I might want to exclude 192.168.0|1.0 from requests sert to
workplace resolver. But I certainly
don't to think about each (sub)domain and whether it's should/can be
resolved by worksplace or
not

[dave...@tuxfamily.org]

If it was for personal need, I wouldn't mind spending time with trial
and error… but it's not.

That hook stuff might be enough for someone who either use a similar
environnent/tools as the script's
OR known well enough both openconnect/connmann/openresolv, as well as
openVPN… So they can easily adapt such hooks to different tolls

I use neither OpenVPN¹ for work nor network-manager. So hooks need to be
adapted BUT my knowledge of openconnect is limited, let alone openresolv
(0 knowledge)
So having some documentation "beginner-friendly" would actually make a
big difference to help me achieving that in a reasonable amount of time

Not having a documentation means tinkering, and trial and error and
spending (too much) time on it.
Sure it might work, but I requires more time and energy I can't afford.

During remote-work, extra hours are simply ignored. So I either thinker
to make things work with near 0 knowledge of these tools, or do my
actual.

And I'm not planning spending my free time debugging work's related
stuff (anymore, did that mistake too often).
Workplace idiotic policy about both extra-hours during remote work AND
on-site extra-hours if one leaves work the office
after 6:30 pm (clocking terminal configured to ignore working time after
that) sc***ed me more than once during incidents.

So I'm clearly being lazy this time. I'd rather find a solution which is
relatively "easy and fast" to implement, than work for free

1. Because, according to workspace staff who "choose" (a.k.a listened to
marketing people) cisco crap… cisco blackbox with it's binary spyware
(CSD idiocy) is "more secure"…

[David Wright]

On Tue 07 Mar 2023 at 17:53:10 (+0100), dave...@tuxfamily.org wrote:
>
> So I'm clearly being lazy this time. I'd rather find a solution which
> is relatively "easy and fast" to implement, than work for free

chattr -i ?

Scripted of course.

Cheers,
David.

[David Wright]

On Tue 07 Mar 2023 at 17:17:24 (+0100), dave...@tuxfamily.org wrote:
> On 2023-03-07 05:01, David Wright wrote:
> > On Mon 06 Mar 2023 at 13:34:52 (+0100), dave...@tuxfamily.org wrote:
> > > On 2023-03-03 16:00, Max Nikulin wrote:
> > > > On 03/03/2023 13:29, Tim Woodall wrote:
> > > > > On Fri, 3 Mar 2023, Max Nikulin wrote:
> > > > > >
> > > > > > dhclient running for enp2s0f0 should detect that VPN is
> > > > > > active and to avoid overwriting DNS settings that direct
> > > > > > requests to tun0.
> > > > > >
> > > > > The hook can create and delete a file like rhis:
> > > > > tim@dirac:/etc/dhcp (none)$ cat dhclient-enter-hooks.d/nodnsupdate
> > > > > make_resolv_conf() {
> > > > > :
> > > > > }
> > > >
> > > > I agree that VPN script may add and remove dhclient hook or may write
> > > > some file in /run that is read by dhclient hook. They should cooperate
> > > > in some way. In more versatile configuration domain resolution may be
> > > > per-interface. E.g. hosts from the corporate domain are resolved
> > > > through tun0, other sites through enp2s0f0.
> > >
> > > I agree about cooperation. BUT It would be much easier if everything
> > > is resolved through workplace's resolver whenever openconnect is
> > > active.
> >
> > I don't see how your workplace's resolver can resolve addresses on
> > your own LAN.
>
> Well, I meant resolving anything on the Internet + work's private
> network. Not on my LAN

Well, I used the LAN as an example because I know that your workplace
can't resolve it. I'm not party to what your workplace /can/ resolve.
So that's the example you got.

> Granted, I might want to exclude 192.168.0|1.0 from requests sert to
> workplace resolver. But I certainly
> don't to think about each (sub)domain and whether it's should/can be
> resolved by worksplace or
> not

You shouldn't have to. When you connect to your workplace,
it tells openresolv what it can resolve, and openresolv
retains what it knew about resolving on /your/ network
before you connected, rather than letting it be destroyed
by overwriting it. It can also reverse this process upon
disconnection. That's what this extra software is for.

Cheers,
David.

[dave...@tuxfamily.org]

Yeah,, I'm using chattr +/-i until I have time time to test openresolv

> Cheers,
> David.