Re: Forcing dhclient to not ignore tun0 interface when it's available

[davenull]

On 2023-03-10 01:51, David Wright wrote:

On Tue 07 Mar 2023 at 17:53:10 (+0100), daven...@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.



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


Cheers,
David.

Re: Forcing dhclient to not ignore tun0 interface when it's available

[David Wright]

On Tue 07 Mar 2023 at 17:53:10 (+0100), daven...@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.

Re: Forcing dhclient to not ignore tun0 interface when it's available

[David Wright]

On Tue 07 Mar 2023 at 17:17:24 (+0100), daven...@tuxfamily.org wrote:
> On 2023-03-07 05:01, David Wright wrote:
> > On Mon 06 Mar 2023 at 13:34:52 (+0100), daven...@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.

Re: Forcing dhclient to not ignore tun0 interface when it's available

[davenull]

On 2023-03-07 16:20, Max Nikulin wrote:

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.


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

Re: Forcing dhclient to not ignore tun0 interface when it's available

[davenull]

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

On Mon 06 Mar 2023 at 13:34:52 (+0100), daven...@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




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.

Re: Forcing dhclient to not ignore tun0 interface when it's available

[davenull]

Hello

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

On Mon 06 Mar 2023 at 13:17:23 (+0100), daven...@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
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.


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.



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.

Re: Forcing dhclient to not ignore tun0 interface when it's available

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

Re: Forcing dhclient to not ignore tun0 interface when it's available

[David Wright]

On Mon 06 Mar 2023 at 13:34:52 (+0100), daven...@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.

Re: Forcing dhclient to not ignore tun0 interface when it's available

[David Wright]

On Mon 06 Mar 2023 at 13:17:23 (+0100), daven...@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.

Re: Forcing dhclient to not ignore tun0 interface when it's available

[davenull]

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.


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

Re: Forcing dhclient to not ignore tun0 interface when it's available

[davenull]

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.

Re: Forcing dhclient to not ignore tun0 interface when it's available

[David Wright]

On Fri 03 Mar 2023 at 17:03:49 (+), daven...@tuxfamily.org wrote:
> On 2023-03-03 05:21, David Wright wrote:
> > On Thu 02 Mar 2023 at 11:44:17 (+0100), daven...@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.
> 
> The VPN was obviously running at that time.

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 expe

Re: Forcing dhclient to not ignore tun0 interface when it's available

[Kamil Jońca]

David Wright  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/

Re: Forcing dhclient to not ignore tun0 interface when it's available

[davenull]

Hello

On 2023-03-03 05:21, David Wright wrote:

On Thu 02 Mar 2023 at 11:44:17 (+0100), daven...@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.


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

 ├─ifup@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.




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

Re: Forcing dhclient to not ignore tun0 interface when it's available

[David Wright]

On Fri 03 Mar 2023 at 22:00:37 (+0700), 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.

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.

Re: Forcing dhclient to not ignore tun0 interface when it's available

[Max Nikulin]

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.

Re: Forcing dhclient to not ignore tun0 interface when it's available

[Tim Woodall]

On Fri, 3 Mar 2023, 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.

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.



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

Re: Forcing dhclient to not ignore tun0 interface when it's available

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

Re: Forcing dhclient to not ignore tun0 interface when it's available

[David Wright]

On Thu 02 Mar 2023 at 11:44:17 (+0100), daven...@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
> 
>  ├─ifup@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.

> 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=0xfa4d
> 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

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.

Re: Forcing dhclient to not ignore tun0 interface when it's available

[Tim Woodall]

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


Hello

On 2023-02-24 10:19, daven...@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

Forcing dhclient to not ignore tun0 interface when it's available

[davenull]

Hello

On 2023-02-24 10:19, daven...@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

 ├─ifup@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=0xfa4d 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

Re: reject dhclient offer from wrong subnet

[Reco]

Hi.

On Wed, Dec 15, 2021 at 04:37:19PM +0100, Tuxo wrote:
> Can I configure dhclient on my router to discard lease offers from a certain 
> subnet? I could also try to match the lease time, the 192.168.100/24 lease 
> time
> is only several seconds (!!) short, the real one will be 4 hours or more and 
> come with a valid WAN subnet mask.

Try adding "reject 192.168.100/24;" into your router's dhclient.conf.

Also, dhclient.conf(5).

Reco

reject dhclient offer from wrong subnet

[Tuxo]

Hi list

My router and my docsys modem power on at the same time. the modem is 
handing out dhcp offers of 192.168.100/24 . I assume they are meant for 
internal set up purposes and dhclient on my router should not catch or 
respond to them. Only the final offer after modem bootup has completed 
does contain the WAN subnet and a lease time of 4 hours.


Can I configure dhclient on my router to discard lease offers from a 
certain subnet? I could also try to match the lease time, the 
192.168.100/24 lease time is only several seconds (!!) short, the real 
one will be 4 hours or more and come with a valid WAN subnet mask.


I never had this problem before, so I don't know how to change 
dhclient's behaviour to a bogus lease offer.


Maybe iptables could assist and block multicast traffic from/to the 
wrong subnet? I'm not sure I would still get the actual WAN lease then.

Re: Re: Debian 9, dhclient does not update gateway

[Tapio Lehtonen]

Started behaving on its own. I installed gateway host on monday, on
thursday the gateway was correct on client. I did not find any mention of
the old gateway address, but maybe it had gone away by the time I checked.
This may be because the new gateway host was Debian desktop, I just removed
the desktop package, and something network configuration related lingered
in some cache for three days.

Thanks for help.

Re: Debian 9, dhclient does not update gateway

[Anssi Saari]

Tapio Lehtonen  writes:

> This is tail from /var/lib/dhcp/dhclient.leases
> lease {
>   interface "eth0";
>   fixed-address 192.168.250.41;
>   option subnet-mask 255.255.255.0;
>   option routers 192.168.250.6;
>   option dhcp-lease-time 3600;
>   option dhcp-message-type 5;
>   option domain-name-servers 192.168.250.2,192.168.250.10;
>   option dhcp-server-identifier 192.168.250.2;
>   option domain-name "office.mydomain.fi";
>   renew 2 2021/01/05 14:26:38;
>   rebind 2 2021/01/05 14:52:52;
>   expire 2 2021/01/05 15:00:22;
> }

Could it be there are other leases in that file which are still valid?
Or other files? For example, my Debian 9 box has these files:

-rw-r--r-- 1 root root 1046 Jan  7 09:44 /var/lib/dhcp/dhclient.eth0.leases
-rw-r--r-- 1 root root  525 Feb 10  2013 /var/lib/dhcp/dhclient.eth1.leases
-rw-r--r-- 1 root root0 Aug 23  2018 /var/lib/dhcp/dhclient.leases

So for me the valid lease is actually in
/var/lib/dhcp/dhclient.eth0.leases and dhclient.leases is empty and
dhclient.eth1.leases is a blast from the past.

I'm not using NetworkManager though. NetworkManager might have its own
idea about gateway address.

Re: Debian 9, dhclient does not update gateway

[Andrei POPESCU]

On Mi, 06 ian 21, 15:41:27, Tapio Lehtonen wrote:
> Old gateway host broke down, so I made a new one. One host now does get
> from DHCP server the new gateway IP -address, but continues to use the old.
> I can fix it temporarily doing
> 
> dhclient -r ; dhclient
> 
> but after boot it again uses the old gateway address. Another host also
> running Debian 9 behaves correctly.

[...]
 
> How can I get that problem host to behave?

Could it be you have the old gateway address hardcoded in some 
configuration file? Grepping /etc for the old gateway IP might help.

Otherwise it could be some local cache, not necessarily of dhclient.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Debian 9, dhclient does not update gateway

[Tapio Lehtonen]

Old gateway host broke down, so I made a new one. One host now does get
from DHCP server the new gateway IP -address, but continues to use the old.
I can fix it temporarily doing

dhclient -r ; dhclient

but after boot it again uses the old gateway address. Another host also
running Debian 9 behaves correctly.

root@viima:/etc/dhcp# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.13 (stretch)
Release: 9.13
Codename: stretch

This is tail from /var/lib/dhcp/dhclient.leases
lease {
  interface "eth0";
  fixed-address 192.168.250.41;
  option subnet-mask 255.255.255.0;
  option routers 192.168.250.6;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.250.2,192.168.250.10;
  option dhcp-server-identifier 192.168.250.2;
  option domain-name "office.mydomain.fi";
  renew 2 2021/01/05 14:26:38;
  rebind 2 2021/01/05 14:52:52;
  expire 2 2021/01/05 15:00:22;
}
root@viima:/etc/dhcp# ip r
default via 192.168.250.5 dev eth0 proto static metric 100
192.168.250.0/24 dev eth0 proto kernel scope link src 192.168.250.41 metric
100
root@viima:/etc/dhcp#

root@viima:/etc/dhcp# systemctl status NetworkManager
● NetworkManager.service - Network Manager
   Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled;
vendor preset: enabled)
   Active: active (running) since Wed 2021-01-06 15:12:54 EET; 22min ago
 Docs: man:NetworkManager(8)
 Main PID: 549 (NetworkManager)
Tasks: 4 (limit: 4915)
   CGroup: /system.slice/NetworkManager.service
   ├─549 /usr/sbin/NetworkManager --no-daemon
   └─688 /sbin/dhclient -d -q -sf
/usr/lib/NetworkManager/nm-dhcp-helper -pf /var/run/dhclient-eth0.pid -lf
/var/lib/NetworkManager/

tammi 06 15:13:00 viima NetworkManager[549]:   [1609938780.1464]
dhcp4 (eth0): state changed unknown -> bound
tammi 06 15:13:00 viima dhclient[688]: bound to 192.168.250.41 -- renewal
in 1557 seconds.
tammi 06 15:13:00 viima NetworkManager[549]:   [1609938780.9486]
device (eth0): state change: ip-config -> ip-check (reason 'none') [7
tammi 06 15:13:00 viima NetworkManager[549]:   [1609938780.9497]
device (eth0): state change: ip-check -> secondaries (reason 'none')
tammi 06 15:13:00 viima NetworkManager[549]:   [1609938780.9500]
device (eth0): state change: secondaries -> activated (reason 'none')
tammi 06 15:13:00 viima NetworkManager[549]:   [1609938780.9502]
manager: NetworkManager state is now CONNECTED_LOCAL
tammi 06 15:13:01 viima NetworkManager[549]:   [1609938781.1269]
manager: NetworkManager state is now CONNECTED_GLOBAL
tammi 06 15:13:01 viima NetworkManager[549]:   [1609938781.1270]
policy: set 'Wired connection 1' (eth0) as default for IPv4 routing a
tammi 06 15:13:01 viima NetworkManager[549]:   [1609938781.1290]
device (eth0): Activation: successful, device activated.
tammi 06 15:13:05 viima NetworkManager[549]:   [1609938785.0519]
manager: startup complete

How can I get that problem host to behave?

Re: How to make dhclient reread its config? (Debian 10)

[Victor Sudakov]

Greg Wooledge wrote:
> On Wed, Aug 26, 2020 at 10:56:30AM +0700, Victor Sudakov wrote:
> > I've made some changes to /etc/dhcp/dhclient.conf, now I need to make
> > dhclient reread it (and apply the changes to /etc/resolv.conf).
> 
> There is nothing you can put in dhclient.conf that will successfully
> prevent dhclient from fucking up your resolv.conf file in the general
> case.  

Well, I don't quite agree with you. The append, prepend and supersede
options can be quite useful.

> (You might be lucky enough that it works on *one* network, but
> even then, why take the chance?)
> 
> Please see <https://wiki.debian.org/resolv.conf> for your options.

Yes, my case is mentioned there in the "Modifying /etc/dhcp/dhclient.conf" 
paragraph.
Sadly, this article does not mention how to restart dhclient gracefully.

> 
> As far as "re-reading" goes, what you want to do is bring the interface
> down and back up.
> 
> ifdown yourifname
> ifup yourifname

I've found out that running `systemctl restart networking` is sufficient,
simple and safe. I've modified 3 remove hosts already without issues.

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/


signature.asc
Description: PGP signature

Re: How to make dhclient reread its config? (Debian 10)

[Greg Wooledge]

On Wed, Aug 26, 2020 at 10:56:30AM +0700, Victor Sudakov wrote:
> I've made some changes to /etc/dhcp/dhclient.conf, now I need to make
> dhclient reread it (and apply the changes to /etc/resolv.conf).

There is nothing you can put in dhclient.conf that will successfully
prevent dhclient from fucking up your resolv.conf file in the general
case.  (You might be lucky enough that it works on *one* network, but
even then, why take the chance?)

Please see <https://wiki.debian.org/resolv.conf> for your options.

As far as "re-reading" goes, what you want to do is bring the interface
down and back up.

ifdown yourifname
ifup yourifname

Obviously you can't do that in two steps if the machine is remote.  If
it's a remote machine, you'll need to do something clever-ish, like

ifdown yourifname; sleep 2; ifup yourifname

And *do not* make any mistakes.  (Doing it inside screen or tmux would
also be wise, just in case you lose the ssh connection during those
few seconds.)

Another alternative would be simply to reboot.

Re: How to make dhclient reread its config? (Debian 10)

[Victor Sudakov]

Reco wrote:
> 
> On Wed, Aug 26, 2020 at 10:56:30AM +0700, Victor Sudakov wrote:
> > There seems to be no dhclient service in systemd, and I don't find
> > any info about signalling dhclient with "kill -HUP" etc.
> 
> There is no need for "dhclient" service in systemd, as there's
> "networking" service for that. Restarting the latter is probably a bad
> idea in your case.

Not that bad, and actually thank you for this idea. I've just tried 
`systemctl restart networking` on a host I have emergency console access
to, and it went well: the host became inaccessible for 4-5 seconds and
then got back online, and even TCP connections (including my ssh
session) were not dropped.

> 
> 
> > "dhclient -x" or "dhclient -r" bring the network down (I've actually
> > confirmed that on a test host), and I loathe to risk it on a remote box.
> 
> As they should. Both "-x" and "-r" run dhclient scripts before dhclient
> exists, and this involves deconfiguring an appropriate network
> interface.
> 
> 
> > A reboot seems too radical.
> > 
> > Any ideas please?
> 
> Try this (note to the certain list readers - it's dangerous, do not try
> it at home unless you have a console access):
> 
> # ip -o a l dev eth0
> 2: eth0    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic eth0...
> ...
> # pgrep -fa dhc
> 355 /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid ...
> # pkill -9 -f dhclient
> # ip -o a l dev eth0 # note that the IPs stay
> 2: eth0    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic eth0...
> ...
> # ifup --force eth0
> Internet Systems Consortium DHCP Client 4.4.1 ...
> 
> Basically, by sending SIGKILL to dhclient you leave your current
> interface configuration as is, and by running dhclient again (via ifup
> in this case) you apply your dhclient.conf changes.

Thanks, Reco, if ever `systemctl restart networking` fails me, I'll do
this manual thing.

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/


signature.asc
Description: PGP signature

Re: How to make dhclient reread its config? (Debian 10)

[Reco]

Hi.

On Wed, Aug 26, 2020 at 10:56:30AM +0700, Victor Sudakov wrote:
> There seems to be no dhclient service in systemd, and I don't find
> any info about signalling dhclient with "kill -HUP" etc.

There is no need for "dhclient" service in systemd, as there's
"networking" service for that. Restarting the latter is probably a bad
idea in your case.


> "dhclient -x" or "dhclient -r" bring the network down (I've actually
> confirmed that on a test host), and I loathe to risk it on a remote box.

As they should. Both "-x" and "-r" run dhclient scripts before dhclient
exists, and this involves deconfiguring an appropriate network
interface.


> A reboot seems too radical.
> 
> Any ideas please?

Try this (note to the certain list readers - it's dangerous, do not try
it at home unless you have a console access):

# ip -o a l dev eth0
2: eth0inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic eth0...
...
# pgrep -fa dhc
355 /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid ...
# pkill -9 -f dhclient
# ip -o a l dev eth0 # note that the IPs stay
2: eth0inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic eth0...
...
# ifup --force eth0
Internet Systems Consortium DHCP Client 4.4.1 ...

Basically, by sending SIGKILL to dhclient you leave your current
interface configuration as is, and by running dhclient again (via ifup
in this case) you apply your dhclient.conf changes.

Reco

Re: How to make dhclient reread its config? (Debian 10)

[Victor Sudakov]

Claudio Kuenzler wrote:
> On Wed, Aug 26, 2020 at 5:56 AM Victor Sudakov  wrote:
> 
> > Dear Colleagues,
> >
> > I've made some changes to /etc/dhcp/dhclient.conf, now I need to make
> > dhclient reread it (and apply the changes to /etc/resolv.conf).
> >
> > There seems to be no dhclient service in systemd, and I don't find
> > any info about signalling dhclient with "kill -HUP" etc.
> >
> > "dhclient -x" or "dhclient -r" bring the network down (I've actually
> > confirmed that on a test host), and I loathe to risk it on a remote box.
> > A reboot seems too radical.
> >
> > Any ideas please?
> >
> 
> A simple "dhclient" as root (or "sudo dhclient") without parameters should
> be enough.
> In syslog you should be able to see something like this afterwards:

Not actually. If you look at `ps` output after "sudo dhclient", you'll
notice that you now have 2 dhclients running in the background, the old
one is still there and the new one has been added. And they both will
race to rewrite your /etc/resolv.conf.

Try it out.

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/


signature.asc
Description: PGP signature

Re: How to make dhclient reread its config? (Debian 10)

[Claudio Kuenzler]

On Wed, Aug 26, 2020 at 5:56 AM Victor Sudakov  wrote:

> Dear Colleagues,
>
> I've made some changes to /etc/dhcp/dhclient.conf, now I need to make
> dhclient reread it (and apply the changes to /etc/resolv.conf).
>
> There seems to be no dhclient service in systemd, and I don't find
> any info about signalling dhclient with "kill -HUP" etc.
>
> "dhclient -x" or "dhclient -r" bring the network down (I've actually
> confirmed that on a test host), and I loathe to risk it on a remote box.
> A reboot seems too radical.
>
> Any ideas please?
>

A simple "dhclient" as root (or "sudo dhclient") without parameters should
be enough.
In syslog you should be able to see something like this afterwards:

Aug 26 06:10:41 mailtest dhclient[899]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 7
Aug 26 06:10:41 mailtest dhclient[899]: DHCPOFFER of 192.168.15.23 from
192.168.15.1
Aug 26 06:10:41 mailtest dhclient[899]: DHCPREQUEST for 192.168.15.23 on
eth0 to 255.255.255.255 port 67
Aug 26 06:10:41 mailtest dhclient[899]: DHCPACK of 192.168.15.23 from
192.168.15.1
Aug 26 06:10:41 mailtest dhclient[899]: bound to 192.168.15.23 -- renewal
in 73845 seconds.

How to make dhclient reread its config? (Debian 10)

[Victor Sudakov]

Dear Colleagues,

I've made some changes to /etc/dhcp/dhclient.conf, now I need to make
dhclient reread it (and apply the changes to /etc/resolv.conf).

There seems to be no dhclient service in systemd, and I don't find
any info about signalling dhclient with "kill -HUP" etc.

"dhclient -x" or "dhclient -r" bring the network down (I've actually
confirmed that on a test host), and I loathe to risk it on a remote box.
A reboot seems too radical.

Any ideas please?

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/


signature.asc
Description: PGP signature

Re: dhclient deixa de funcionar

[Alex Muntada]

Hola Narcis,

> Estic en el cert que dhclient ha de ser un procés viu tota
> l'estona? Jo el què em trobo és que dhclient mor, i suposo
> que per això no renova les dades IP.

Jo tinc un dimoni de dhclient corrent, fill del NetworkManager.
Has mirat si hi ha cap rastre d'error del dhclient al fitxer
/var/log/daemon.log? En el meu cas és on es veu que es renoven
les peticions del DHCP.

> Per a diagnosticar-ho bé hauria de comparar 2 ordinadors: Un
> amb Debian 7 (sense estar governat per Systemd) i l'altre amb
> Debian 10, i ambdós sense NetworkManager ni altres
> reemplaçaments.

Antigament s'indicava dhcp al fitxer interfaces i ja n'hi havia
prou perquè s'iniciés el dhclient corresponent.

> No entenc el què produeix això, reemplaçant dhcp-server-
> identifier :
> interface "ethX" {
>supersede dhcp-server-identifier 255.255.255.255;
> }

El comentari següent al que vaig enllaçar ho explica una mica
(https://serverfault.com/a/391865): alguns proveïdors de DHCP
no atenen les peticions dirigides directament (unicast) a l'IP
del servidor DHCP, solament a les peticions de les quals es fa
difusió a la xarxa local (broadcast).

Si ho entenc correctament, el supersede dhcp-server-identifier
li diu al dhclient que enlloc d'emprar la IP que ha obtingut
prèviament per al servidor DHCP segueixi enviant les peticions
fent broadcast. Això sol afectar xarxes en què hi ha un DHCP
relay (normalment el router) que s'encarrega de capturar totes
les peticions de DHCP localment a cada xarxa i les trasllada al
servidor DHCP central perquè respongui.

Salut,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Re: dhclient deixa de funcionar

[Narcis Garcia]

__
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 13/4/20 a les 13:11, Alex Muntada ha escrit:
> Hola Narcis,
> 
>> Coincideix que els ordinadors amb aquest problema foren
>> instal·lats de zero amb Debian 9, i després actualitzats a
>> Debian 10.
> 
> Diria que em va passar quelcom similar després d'actualitzar un
> servidor virtual i vaig poder resoldre el problema amb el que
> proposen a: https://serverfault.com/a/463339
> 

Gràcies, ja provaré.

Estic en el cert que dhclient ha de ser un procés viu tota l'estona?
Jo el què em trobo és que dhclient mor, i suposo que per això no renova
les dades IP.
Per a diagnosticar-ho bé hauria de comparar 2 ordinadors: Un amb Debian
7 (sense estar governat per Systemd) i l'altre amb Debian 10, i ambdós
sense NetworkManager ni altres reemplaçaments.

No entenc el què produeix això, reemplaçant dhcp-server-identifier :
interface "ethX" {
   supersede dhcp-server-identifier 255.255.255.255;
}

Re: dhclient deixa de funcionar

[Alex Muntada]

Hola Narcis,

> Coincideix que els ordinadors amb aquest problema foren
> instal·lats de zero amb Debian 9, i després actualitzats a
> Debian 10.

Diria que em va passar quelcom similar després d'actualitzar un
servidor virtual i vaig poder resoldre el problema amb el que
proposen a: https://serverfault.com/a/463339

Salut,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Re: dhclient deixa de funcionar

[Narcis Garcia]

Que jo recordi, la nomenclatura de Systemd/udev per a les targetes de
xarxa va canviar abans de Debian 9.
I igualment no, en cap dels casos no havien canviat aquests noms (ja
eren del «nou estil»).


Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 12/4/20 a les 16:29, Josep Lladonosa ha escrit:
> Hola, Narcís,
> 
> Algun cop m'havia passat alguna cosa semblant. Potser et passa pel canvi
> de nomenclatura de les targetes de xarxa? Encara tens eth0?
> 
> 
> 
> 
> On Sun, 12 Apr 2020 at 12:49, Narcis Garcia  <mailto:debianli...@actiu.net>> wrote:
> 
> Ja m'he trobat en més d'un ordinador (sense NetworkManager):
> Sembla que dhclient funciona com a servei, i suposo que, quan caduca la
> concessió DHCP per a la configuració de la targeta de xarxa, deu ser
> l'encarregat de fer una nova petició i renovar les dades.
> 
> La cosa és que en 2 o 3 ordinadors sempre engegats he vist com aquest
> programa o servei finalitza (deixa d'executar-se) i després d'uns dies
> la targeta de xarxa deixa d'estar configurada.
> Aleshores, és clar, no hi ha accés de/a Internet ni altres ordinadors.
> 
> Coincideix que els ordinadors amb aquest problema foren instal·lats de
> zero amb Debian 9, i després actualitzats a Debian 10.
> 
> Algú sap de què va això, i com corregir-ho?
> 
> Gràcies.
> 
> -- 
> Salut i ara desobediència;
> Narcis Garcia
> 
> __
> I'm using this dedicated address because personal addresses aren't
> masked enough at this mail public archive. Public archive administrator
> should fix this against automated addresses collectors.
> 
> 
> 
> -- 
> --
> Salutacions...Josep
> --

Re: dhclient deixa de funcionar

[Josep Lladonosa]

Hola, Narcís,

Algun cop m'havia passat alguna cosa semblant. Potser et passa pel canvi de
nomenclatura de les targetes de xarxa? Encara tens eth0?




On Sun, 12 Apr 2020 at 12:49, Narcis Garcia  wrote:

> Ja m'he trobat en més d'un ordinador (sense NetworkManager):
> Sembla que dhclient funciona com a servei, i suposo que, quan caduca la
> concessió DHCP per a la configuració de la targeta de xarxa, deu ser
> l'encarregat de fer una nova petició i renovar les dades.
>
> La cosa és que en 2 o 3 ordinadors sempre engegats he vist com aquest
> programa o servei finalitza (deixa d'executar-se) i després d'uns dies
> la targeta de xarxa deixa d'estar configurada.
> Aleshores, és clar, no hi ha accés de/a Internet ni altres ordinadors.
>
> Coincideix que els ordinadors amb aquest problema foren instal·lats de
> zero amb Debian 9, i després actualitzats a Debian 10.
>
> Algú sap de què va això, i com corregir-ho?
>
> Gràcies.
>
> --
> Salut i ara desobediència;
> Narcis Garcia
>
> __
> I'm using this dedicated address because personal addresses aren't
> masked enough at this mail public archive. Public archive administrator
> should fix this against automated addresses collectors.
>
>

-- 
--
Salutacions...Josep
--

dhclient deixa de funcionar

[Narcis Garcia]

Ja m'he trobat en més d'un ordinador (sense NetworkManager):
Sembla que dhclient funciona com a servei, i suposo que, quan caduca la
concessió DHCP per a la configuració de la targeta de xarxa, deu ser
l'encarregat de fer una nova petició i renovar les dades.

La cosa és que en 2 o 3 ordinadors sempre engegats he vist com aquest
programa o servei finalitza (deixa d'executar-se) i després d'uns dies
la targeta de xarxa deixa d'estar configurada.
Aleshores, és clar, no hi ha accés de/a Internet ni altres ordinadors.

Coincideix que els ordinadors amb aquest problema foren instal·lats de
zero amb Debian 9, i després actualitzats a Debian 10.

Algú sap de què va això, i com corregir-ho?

Gràcies.

-- 
Salut i ara desobediència;
Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.

Re: dhclient and ipv6 DNS Servers

[Rainer Dorsch]

Am Freitag, 17. Januar 2020, 11:12:07 CET schrieb Curt:
> On 2020-01-16, Rainer Dorsch  wrote:
> > Am Mittwoch, 15. Januar 2020, 00:09:16 CET schrieb Pascal Hambourg:
> >> Le 14/01/2020 à 21:14, Rainer Dorsch a écrit :
> >> > prepend dhcp6.name-servers 2001:4860:4860::, 2001:4860:4860::8844;
> >> > 
> >> > avoids the error message, but has no visible effect I can see. The IPv6
> >> > DNS
> >> > servers still do not show in resolv.conf.
> >> 
> >> You may receive IPv6 DNS information from IPv6 Router Advertisements
> >> (RA) with rdnssd, not DHCPv6.
> > 
> > Many thanks, Pascal, that explains the obervations :-)
> > 
> > I have in /etc/network/interfaces
> > 
> > iface eth0.1 inet6 auto
> > 
> >   dhcp 1
> >   request_prefix 1
> > 
> > I could not find a way to overwrite the DNS server for rdnssd, does
> > anybody
> > know if that is possible?
> 
> All above and way beyond me, but from a cursory online examination of
> this affair it appears that beyond disabling rdnssd entirely, it's
> necessary to modify or patch the /etc/rdnssd/merge-hook script to
> prevent rdnssd from overwriting /etc/resolv.conf.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767071
> 
>  /etc/resolv.conf is handled by a configurable /etc/rdnssd/merge-hook
>  script that users can modify to suit their needs. The stock version
>  upstream has been modified to do what you want for ages:
> 
>  http://git.remlab.net/gitweb/?p=ndisc6.git;a=blob_plain;f=rdnssd/merge-hook
> .in;hb=f7bd3662d2292e248173721d4760c03df39df666

Many thanks for your response, Curt, that helped at least to hack an overwrite 
to the ipv6 DNS server.

I do not understand what the upsteam does which Debian does not (also the bug 
you are refering to is resolved!). Nevertheless, the merge-hook script is a 
good place to look at.

As a quick fix I commented the line

#mv -f $resolvconf.tmp $resolvconf

This at least keeps rdnssd from overwriting the resolv.conf constantly.

I think a better solution would be to check if a e.g. DNS6 variable is defined 
(e.g. in /etc/default/rdnssd) and if yes, ignore the content of

root@home:~# cat /var/run/rdnssd/resolv.conf 
nameserver fe80::d263:b4ff:fe00:325c%eth0.7
nameserver fd38:81d3:9dac::1
nameserver fd22:c2e0:8eb2::1
root@home:~# 

and use the content of the DNS6 variable instead.

Berni,

does that make sense or is there already another mechanism in place for 
overwriting the (ipv6) DNS Server?

I think I could provide you a patch for the script, if that makes sense for 
you to integrate in the Debian package.

Thanks
Rainer






-- 
Rainer Dorsch
http://bokomoko.de/

Re: dhclient and ipv6 DNS Servers

[Curt]

On 2020-01-16, Rainer Dorsch  wrote:
> Am Mittwoch, 15. Januar 2020, 00:09:16 CET schrieb Pascal Hambourg:
>> Le 14/01/2020 à 21:14, Rainer Dorsch a écrit :
>> > prepend dhcp6.name-servers 2001:4860:4860::, 2001:4860:4860::8844;
>> > 
>> > avoids the error message, but has no visible effect I can see. The IPv6
>> > DNS
>> > servers still do not show in resolv.conf.
>> 
>> You may receive IPv6 DNS information from IPv6 Router Advertisements
>> (RA) with rdnssd, not DHCPv6.
>
> Many thanks, Pascal, that explains the obervations :-)
>
> I have in /etc/network/interfaces
>
> iface eth0.1 inet6 auto
>   dhcp 1
>   request_prefix 1
>
> I could not find a way to overwrite the DNS server for rdnssd, does anybody 
> know if that is possible?
>
>

All above and way beyond me, but from a cursory online examination of
this affair it appears that beyond disabling rdnssd entirely, it's
necessary to modify or patch the /etc/rdnssd/merge-hook script to
prevent rdnssd from overwriting /etc/resolv.conf.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767071

 /etc/resolv.conf is handled by a configurable /etc/rdnssd/merge-hook
 script that users can modify to suit their needs. The stock version
 upstream has been modified to do what you want for ages:

 
http://git.remlab.net/gitweb/?p=ndisc6.git;a=blob_plain;f=rdnssd/merge-hook.in;hb=f7bd3662d2292e248173721d4760c03df39df666

Good luck.

-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: dhclient and ipv6 DNS Servers

[Rainer Dorsch]

Am Mittwoch, 15. Januar 2020, 00:09:16 CET schrieb Pascal Hambourg:
> Le 14/01/2020 à 21:14, Rainer Dorsch a écrit :
> > prepend dhcp6.name-servers 2001:4860:4860::, 2001:4860:4860::8844;
> > 
> > avoids the error message, but has no visible effect I can see. The IPv6
> > DNS
> > servers still do not show in resolv.conf.
> 
> You may receive IPv6 DNS information from IPv6 Router Advertisements
> (RA) with rdnssd, not DHCPv6.

Many thanks, Pascal, that explains the obervations :-)

I have in /etc/network/interfaces

iface eth0.1 inet6 auto
  dhcp 1
  request_prefix 1

I could not find a way to overwrite the DNS server for rdnssd, does anybody 
know if that is possible?


According to the interfaces man page, dhclient should be responsible with the 
dhcp method

iface eth0.1 inet6 dhcp
  request_prefix 1

ifup shows the nameservers in the log

Thu Jan 16 23:15:13 CET 2020: entering /etc/dhcp/dhclient-enter-hooks.d, 
dumping variables.
reason='PREINIT'
interface='eth0.1'
--
Thu Jan 16 23:15:13 CET 2020: entering /etc/dhcp/dhclient-exit-hooks.d, 
dumping variables.
reason='PREINIT'
interface='eth0.1'
--
Thu Jan 16 23:15:14 CET 2020: entering /etc/dhcp/dhclient-enter-hooks.d, 
dumping variables.
reason='REBOOT'
interface='eth0.1'
new_ip_address='192.168.0.30'
new_network_number='192.168.0.0'
new_subnet_mask='255.255.255.0'
new_broadcast_address='192.168.0.255'
new_routers='192.168.0.1'
new_domain_name='bokomoko.de'
new_domain_name_servers='192.168.0.1'
new_ntp_servers='192.168.0.1'
new_dhcp6_name_servers='2001:4860:4860:: 2001:4860:4860::8844'
--
Thu Jan 16 23:15:14 CET 2020: entering /etc/dhcp/dhclient-exit-hooks.d, 
dumping variables.
reason='REBOOT'
interface='eth0.1'
new_ip_address='192.168.0.30'
new_network_number='192.168.0.0'
new_subnet_mask='255.255.255.0'
new_broadcast_address='192.168.0.255'
new_routers='192.168.0.1'
new_domain_name='bokomoko.de'
new_domain_name_servers='192.168.0.1'
new_ntp_servers='192.168.0.1'
new_dhcp6_name_servers='2001:4860:4860:: 2001:4860:4860::8844'
--
Thu Jan 16 23:15:14 CET 2020: entering /etc/dhcp/dhclient-enter-hooks.d, 
dumping variables.
reason='PREINIT6'
interface='eth0.1'
--
Thu Jan 16 23:15:14 CET 2020: entering /etc/dhcp/dhclient-exit-hooks.d, 
dumping variables.
reason='PREINIT6'
interface='eth0.1'
--


but then I do not see an impact on resolv.conf:

nameserver fd38:81d3:9dac::1
nameserver fd22:c2e0:8eb2::1

ifup produces this output

XMT: Forming Solicit, 31050 ms elapsed.
XMT:  X-- IA_NA b4:00:32:5c
XMT:  | X-- Request renew in  +3600
XMT:  | X-- Request rebind in +5400
XMT:  X-- IA_PD b4:00:32:5c
XMT:  | X-- Request renew in  +3600
XMT:  | X-- Request rebind in +5400
XMT:  | X-- Request prefix 2a02:8070:898f:e4fc::/62.
XMT:  | | X-- Request preferred in +7200
XMT:  | | X-- Request valid in +10800
XMT: Solicit on eth0.1, interval 33560ms.
RCV: Advertise message on eth0.1 from fe80::e228:6dff:fe43:5776.
RCV:  X-- Server ID: 00:03:00:01:e0:28:6d:43:57:76
PRC: Lease failed to satisfy.

Any hint is still welcome :-)

Thanks
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

Re: dhclient and ipv6 DNS Servers

[tomas]

On Tue, Jan 14, 2020 at 01:18:01PM -0500, Greg Wooledge wrote:
> On Tue, Jan 14, 2020 at 12:12:03PM -0500, Bob Weber wrote:
> > Just edit the file /etc/resolv.conf and make it immutable (chattr +i 

[...]

> That is one of the options given on the wiki page.
> 
> https://wiki.debian.org/resolv.conf
> 
> Be sure you work around bug #860928 if you use this approach.

This is a very instructive bug, thanks for linking it :-)

That's why I usually recommend doing the chattr +i for debugging
purposes only. The software "on the other side" won't expect it,
and it'll reveal strange bugs procedure) is... risky.

Cheers
-- tomás.


signature.asc
Description: Digital signature

Re: dhclient and ipv6 DNS Servers

[Pascal Hambourg]

Le 14/01/2020 à 21:14, Rainer Dorsch a écrit :


prepend dhcp6.name-servers 2001:4860:4860::, 2001:4860:4860::8844;

avoids the error message, but has no visible effect I can see. The IPv6 DNS
servers still do not show in resolv.conf.


You may receive IPv6 DNS information from IPv6 Router Advertisements 
(RA) with rdnssd, not DHCPv6.

Re: dhclient and ipv6 DNS Servers

[Rainer Dorsch]

Am Dienstag, 14. Januar 2020, 21:14:26 CET schrieben Sie:
> Am Dienstag, 14. Januar 2020, 19:18:01 CET schrieb Greg Wooledge:
> > On Tue, Jan 14, 2020 at 12:12:03PM -0500, Bob Weber wrote:
> > > Just edit the file /etc/resolv.conf and make it immutable (chattr +i
> > > /etc/resolv.conf).  At least you will know what is in the file and that
> > > it
> > > can't be changed (mistakes and all).  I use this to keep chrome from
> > > changing the google-chrome-beta.list file every time it starts since I
> > > use
> > > the HTTPS/// option of  apt-cacher-ng to use https transfers outside my
> > > LAN.
> > 
> > That is one of the options given on the wiki page.
> > 
> > https://wiki.debian.org/resolv.conf
> > 
> > Be sure you work around bug #860928 if you use this approach.
> 
> Thank you for all the good replies to this thread.
> 
> prepend dhcp6.name-servers 2001:4860:4860::, 2001:4860:4860::8844;
> 
> avoids the error message, but has no visible effect I can see. The IPv6 DNS
> servers still do not show in resolv.conf.
> 
> Unfortunately,
> 
> root@home:~# cat /etc/dhcp/dhclient-enter-hooks.d/leave_my_resolv_conf_alone
> make_resolv_conf() { :; }
> root@home:~# ls -l
> /etc/dhcp/dhclient-enter-hooks.d/leave_my_resolv_conf_alone -rwxr-xr-x 1
> root root 26 Jan 14 20:59 /etc/dhcp/dhclient-enter-hooks.d/
> leave_my_resolv_conf_alone
> root@home:~#
> 
> does not stop the system to overwrite /etc/resolv.conf constantly.
> 
> Do I need to restart a service that the change takes effect?
> 
> I did an ifdown/ifup eth0.1 ...
> 

Another interesting datapoint, if I enable debug data, I get with 

prepend dhcp6.name-servers 2001:4860:4860::, 2001:4860:4860::8844;

in dhclient.conf

as debug data in /tmp/dhclient-script.debug

--
Tue Jan 14 22:40:15 CET 2020: entering /etc/dhcp/dhclient-exit-hooks.d, 
dumping variables.
reason='PREINIT'
interface='eth0.1'
--
Tue Jan 14 22:40:15 CET 2020: entering /etc/dhcp/dhclient-enter-hooks.d, 
dumping variables.
reason='BOUND'
interface='eth0.1'
new_ip_address='192.168.0.30'
new_network_number='192.168.0.0'
new_subnet_mask='255.255.255.0'
new_broadcast_address='192.168.0.255'
new_routers='192.168.0.1'
new_domain_name='bokomoko.de'
new_domain_name_servers='192.168.0.1'
new_ntp_servers='192.168.0.1'
new_dhcp6_name_servers='2001:4860:4860:: 2001:4860:4860::8844'
old_ip_address='192.168.0.30'
old_network_number='192.168.0.0'
old_subnet_mask='255.255.255.0'
old_broadcast_address='192.168.0.255'
old_routers='192.168.0.1'
old_domain_name='bokomoko.de'
old_domain_name_servers='192.168.0.1'
old_ntp_servers='192.168.0.1'
old_dhcp6_name_servers='2001:4860:4860:: 2001:4860:4860::8844'
--
Tue Jan 14 22:40:15 CET 2020: entering /etc/dhcp/dhclient-exit-hooks.d, 
dumping variables.
reason='BOUND'
interface='eth0.1'
new_ip_address='192.168.0.30'
new_network_number='192.168.0.0'
new_subnet_mask='255.255.255.0'
new_broadcast_address='192.168.0.255'
new_routers='192.168.0.1'
new_domain_name='bokomoko.de'
new_domain_name_servers='192.168.0.1'
new_ntp_servers='192.168.0.1'
new_dhcp6_name_servers='2001:4860:4860:: 2001:4860:4860::8844'
old_ip_address='192.168.0.30'
old_network_number='192.168.0.0'
old_subnet_mask='255.255.255.0'
old_broadcast_address='192.168.0.255'
old_routers='192.168.0.1'
old_domain_name='bokomoko.de'
old_domain_name_servers='192.168.0.1'
old_ntp_servers='192.168.0.1'
old_dhcp6_name_servers='2001:4860:4860:: 2001:4860:4860::8844'
--
Tue Jan 14 22:40:17 CET 2020: entering /etc/dhcp/dhclient-enter-hooks.d, 
dumping variables.
reason='PREINIT6'
interface='eth0.1'
--
Tue Jan 14 22:40:17 CET 2020: entering /etc/dhcp/dhclient-exit-hooks.d, 
dumping variables.
reason='PREINIT6'
interface='eth0.1'
--
Tue Jan 14 22:40:18 CET 2020: entering /etc/dhcp/dhclient-enter-hooks.d, 
dumping variables.
reason='REBIND6'
interface='eth0.1'
new_domain_name='bokomoko.de'
new_ip6_prefix='2a02:8070:898f:e4fc::/62'
new_dhcp6_name_servers='2001:4860:4860:: 2001:4860:4860::8844 
fd00::e228:6dff:fe43:5776'
old_domain_name='bokomoko.de'
old_ip6_prefix='2a02:8070:898f:e4fc::/62'
old_dhcp6_name_servers='2001:4860:4860:: 2001:4860:4860::8844 
fd00::e228:6dff:fe43:5776'
--
Tue Jan 14 22:40:18 CET 2020: entering /etc/dhcp/dhclient-exit-hooks.d, 
dumping variables.
reason='REBIND6'
interface='eth0.1'
new_domain_name='bokomoko.de'
new_ip6_prefix='2a02:8070:898f:e4fc::/62'
new_dhcp6_name_servers='2001:4860:4860:: 2001:4860:4860::8844 
fd00::e228:6dff:fe43:5776'
old_domain_name='bokomoko.de'
old_ip6_prefix='2a02:8070:898f:e4fc::/62'
old_dhcp6_name_servers='2001:4860:4860:: 2001:4860:4860::8844 
fd00::e228:6dff:fe43:5776'
-

Re: dhclient and ipv6 DNS Servers

[Rainer Dorsch]

Am Dienstag, 14. Januar 2020, 19:18:01 CET schrieb Greg Wooledge:
> On Tue, Jan 14, 2020 at 12:12:03PM -0500, Bob Weber wrote:
> > Just edit the file /etc/resolv.conf and make it immutable (chattr +i 
> > /etc/resolv.conf).  At least you will know what is in the file and that it
> > can't be changed (mistakes and all).  I use this to keep chrome from
> > changing the google-chrome-beta.list file every time it starts since I use
> > the HTTPS/// option of  apt-cacher-ng to use https transfers outside my
> > LAN.
> That is one of the options given on the wiki page.
> 
> https://wiki.debian.org/resolv.conf
> 
> Be sure you work around bug #860928 if you use this approach.

Thank you for all the good replies to this thread.

prepend dhcp6.name-servers 2001:4860:4860::, 2001:4860:4860::8844;   

avoids the error message, but has no visible effect I can see. The IPv6 DNS 
servers still do not show in resolv.conf.

Unfortunately,

root@home:~# cat /etc/dhcp/dhclient-enter-hooks.d/leave_my_resolv_conf_alone 
make_resolv_conf() { :; }
root@home:~# ls -l /etc/dhcp/dhclient-enter-hooks.d/leave_my_resolv_conf_alone
-rwxr-xr-x 1 root root 26 Jan 14 20:59 /etc/dhcp/dhclient-enter-hooks.d/
leave_my_resolv_conf_alone
root@home:~# 

does not stop the system to overwrite /etc/resolv.conf constantly.

Do I need to restart a service that the change takes effect?

I did an ifdown/ifup eth0.1 ...

Thanks again
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

Re: dhclient and ipv6 DNS Servers

[Greg Wooledge]

On Tue, Jan 14, 2020 at 12:12:03PM -0500, Bob Weber wrote:
> Just edit the file /etc/resolv.conf and make it immutable (chattr +i 
> /etc/resolv.conf).  At least you will know what is in the file and that it
> can't be changed (mistakes and all).  I use this to keep chrome from
> changing the google-chrome-beta.list file every time it starts since I use
> the HTTPS/// option of  apt-cacher-ng to use https transfers outside my LAN.

That is one of the options given on the wiki page.

https://wiki.debian.org/resolv.conf

Be sure you work around bug #860928 if you use this approach.

Re: dhclient and ipv6 DNS Servers

[Bob Weber]

Meanwhile, there are a few different ways to keep your resolv.conf
file untouched, rather than relying on isc-dhcp-client to continually
rewrite it in the form you want.  The wiki page describes some of
those ways.

Personally, I do not understand the appeal of the "put lines in
configuration file X so that isc-dhcp-client will use them when it
rewrites configuration file Y" approach.  I'd rather just edit file Y by
hand and tell isc-dhcp-client not to touch it at all.  It's a shame that
it's so incredibly difficult to do that.  But, that's why we have the
resolvconf package, and it's why we have the wiki page that describes
how to do it.

Just edit the file /etc/resolv.conf and make it immutable (chattr +i  
/etc/resolv.conf).  At least you will know what is in the file and that it can't 
be changed (mistakes and all).  I use this to keep chrome from changing the 
google-chrome-beta.list file every time it starts since I use the HTTPS/// 
option of  apt-cacher-ng to use https transfers outside my LAN.


--


*...Bob*

Re: dhclient and ipv6 DNS Servers

[Greg Wooledge]

On Tue, Jan 14, 2020 at 03:00:50PM +, Curt wrote:
> On 2020-01-14, Greg Wooledge  wrote:
> > On Tue, Jan 14, 2020 at 09:37:05AM +0100, Rainer Dorsch wrote:
> >> I tried to switch to other servers, e.g. Google, but this does not work, 
> >> since
> >> 
> >> /etc/resolv.conf gets  overwritten with a high frequency
> >
> > https://wiki.debian.org/resolv.conf
> 
> Actually, as I've said elsewhere (but I'm still dealing with a gmane
> post-absorption issue so I'll repeat it here) I believe he needs the
> 
>  prepend dhcp6.name-servers ...
> 
> option for ipv6 as described in the dhcp-options manpage. This
> is why he's receiving the "semicolon expected" error.

None of my systems have IPv6, so I can't be the one to verify any
of that information to add to the wiki page.  If you'd like to do it,
that's great.

Meanwhile, there are a few different ways to keep your resolv.conf
file untouched, rather than relying on isc-dhcp-client to continually
rewrite it in the form you want.  The wiki page describes some of
those ways.

Personally, I do not understand the appeal of the "put lines in
configuration file X so that isc-dhcp-client will use them when it
rewrites configuration file Y" approach.  I'd rather just edit file Y by
hand and tell isc-dhcp-client not to touch it at all.  It's a shame that
it's so incredibly difficult to do that.  But, that's why we have the
resolvconf package, and it's why we have the wiki page that describes
how to do it.

Re: dhclient and ipv6 DNS Servers

[Curt]

On 2020-01-14, Greg Wooledge  wrote:
> On Tue, Jan 14, 2020 at 09:37:05AM +0100, Rainer Dorsch wrote:
>> I tried to switch to other servers, e.g. Google, but this does not work, 
>> since
>> 
>> /etc/resolv.conf gets  overwritten with a high frequency
>
> https://wiki.debian.org/resolv.conf

Actually, as I've said elsewhere (but I'm still dealing with a gmane
post-absorption issue so I'll repeat it here) I believe he needs the

 prepend dhcp6.name-servers ...

option for ipv6 as described in the dhcp-options manpage. This
is why he's receiving the "semicolon expected" error.


-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: dhclient and ipv6 DNS Servers

[Curt]

On 2020-01-14, Rainer Dorsch  wrote:

>
> https://developers.google.com/speed/public-dns/docs/using
>
> and add to /etc/dhcp/dhclient.conf
>
> prepend domain-name-servers 2001:4860:4860::, 2001:4860:4860::8844;
>
> dhclient becomes unhappy (during an ifup eth0.1)
>
> /etc/dhcp/dhclient.conf line 26: semicolon expected.
> prepend domain-name-servers 2001:
>  ^
> /etc/dhcp/dhclient.conf line 26: expecting a statement.
> prepend domain-name-servers 2001:4860:4860::, 2001:4860:4860::8844;
>^
> /etc/dhcp/dhclient.conf line 26: semicolon expected.
>

Have you tried

  prepend dhcp6.name-servers ...

as described in the dhcp-options manpage?


-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: dhclient and ipv6 DNS Servers

[Greg Wooledge]

On Tue, Jan 14, 2020 at 09:37:05AM +0100, Rainer Dorsch wrote:
> I tried to switch to other servers, e.g. Google, but this does not work, since
> 
> /etc/resolv.conf gets  overwritten with a high frequency

https://wiki.debian.org/resolv.conf

Re: dhclient and ipv6 DNS Servers

[Richard Hector]

On 14/01/20 9:37 pm, Rainer Dorsch wrote:

> /etc/dhcp/dhclient.conf does not accept ipv6 addresses like, since if I
> use the instructions from
> 
>  
> 
> https://developers.google.com/speed/public-dns/docs/using
> 
>  
> 
> and add to /etc/dhcp/dhclient.conf
> 
>  
> 
> prependdomain-name-servers 2001:4860:4860::, 2001:4860:4860::8844;
> 
> dhclient becomes unhappy (during an ifup eth0.1)
> 
>  
> 
> /etc/dhcp/dhclient.conf line 26: semicolon expected.
> 
> prepend domain-name-servers 2001:
> 
> ^
> 
> /etc/dhcp/dhclient.conf line 26: expecting a statement.
> 
> prepend domain-name-servers 2001:4860:4860::, 2001:4860:4860::8844;
> 
> ^
> 
> /etc/dhcp/dhclient.conf line 26: semicolon expected.
> 

Hi Rainer,

From dhcp-options(5), it looks like you need:

prepend dhcp6.name-servers 2001:4860:4860::, 2001:4860:4860::8844;

instead. I haven't tried it myself.

Richard



signature.asc
Description: OpenPGP digital signature

dhclient and ipv6 DNS Servers

[Rainer Dorsch]

Hello,

the ipv6 DNS servers I get supplied from my ISP

nameserver fd38:81d3:9dac::1
nameserver fd22:c2e0:8eb2::1

have problems from time to time.

I tried to switch to other servers, e.g. Google, but this does not work, since

/etc/resolv.conf gets  overwritten with a high frequency

/etc/dhcp/dhclient.conf does not accept ipv6 addresses like, since if I use 
the instructions from

https://developers.google.com/speed/public-dns/docs/using

and add to /etc/dhcp/dhclient.conf

prepend domain-name-servers 2001:4860:4860::, 2001:4860:4860::8844;

dhclient becomes unhappy (during an ifup eth0.1)

/etc/dhcp/dhclient.conf line 26: semicolon expected.
prepend domain-name-servers 2001:
 ^
/etc/dhcp/dhclient.conf line 26: expecting a statement.
prepend domain-name-servers 2001:4860:4860::, 2001:4860:4860::8844;
   ^
/etc/dhcp/dhclient.conf line 26: semicolon expected.

^

prepend domain-name-servers 8.8.8.8;
works, but still comes after the ipv6 nameservers

root@home:~# cat /etc/resolv.conf
domain bokomoko.de 
search bokomoko.de 
nameserver fd38:81d3:9dac::1 
nameserver fd22:c2e0:8eb2::1 
nameserver 8.8.8.8 
nameserver 192.168.0.1 
root@home:~# 

and the slow servers get queried first :-/


Probably unrelated, but today even Murphy seems to be with me, even if I 
switch on my ISP modem to alternate DNS servers, this gets ignored.

Any hint is welcome.

Thanks
Rainer



-- 
Rainer Dorsch
http://bokomoko.de/

Utilisation de dhclient-up-hooks

[Olivier]

Bonjour,

La doc dhclient-script [1] fait référence à un script
/etc/dhcp/dhclient-up-hooks qui n'est jamais exécuté sur ma machine sous
Stretch.

Sur ma machine, les scripts dans /etc/dhcp/dhclient-enter-hooks.d sont
exécutés mais pas le script /etc/dhcp/dhclient-up-hooks ou des variations
de celui-ci (script /etc/dhcp/dhclient-up-hooks.d/ffobar, ...).

Qui a réussit à faire exécuter ce script ?

Slts

[1] https://linux.die.net/man/8/dhclient-script

Systemd equivalent to dhclient exit-hooks script

[john doe]

Hi,

I configure a dhcp interface using systemd-networkd.
When a new lease is acquired I need to reload some services.
How can I do that?

In other words: I'm looking for a systemd equivalent to dhclient exit 
hooks script.


I'm on Debian 9.

--
John Doe

Re: Dhclient não funciona automaticamente

[Diego Rabatone Oliveira]

Sávio,

se você setou a interface com IP estático porque o DHCLIENT deveria "rodar
automaticamente" para ela? Não faria sentido.

Se você quer o dhclient rodando para outra interface, configure-a indicando
isso.


Diego Rabatone Oliveira
http://blog.diraol.eng.br
diraol(arroba)diraol(ponto)eng(ponto)br
Twitter: @diraol

Em 27 de julho de 2017 12:14, P. J. <pjotam...@gmail.com> escreveu:

> Acredito que se as estações desktop com GUI não seja necessário
> escrever diretamente no arquivo e sim usar o utilitário de
> gerenciamento de conexões, por exemplo networkmanager, pois usando
> diretamente no arquivo suponho q dê algum conflito...
>
> Mas não seria melhor setar diretamente no servidor DHCP??
>
> Posso estar errado tb
>
> Em 27/07/2017, Sávio Ramos<savio.deb...@gmail.com> escreveu:
> > Olá,
> >
> > Desejo que minha máquina fique com ip estático. Acrescentei as linhas
> > abaixo no arquivo /etc/network/interfaces
> >
> > auto enp0s25
> > iface enp0s25 inet static
> > address 192.168.0.2
> > netmask 255.255.255.0
> > network 192.168.0.0
> > broadcast 192.168.0.255
> > gateway 192.168.0.1
> >
> >
> > Depois disto, para me conectar a internet, tenho que digitar como root
> > o comando:  dhclient.
> >
> > Por que este comando não funciona mais automaticamente?
> >
> > Eu sei a senha do root e executo o comando mas, outras pessoas não
> > sabem fazer isto.
> >
> > Alguma luz?
> >
> > Grato.
> > --
> > Sávio M Ramos
> > Arquiteto, Rio, RJ
> > Só uso Linux desde 2000
> > www.debian.org
> >
> >
>
>
> --
> |  .''`.   A fé não dá respostas. Só impede perguntas.
> | : :'  :
> | `. `'`
> |   `-   Je vois tout
>
>

Re: Dhclient não funciona automaticamente

[P. J.]

Acredito que se as estações desktop com GUI não seja necessário
escrever diretamente no arquivo e sim usar o utilitário de
gerenciamento de conexões, por exemplo networkmanager, pois usando
diretamente no arquivo suponho q dê algum conflito...

Mas não seria melhor setar diretamente no servidor DHCP??

Posso estar errado tb

Em 27/07/2017, Sávio Ramos<savio.deb...@gmail.com> escreveu:
> Olá,
>
> Desejo que minha máquina fique com ip estático. Acrescentei as linhas
> abaixo no arquivo /etc/network/interfaces
>
> auto enp0s25
> iface enp0s25 inet static
> address 192.168.0.2
> netmask 255.255.255.0
> network 192.168.0.0
> broadcast 192.168.0.255
> gateway 192.168.0.1
>
>
> Depois disto, para me conectar a internet, tenho que digitar como root
> o comando:  dhclient.
>
> Por que este comando não funciona mais automaticamente?
>
> Eu sei a senha do root e executo o comando mas, outras pessoas não
> sabem fazer isto.
>
> Alguma luz?
>
> Grato.
> --
> Sávio M Ramos
> Arquiteto, Rio, RJ
> Só uso Linux desde 2000
> www.debian.org
>
>


-- 
|  .''`.   A fé não dá respostas. Só impede perguntas.
| : :'  :
| `. `'`
|   `-   Je vois tout

Dhclient não funciona automaticamente

[Sávio Ramos]

Olá,

Desejo que minha máquina fique com ip estático. Acrescentei as linhas
abaixo no arquivo /etc/network/interfaces

auto enp0s25
iface enp0s25 inet static
address 192.168.0.2
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.1


Depois disto, para me conectar a internet, tenho que digitar como root
o comando:  dhclient.

Por que este comando não funciona mais automaticamente?

Eu sei a senha do root e executo o comando mas, outras pessoas não
sabem fazer isto.

Alguma luz?

Grato.
-- 
Sávio M Ramos
Arquiteto, Rio, RJ
Só uso Linux desde 2000
www.debian.org

dhclient doesn't send DHCP options

[Joshua Schaeffer]

Anybody seen this issue where dhclient does not send the user-class option in 
it's solicit message. I have a minimal dhclient.conf file and when I start 
dhclient I can see that option 15 isn't sent:

root@blldhcptest01:~# cat /etc/dhcp/dhclient.conf
senduser-class"dhcp server";
requesttime-offset, host-name, dhcp6.name-servers, 
dhcp6.domain-search, dhcp6.fqdn;
do-forward-updatesoff;

root@blldhcptest01:~# dhclient -6 -pf /run/dhclient6.eth0.pid -I eth0 -d -v 
-cf /etc/dhcp/dhclient.conf
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on Socket/eth0
Sending on   Socket/eth0
PRC: Soliciting for leases (INIT).
XMT: Forming Solicit, 0 ms elapsed.
XMT:  X-- IA_NA 3e:1e:cd:ff
XMT:  | X-- Request renew in  +3600
XMT:  | X-- Request rebind in +5400
XMT: Solicit on eth0, interval 1030ms.
RCV: Advertise message on eth0 from fe80::216:3eff:fe11:10ab.
RCV:  X-- IA_NA 3e:1e:cd:ff
RCV:  | X-- starts 1500753449
RCV:  | X-- t1 - renew  +0
RCV:  | X-- t2 - rebind +0
RCV:  | X-- [Options]
RCV:  X-- Server ID: 00:01:00:01:21:04:51:d0:00:16:3e:11:10:ab
IA_NA status code NoAddrsAvail: "No addresses available for this interface."

And I don't see the option in the packet:

No. TimeSourceDestination   Protocol 
Length Info
  2 1.640863fe80::216:3eff:fe1e:cdff ff02::1:2 DHCPv6   
116Solicit XID: 0x7ea155 CID: 00010001210664ed00163e1ecdff

Frame 2: 116 bytes on wire (928 bits), 116 bytes captured (928 bits)
Ethernet II, Src: Xensourc_1e:cd:ff (00:16:3e:1e:cd:ff), Dst: 
IPv6mcast_01:00:02 (33:33:00:01:00:02)
Internet Protocol Version 6, Src: fe80::216:3eff:fe1e:cdff 
(fe80::216:3eff:fe1e:cdff), Dst: ff02::1:2 (ff02::1:2)
User Datagram Protocol, Src Port: 546 (546), Dst Port: 547 (547)
DHCPv6
Message type: Solicit (1)
Transaction ID: 0x7ea155
Client Identifier
Option: Client Identifier (1)
Length: 14
Value: 00010001210664ed00163e1ecdff
DUID: 00010001210664ed00163e1ecdff
DUID Type: link-layer address plus time (1)
Hardware type: Ethernet (1)
DUID Time: Jul 22, 2017 13:33:01.0 MDT
Link-layer address: 00:16:3e:1e:cd:ff
Option Request
Option: Option Request (6)
Length: 6
Value: 001700180027
Requested Option code: DNS recursive name server (23)
Requested Option code: Domain Search List (24)
Requested Option code: Fully Qualified Domain Name (39)
Elapsed time
Option: Elapsed time (8)
Length: 2
Value: 
Elapsed time: 0 ms
Identity Association for Non-temporary Address
Option: Identity Association for Non-temporary Address (3)
Length: 12
Value: 3e1ecdff0e101518
IAID: 3e1ecdff
T1: 3600
T2: 5400

I have classes defined on my DHCP server that requires the user-class option 
and because it isn't being sent it can't match the client to any class and as 
such returns a NoAddrsAvail status code is returned. Anybody encountered this 
before and know how to fix it?

Thanks,
Joshua Schaeffer

Re: dhclient or network problem

[Dominique Dumont]

On Monday, 10 July 2017 11:28:12 CEST Franz Angeli wrote:
> for example interface name eno52 (tg3, Broadcom Limited NetXtreme
> BCM5719 Gigabit Ethernet PCIe (rev 01) :

I had a similar issue due to a missing firmware. I think it was on a broadcom 
card.

Please check the kernel logs (journalctl -k) and check the logs mentioning 
your card.

HTH

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Re: dhclient or network problem

[Mark Fletcher]

On Mon, Jul 10, 2017 at 12:55:53PM +0200, Dejan Jocic wrote:
> On 10-07-17, Franz Angeli wrote:
> > Hi,
> > 
> > i have a problem with dhclient:
> > 
> > for example interface name eno52 (tg3, Broadcom Limited NetXtreme
> > BCM5719 Gigabit Ethernet PCIe (rev 01) :
> > 
> > root@:~# dhclient eno52 -v
> > Internet Systems Consortium DHCP Client 4.3.5
> > Copyright 2004-2016 Internet Systems Consortium.
> > All rights reserved.
> > For info, please visit https://www.isc.org/software/dhcp/
> > 
> > Listening on LPF/eno52/3c:a8:2a:e7:87:bf
> > Sending on   LPF/eno52/3c:a8:2a:e7:87:bf
> > Sending on   Socket/fallback
> > DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 4
> > DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 10
> > DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 7
> > DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 9
> > DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 15
> > DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 16
> > No DHCPOFFERS received.
> > No working leases in persistent database - sleeping.
> > 
> > tcpdump during dhclient doesn't show anything?!?
> > 
> > root@*:~# tcpdump -i eno52
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> > listening on eno52, link-type EN10MB (Ethernet), capture size 262144 bytes
> > 
> > 
> > root@***:~# ip addr show eno52
> > 9: eno52: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state
> > DOWN group default qlen 1000
> > link/ether 3c:a8:2a:e7:87:bf brd ff:ff:ff:ff:ff:ff
> > 
> > 
> > if i use the same ethernet cable on my laptop all works fine...
> 
> Don't you think that you have enough of a clue there :P That eno52 is,
> as you can see ethernet card, of course it will work when you connect it
> with ethernet cable. If you want it to work with wifi, that is another
> story. What is your wifi card, do you have something starting with w in
> the output of ip addr show? What is the output of the lspci -v | grep -i
> -A6 net?
> > 

Uh, no mate, I don't think that is what the OP meant. I suspect the 
laptop is a different computer. And telling us the cable works in his 
laptop is designed to head off suggestions the cable might be at fault.

He never mentiond WiFi anywhere.

Mark

Re: Debain 9 dhclient or network problem

[Brian]

On Tue 11 Jul 2017 at 09:24:01 +0200, Dejan Jocic wrote:
 
> You are doing lspci as root, so with A10 it does not get to the kernel
> driver and module part. Can you see what is there by using A15 instead?

If the driver turns out to be tg3 then firmware from nonfree is required.

-- 
Brian.

Re: Debain 9 dhclient or network problem

[Franz Angeli]

nothing usefull...

one strange thing is that during debian installation all works fine
because i use net-install with a iso.




2017-07-11 9:27 GMT+02:00 Johann Spies :
> On 11 July 2017 at 08:29, Franz Angeli  wrote:
>
>> i tried every other interface butt it's the same
>>
>> i tried also to disable interface renaming but doesn't work.
>
> What information do you get from /var/log/messages, /var/log/syslog
> and dmesg about your interfaces?
>
> Regards
> Johann
>

Re: Debain 9 dhclient or network problem

[Johann Spies]

On 11 July 2017 at 08:29, Franz Angeli  wrote:

> i tried every other interface butt it's the same
>
> i tried also to disable interface renaming but doesn't work.

What information do you get from /var/log/messages, /var/log/syslog
and dmesg about your interfaces?

Regards
Johann

Re: Debain 9 dhclient or network problem

[Dejan Jocic]

On 11-07-17, Franz Angeli wrote:
> Hi,
> 
> i have a problem with dhclient:
> 
> for example interface name eno52 (tg3, Broadcom Limited NetXtreme
> BCM5719 Gigabit Ethernet PCIe (rev 01) :
> 
> root@:~# dhclient eno52 -v
> Internet Systems Consortium DHCP Client 4.3.5
> Copyright 2004-2016 Internet Systems Consortium.
> All rights reserved.
> For info, please visit https://www.isc.org/software/dhcp/
> 
> Listening on LPF/eno52/3c:a8:2a:e7:87:bf
> Sending on   LPF/eno52/3c:a8:2a:e7:87:bf
> Sending on   Socket/fallback
> DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 4
> DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 10
> DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 7
> DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 9
> DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 15
> DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 16
> No DHCPOFFERS received.
> No working leases in persistent database - sleeping.
> 
> tcpdump during dhclient doesn't show anything?!?
> 
> root@*:~# tcpdump -i eno52
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eno52, link-type EN10MB (Ethernet), capture size 262144 bytes
> 
> 
> root@***:~# ip addr show eno52
> 9: eno52: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state
> DOWN group default qlen 1000
> link/ether 3c:a8:2a:e7:87:bf brd ff:ff:ff:ff:ff:ff
> 
> interface eno52 seems to be disconnected but cable is plugged and
> working (i tried with other pc)
> 
> obviously ethernet cable is connected...
> Debian 8 works fine with this hw
> Debian 9 doesn't work
> 
> Server is ProLiant DL380 Gen9 (719064-B21)
> 
> root@***:~# lspci -v | grep -A10 Ethernet
> 02:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM5719
> Gigabit Ethernet PCIe (rev 01)
> Subsystem: Hewlett-Packard Company Ethernet 1Gb 4-port 331i Adapter
> Flags: bus master, fast devsel, latency 0, IRQ 16, NUMA node 0
> Memory at 92c9 (64-bit, prefetchable) [size=64K]
> Memory at 92ca (64-bit, prefetchable) [size=64K]
> Memory at 92cb (64-bit, prefetchable) [size=64K]
> [virtual] Expansion ROM at 9310 [disabled] [size=256K]
> Capabilities: [48] Power Management version 3
> Capabilities: [50] Vital Product Data
> Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
> Capabilities: [a0] MSI-X: Enable+ Count=17 Masked-
> Capabilities: [ac] Express Endpoint, MSI 00
> --
> 02:00.1 Ethernet controller: Broadcom Limited NetXtreme BCM5719
> Gigabit Ethernet PCIe (rev 01)
> Subsystem: Hewlett-Packard Company Ethernet 1Gb 4-port 331i Adapter
> Flags: bus master, fast devsel, latency 0, IRQ 17, NUMA node 0
> Memory at 92c6 (64-bit, prefetchable) [size=64K]
> Memory at 92c7 (64-bit, prefetchable) [size=64K]
> Memory at 92c8 (64-bit, prefetchable) [size=64K]
> [virtual] Expansion ROM at 9314 [disabled] [size=256K]
> Capabilities: [48] Power Management version 3
> Capabilities: [50] Vital Product Data
> Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
> Capabilities: [a0] MSI-X: Enable- Count=17 Masked-
> Capabilities: [ac] Express Endpoint, MSI 00
> --
> 02:00.2 Ethernet controller: Broadcom Limited NetXtreme BCM5719
> Gigabit Ethernet PCIe (rev 01)
> Subsystem: Hewlett-Packard Company Ethernet 1Gb 4-port 331i Adapter
> Flags: bus master, fast devsel, latency 0, IRQ 16, NUMA node 0
> Memory at 92c3 (64-bit, prefetchable) [size=64K]
> Memory at 92c4 (64-bit, prefetchable) [size=64K]
> Memory at 92c5 (64-bit, prefetchable) [size=64K]
> [virtual] Expansion ROM at 9318 [disabled] [size=256K]
> Capabilities: [48] Power Management version 3
> Capabilities: [50] Vital Product Data
> Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
> Capabilities: [a0] MSI-X: Enable- Count=17 Masked-
> Capabilities: [ac] Express Endpoint, MSI 00
> --
> 02:00.3 Ethernet controller: Broadcom Limited NetXtreme BCM5719
> Gigabit Ethernet PCIe (rev 01)
> Subsystem: Hewlett-Packard Company Ethernet 1Gb 4-port 331i Adapter
> Flags: bus master, fast devsel, latency 0, IRQ 17, NUMA node 0
> Memory at 92c0 (64-bit, prefetchable) [size=64K]
> Memory at 92c1 (64-bit, prefetchable) [size=64K]
> Memory at 92c2 (64-bit, prefetchable) [size=64K]
> [virtual] Expansion ROM at 931c [disabled] [size=256K]
> Capabilities: [48] Power Management version 3
> Capabilities: [50] Vital Product Data
> Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
> Capabilities: [a0] MSI-X: Enable- Count=17 Masked-
> Capabilities: [ac] Express Endpoint, MSI 00
> --
> 04:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM5719
> Gigabi

Re: Debain 9 dhclient or network problem

[Franz Angeli]

Hi,

i tried every other interface butt it's the same

i tried also to disable interface renaming but doesn't work.

2017-07-11 8:02 GMT+02:00 Johann Spies <johann.sp...@gmail.com>:
> On 11 July 2017 at 07:48, Franz Angeli <franz.ang...@gmail.com> wrote:
>> Hi,
>>
>> i have a problem with dhclient:
>>
>> for example interface name eno52 (tg3, Broadcom Limited NetXtreme
>> BCM5719 Gigabit Ethernet PCIe (rev 01) :
>>
>> root@:~# dhclient eno52 -v
>> Internet Systems Consortium DHCP Client 4.3.5
>> Copyright 2004-2016 Internet Systems Consortium.
>> All rights reserved.
>> For info, please visit https://www.isc.org/software/dhcp/
>>
> ...
>> if i use the same ethernet cable on my laptop all works fine... (DHCP
>> lease and so on)
>
> My first guess would be that the order of the network interfaces
> differ between Debian 8 and 9 and that you should try the cable on the
> other interfaces.
>
> In the past (many years ago) it was a known problem that eth0 on the
> new system used for another interface.  I don't know whether this is
> still the case. It had been some time that I had to build a server.
>
> Regards
> Johann
> --
> Because experiencing your loyal love is better than life itself,
> my lips will praise you.  (Psalm 63:3)
>

Re: Debain 9 dhclient or network problem

[Johann Spies]

On 11 July 2017 at 07:48, Franz Angeli <franz.ang...@gmail.com> wrote:
> Hi,
>
> i have a problem with dhclient:
>
> for example interface name eno52 (tg3, Broadcom Limited NetXtreme
> BCM5719 Gigabit Ethernet PCIe (rev 01) :
>
> root@:~# dhclient eno52 -v
> Internet Systems Consortium DHCP Client 4.3.5
> Copyright 2004-2016 Internet Systems Consortium.
> All rights reserved.
> For info, please visit https://www.isc.org/software/dhcp/
>
...
> if i use the same ethernet cable on my laptop all works fine... (DHCP
> lease and so on)

My first guess would be that the order of the network interfaces
differ between Debian 8 and 9 and that you should try the cable on the
other interfaces.

In the past (many years ago) it was a known problem that eth0 on the
new system used for another interface.  I don't know whether this is
still the case. It had been some time that I had to build a server.

Regards
Johann
-- 
Because experiencing your loyal love is better than life itself,
my lips will praise you.  (Psalm 63:3)

Debain 9 dhclient or network problem

[Franz Angeli]

Hi,

i have a problem with dhclient:

for example interface name eno52 (tg3, Broadcom Limited NetXtreme
BCM5719 Gigabit Ethernet PCIe (rev 01) :

root@:~# dhclient eno52 -v
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eno52/3c:a8:2a:e7:87:bf
Sending on   LPF/eno52/3c:a8:2a:e7:87:bf
Sending on   Socket/fallback
DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 15
DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 16
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

tcpdump during dhclient doesn't show anything?!?

root@*:~# tcpdump -i eno52
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno52, link-type EN10MB (Ethernet), capture size 262144 bytes


root@***:~# ip addr show eno52
9: eno52: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state
DOWN group default qlen 1000
link/ether 3c:a8:2a:e7:87:bf brd ff:ff:ff:ff:ff:ff

interface eno52 seems to be disconnected but cable is plugged and
working (i tried with other pc)

obviously ethernet cable is connected...
Debian 8 works fine with this hw
Debian 9 doesn't work

Server is ProLiant DL380 Gen9 (719064-B21)

root@***:~# lspci -v | grep -A10 Ethernet
02:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM5719
Gigabit Ethernet PCIe (rev 01)
Subsystem: Hewlett-Packard Company Ethernet 1Gb 4-port 331i Adapter
Flags: bus master, fast devsel, latency 0, IRQ 16, NUMA node 0
Memory at 92c9 (64-bit, prefetchable) [size=64K]
Memory at 92ca (64-bit, prefetchable) [size=64K]
Memory at 92cb (64-bit, prefetchable) [size=64K]
[virtual] Expansion ROM at 9310 [disabled] [size=256K]
Capabilities: [48] Power Management version 3
Capabilities: [50] Vital Product Data
Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
Capabilities: [a0] MSI-X: Enable+ Count=17 Masked-
Capabilities: [ac] Express Endpoint, MSI 00
--
02:00.1 Ethernet controller: Broadcom Limited NetXtreme BCM5719
Gigabit Ethernet PCIe (rev 01)
Subsystem: Hewlett-Packard Company Ethernet 1Gb 4-port 331i Adapter
Flags: bus master, fast devsel, latency 0, IRQ 17, NUMA node 0
Memory at 92c6 (64-bit, prefetchable) [size=64K]
Memory at 92c7 (64-bit, prefetchable) [size=64K]
Memory at 92c8 (64-bit, prefetchable) [size=64K]
[virtual] Expansion ROM at 9314 [disabled] [size=256K]
Capabilities: [48] Power Management version 3
Capabilities: [50] Vital Product Data
Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
Capabilities: [a0] MSI-X: Enable- Count=17 Masked-
Capabilities: [ac] Express Endpoint, MSI 00
--
02:00.2 Ethernet controller: Broadcom Limited NetXtreme BCM5719
Gigabit Ethernet PCIe (rev 01)
Subsystem: Hewlett-Packard Company Ethernet 1Gb 4-port 331i Adapter
Flags: bus master, fast devsel, latency 0, IRQ 16, NUMA node 0
Memory at 92c3 (64-bit, prefetchable) [size=64K]
Memory at 92c4 (64-bit, prefetchable) [size=64K]
Memory at 92c5 (64-bit, prefetchable) [size=64K]
[virtual] Expansion ROM at 9318 [disabled] [size=256K]
Capabilities: [48] Power Management version 3
Capabilities: [50] Vital Product Data
Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
Capabilities: [a0] MSI-X: Enable- Count=17 Masked-
Capabilities: [ac] Express Endpoint, MSI 00
--
02:00.3 Ethernet controller: Broadcom Limited NetXtreme BCM5719
Gigabit Ethernet PCIe (rev 01)
Subsystem: Hewlett-Packard Company Ethernet 1Gb 4-port 331i Adapter
Flags: bus master, fast devsel, latency 0, IRQ 17, NUMA node 0
Memory at 92c0 (64-bit, prefetchable) [size=64K]
Memory at 92c1 (64-bit, prefetchable) [size=64K]
Memory at 92c2 (64-bit, prefetchable) [size=64K]
[virtual] Expansion ROM at 931c [disabled] [size=256K]
Capabilities: [48] Power Management version 3
Capabilities: [50] Vital Product Data
Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
Capabilities: [a0] MSI-X: Enable- Count=17 Masked-
Capabilities: [ac] Express Endpoint, MSI 00
--
04:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM5719
Gigabit Ethernet PCIe (rev 01)
Subsystem: Hewlett-Packard Company Ethernet 1Gb 4-port 331FLR Adapter
Flags: bus master, fast devsel, latency 0, IRQ 16, NUMA node 0
Memory at 92b9 (64-bit, prefetchable) [size=64K]
Memory at 92ba (64-bit, prefetchable) [size=64K]
Memory at 92bb (64-bit, prefetchable) [size=64K]
[virtual] Expansion ROM at 9300 [disabled] [size=256K]
Capabilities: [48] Power Management version 3
Capabilities: [50] Vital Product Data
Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
Capabilities: [a0] MSI-X: Enable- Co

Re: dhclient or network problem

[Dejan Jocic]

On 10-07-17, Franz Angeli wrote:
> Hi,
> 
> i have a problem with dhclient:
> 
> for example interface name eno52 (tg3, Broadcom Limited NetXtreme
> BCM5719 Gigabit Ethernet PCIe (rev 01) :
> 
> root@:~# dhclient eno52 -v
> Internet Systems Consortium DHCP Client 4.3.5
> Copyright 2004-2016 Internet Systems Consortium.
> All rights reserved.
> For info, please visit https://www.isc.org/software/dhcp/
> 
> Listening on LPF/eno52/3c:a8:2a:e7:87:bf
> Sending on   LPF/eno52/3c:a8:2a:e7:87:bf
> Sending on   Socket/fallback
> DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 4
> DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 10
> DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 7
> DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 9
> DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 15
> DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 16
> No DHCPOFFERS received.
> No working leases in persistent database - sleeping.
> 
> tcpdump during dhclient doesn't show anything?!?
> 
> root@*:~# tcpdump -i eno52
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eno52, link-type EN10MB (Ethernet), capture size 262144 bytes
> 
> 
> root@***:~# ip addr show eno52
> 9: eno52: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state
> DOWN group default qlen 1000
> link/ether 3c:a8:2a:e7:87:bf brd ff:ff:ff:ff:ff:ff
> 
> 
> if i use the same ethernet cable on my laptop all works fine...

Don't you think that you have enough of a clue there :P That eno52 is,
as you can see ethernet card, of course it will work when you connect it
with ethernet cable. If you want it to work with wifi, that is another
story. What is your wifi card, do you have something starting with w in
the output of ip addr show? What is the output of the lspci -v | grep -i
-A6 net?
> 
> i don't know if is a module problem...or?
> 
> Can you help me?
> 
> BR
> 

dhclient or network problem

[Franz Angeli]

Hi,

i have a problem with dhclient:

for example interface name eno52 (tg3, Broadcom Limited NetXtreme
BCM5719 Gigabit Ethernet PCIe (rev 01) :

root@:~# dhclient eno52 -v
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eno52/3c:a8:2a:e7:87:bf
Sending on   LPF/eno52/3c:a8:2a:e7:87:bf
Sending on   Socket/fallback
DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 15
DHCPDISCOVER on eno52 to 255.255.255.255 port 67 interval 16
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

tcpdump during dhclient doesn't show anything?!?

root@*:~# tcpdump -i eno52
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno52, link-type EN10MB (Ethernet), capture size 262144 bytes


root@***:~# ip addr show eno52
9: eno52: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state
DOWN group default qlen 1000
link/ether 3c:a8:2a:e7:87:bf brd ff:ff:ff:ff:ff:ff


if i use the same ethernet cable on my laptop all works fine...

i don't know if is a module problem...or?

Can you help me?

BR

Re: Why 2 dhclient processes running for eth0 (IPv4)?

[Clark Wang]

2017-03-08 15:24 GMT+08:00 Clark Wang <dearv...@gmail.com>:

> See following output from my system (Debian 8.6):
>
> root@debian:~# cat /etc/debian_version
> 8.6
> root@debian:~# pgrep -af dhc
> 506 dhclient -v -pf /run/dhclient.eth1.pid -lf
> /var/lib/dhcp/dhclient.eth1.leases eth1
> 447 dhclient -v -pf /run/dhclient.eth0.pid -lf
> /var/lib/dhcp/dhclient.eth0.leases eth0
> 601 dhclient -v -pf /run/dhclient.eth0.pid -lf
> /var/lib/dhcp/dhclient.eth0.leases eth0
> 664 dhclient -6 -pf /run/dhclient6.eth0.pid -lf
> /var/lib/dhcp/dhclient6.eth0.leases eth0
> root@debian:~# grep -n -C3 eth0 /etc/network/interfaces
>  7-auto lo
>  8-iface lo inet loopback
>  9-
> 10:allow-hotplug eth0
> 11:iface eth0 inet dhcp
> 12:iface eth0 inet6 dhcp
> 13-accept_ra 1
>     14-
> 15-allow-hotplug eth1
> root@debian:~#
>
> There are 2 `dhclient` processes running for `eth0` (IPv4). Rebooting does
> not help for me.
>

Thanks all for pointing me to the debug direction.

I moved /sbin/dhclient to /sbin/dhclient.bin and rewrite /sbin/dhclient as
a shell script which would call /sbin/dhclient.bin and prints some proc
hierarchy info. It turned out both /etc/init.d/networking and systemd would
call ifup. See following example (only for IPv4):

 Sun Mar 12 21:38:08 PDT 2017 
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
root   433  0.0  1.1  20052  2880 ?S21:38   0:00 /bin/bash
/sbin/dhclient -v -pf /run/dhclient.eth0.pid -lf
/var/lib/dhcp/dhclient.eth0.leases eth0
systemd(1)-+-networking(285)---ifup(427)---sh(432)---dhclient(433)---pstree(441)
   |-systemd-journal(160)
   `-systemd-udevd(164)-+-systemd-udevd(167)
|-systemd-udevd(171)
|-systemd-udevd(172)
|-systemd-udevd(173)
|-systemd-udevd(174)
|-systemd-udevd(175)
|-systemd-udevd(176)
|-systemd-udevd(177)
|-systemd-udevd(178)
`-systemd-udevd(179)

 Sun Mar 12 21:38:10 PDT 2017 
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
root   518  0.0  1.1  20052  2920 ?S21:38   0:00 /bin/bash
/sbin/dhclient -v -pf /run/dhclient.eth0.pid -lf
/var/lib/dhcp/dhclient.eth0.leases eth0
systemd(1)-+-dhclient.bin(457)
   |-ifup(509)---sh(517)---dhclient(518)---pstree(522)
   |-nfs-common(512)---nfs-common(523)
   |-systemd-journal(160)
   `-systemd-udevd(164)-+-systemd-udevd(167)
|-systemd-udevd(171)
|-systemd-udevd(172)
|-systemd-udevd(173)
|-systemd-udevd(174)
|-systemd-udevd(175)
|-systemd-udevd(176)
|-systemd-udevd(177)
|-systemd-udevd(178)
`-systemd-udevd(179)

I know nothing about systemd so I disabled the "networking" service with
"sysv-rc-conf" but then network would not be up after reboot. So how can I
make sure only "systemd" or the "networking" service would bring network up?

-clark

Re: Why 2 dhclient processes running for eth0 (IPv4)?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Mar 10, 2017 at 08:31:10AM -0500, Greg Wooledge wrote:
> On Fri, Mar 10, 2017 at 12:34:34PM +0100, to...@tuxteam.de wrote:
> > Also, more "w" in the ps:
> > 
> >   ps auxf | less
> 
> >From ps(1):
> 
>w  Wide output.  Use this option twice for unlimited width.
> 
> You never need more than two.

Habit acquired back then (really back then, you don't want to know :)

Old habits die hard. Thanks for the clarification.

- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAljCq34ACgkQBcgs9XrR2kYX0gCfYtvu+UDzEmro57CuGrtacPBj
rMoAn278Opk262O2olQioUz0D51BfjQC
=63C5
-END PGP SIGNATURE-

Re: Why 2 dhclient processes running for eth0 (IPv4)?

[Greg Wooledge]

On Fri, Mar 10, 2017 at 12:34:34PM +0100, to...@tuxteam.de wrote:
> Also, more "w" in the ps:
> 
>   ps auxf | less

>From ps(1):

   w  Wide output.  Use this option twice for unlimited width.

You never need more than two.

Re: Why 2 dhclient processes running for eth0 (IPv4)?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Mar 10, 2017 at 01:23:36PM +, Jonathan Dowland wrote:
> On Fri, Mar 10, 2017 at 06:58:30PM +0800, Clark Wang wrote:
> > > There are 2 `dhclient` processes running for `eth0` (IPv4). Rebooting does
> > > not help for me.
> > >
> > 
> > Anyone else has the same problem?
> 
> I think I have sometimes seen this, but I do not know what provokes it. The 
> most
> likely explanation is installing more than one network management system 
> and/or
> leaving more than one configured. So for example I have had ifupdown and wicd 
> both
> attempt to manage interfaces.
> 
> If you look at the parent PID for the dhclient instances, you might get some 
> clues.
> (ps -eaf --forest for example, or pstree(1))

I was tempted to propose that too, but mine daemonizes and becomes
init's child (ifupdown, don't know what other network managers do).

Regards
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAljCqZwACgkQBcgs9XrR2kYLlACfWY3HLojGwlC9Wsa2+TnUzjVW
micAn3mgTQaOTBfpp3NqZ/vFkZUTQ77A
=bPJL
-END PGP SIGNATURE-

Re: Why 2 dhclient processes running for eth0 (IPv4)?

[Jonathan Dowland]

On Fri, Mar 10, 2017 at 06:58:30PM +0800, Clark Wang wrote:
> > There are 2 `dhclient` processes running for `eth0` (IPv4). Rebooting does
> > not help for me.
> >
> 
> Anyone else has the same problem?

I think I have sometimes seen this, but I do not know what provokes it. The most
likely explanation is installing more than one network management system and/or
leaving more than one configured. So for example I have had ifupdown and wicd 
both
attempt to manage interfaces.

If you look at the parent PID for the dhclient instances, you might get some 
clues.
(ps -eaf --forest for example, or pstree(1))


-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.


signature.asc
Description: Digital signature

Re: Why 2 dhclient processes running for eth0 (IPv4)?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Mar 10, 2017 at 06:58:30PM +0800, Clark Wang wrote:

[...]

> Anyone else has the same problem?

No. At least not if I don't provoke it :-)

You could gather some hints by looking into /var/log/daemon.log (dhclient's
mumblings are there) and/or by having a look at /proc/<dhclient's PID>/fd.

Also, more "w" in the ps:

  ps auxf | less

then search for dhclient. wider command line, parent-child relationships as
additional hints.

Good luck
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAljCj0oACgkQBcgs9XrR2kZARQCfTjU7tYxFBy3NK8MO8z1+JLmK
QsoAn3wdX5JTDdbN/vAB6UZB13wmVp9l
=79a+
-END PGP SIGNATURE-

Re: Why 2 dhclient processes running for eth0 (IPv4)?

[Clark Wang]

2017-03-08 15:24 GMT+08:00 Clark Wang <dearv...@gmail.com>:

> See following output from my system (Debian 8.6):
>
> root@debian:~# cat /etc/debian_version
> 8.6
> root@debian:~# pgrep -af dhc
> 506 dhclient -v -pf /run/dhclient.eth1.pid -lf
> /var/lib/dhcp/dhclient.eth1.leases eth1
> 447 dhclient -v -pf /run/dhclient.eth0.pid -lf
> /var/lib/dhcp/dhclient.eth0.leases eth0
> 601 dhclient -v -pf /run/dhclient.eth0.pid -lf
> /var/lib/dhcp/dhclient.eth0.leases eth0
> 664 dhclient -6 -pf /run/dhclient6.eth0.pid -lf
> /var/lib/dhcp/dhclient6.eth0.leases eth0
> root@debian:~# grep -n -C3 eth0 /etc/network/interfaces
>  7-auto lo
>  8-iface lo inet loopback
>  9-
> 10:allow-hotplug eth0
> 11:iface eth0 inet dhcp
> 12:iface eth0 inet6 dhcp
> 13-accept_ra 1
>     14-
> 15-allow-hotplug eth1
> root@debian:~#
>
> There are 2 `dhclient` processes running for `eth0` (IPv4). Rebooting does
> not help for me.
>

Anyone else has the same problem?

[solved] Re: How to disable dhclient to control the interfaces with NetworkManager?

[Farhad Mohammadi Majd]

On Thu, 9 Mar 2017 13:51:40 +, Jonathan Dowland wrote:

> Edit /etc/network/interfaces and comment out the lines corresponding to
> your network interface, e.g. 'auto eth0', 'iface eth0 inet dhcp', etc.

Thank you, I did this work at last night and this morning when I turn on
my computer, the problem was solved.

Re: How to disable dhclient to control the interfaces with NetworkManager?

[Jonathan Dowland]

On Thu, Mar 09, 2017 at 09:26:40AM -0500, Henning Follmann wrote:
> Any interface defined in the /etc/network/interfaces is by default ignored
> by the NetwokManager. 
> So you have to make the decision how to manage your interface. By removing
> it from that file, NetworkManager takes over control again. However by
> default the NetworkManager also connects the interface if it is plugged in.
> It will try to assign the ip address through dhcp. If you do not want that
> you have to define a new profile and assign that to the interface.

That was my understanding of OP's desire: to have NetworkManager handle the
interface, and do what it does.

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.


signature.asc
Description: Digital signature

Re: How to disable dhclient to control the interfaces with NetworkManager?

[Henning Follmann]

On Thu, Mar 09, 2017 at 01:51:40PM +, Jonathan Dowland wrote:
> On Thu, Mar 09, 2017 at 04:44:34PM +0330, Farhad Mohammadi Majd wrote:
> > Hello, I did install Debian GNU/Linux v8.7 through NetInstall option,
> > during installation I did not select any Desktop Environment for install
> > on system, only `standard utilities', after finish the installation, I
> > did use `aptitude' to install xorg, gnome-shell, gnome-session and some
> > parts of GNOME without recomended packages.
> > 
> > Now anytime on system booting, dhclient automatically connects the
> > interface to network and I just know to use `ifdown' by root user to
> > turn off the interface.
> > 
> > I want to disable dhclient to control the interface with NetworkManager
> > by regular user.
> > 
> > How is this possible?
> 
> Edit /etc/network/interfaces and comment out the lines corresponding to
> your network interface, e.g. 'auto eth0', 'iface eth0 inet dhcp', etc.
> then restart NetworkManager (systemctl restart NetworkManager.service)
> 


Any interface defined in the /etc/network/interfaces is by default ignored
by the NetwokManager. 
So you have to make the decision how to manage your interface. By removing
it from that file, NetworkManager takes over control again. However by
default the NetworkManager also connects the interface if it is plugged in.
It will try to assign the ip address through dhcp. If you do not want that
you have to define a new profile and assign that to the interface.


-H



-- 
Henning Follmann   | hfollm...@itcfollmann.com

Re: How to disable dhclient to control the interfaces with NetworkManager?

[Jonathan Dowland]

On Thu, Mar 09, 2017 at 04:44:34PM +0330, Farhad Mohammadi Majd wrote:
> Hello, I did install Debian GNU/Linux v8.7 through NetInstall option,
> during installation I did not select any Desktop Environment for install
> on system, only `standard utilities', after finish the installation, I
> did use `aptitude' to install xorg, gnome-shell, gnome-session and some
> parts of GNOME without recomended packages.
> 
> Now anytime on system booting, dhclient automatically connects the
> interface to network and I just know to use `ifdown' by root user to
> turn off the interface.
> 
> I want to disable dhclient to control the interface with NetworkManager
> by regular user.
> 
> How is this possible?

Edit /etc/network/interfaces and comment out the lines corresponding to
your network interface, e.g. 'auto eth0', 'iface eth0 inet dhcp', etc.
then restart NetworkManager (systemctl restart NetworkManager.service)

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.


signature.asc
Description: Digital signature

Re: How to disable dhclient to control the interfaces with NetworkManager?

[Joe]

On Thu, 09 Mar 2017 16:44:34 +0330
Farhad Mohammadi Majd <farhadbenya...@yahoo.com> wrote:

> Hello, I did install Debian GNU/Linux v8.7 through NetInstall option,
> during installation I did not select any Desktop Environment for
> install on system, only `standard utilities', after finish the
> installation, I did use `aptitude' to install xorg, gnome-shell,
> gnome-session and some parts of GNOME without recomended packages.
> 
> Now anytime on system booting, dhclient automatically connects the
> interface to network and I just know to use `ifdown' by root user to
> turn off the interface.
> 
> I want to disable dhclient to control the interface with
> NetworkManager by regular user.
> 
> How is this possible?
> 
> Sorry for my bad english; Thanks for help.
> 

If Network Manager is installed, it should also be managing any wired
connections. Dhcpclient should not be overriding NM.

I don't have an NM installation to hand at the moment, but it is
possible to edit the properties of any interface to connect
automatically or not. Try left- or right-clicking the network icon and
there should be an entry for configuration. It's a long time since I
used it last.

I recall having several fixed IP addresses that I wanted to switch a
laptop between to troubleshoot a network, and any number of
configurations can be created and called by name. All were set to
manual connection.

-- 
Joe

Why 2 dhclient processes running for eth0 (IPv4)?

[Clark Wang]

See following output from my system (Debian 8.6):

root@debian:~# cat /etc/debian_version
8.6
root@debian:~# pgrep -af dhc
506 dhclient -v -pf /run/dhclient.eth1.pid -lf
/var/lib/dhcp/dhclient.eth1.leases eth1
447 dhclient -v -pf /run/dhclient.eth0.pid -lf
/var/lib/dhcp/dhclient.eth0.leases eth0
601 dhclient -v -pf /run/dhclient.eth0.pid -lf
/var/lib/dhcp/dhclient.eth0.leases eth0
664 dhclient -6 -pf /run/dhclient6.eth0.pid -lf
/var/lib/dhcp/dhclient6.eth0.leases eth0
root@debian:~# grep -n -C3 eth0 /etc/network/interfaces
 7-auto lo
 8-iface lo inet loopback
 9-
10:allow-hotplug eth0
11:iface eth0 inet dhcp
12:iface eth0 inet6 dhcp
13-accept_ra 1
14-
15-allow-hotplug eth1
root@debian:~#

There are 2 `dhclient` processes running for `eth0` (IPv4). Rebooting does
not help for me.

Thanks.

Re: Re: Debian jessie: DHCP v6 in interfaces does not start dhclient

[gustav Spellauge]

in my case 2 seconds were not enough - had to increase to 5 on one 
machine and to 10 on another (slower) one.


is this issue fixed in stretch/sid?

Re: Re-exec dhclient without stopping network?

[Richard Hector]

On 24/02/16 22:13, Reco wrote:
> ...
> pkill -9 -f dhclient
> ifup --force eth0
> sleep 1800
> reboot
> 
> If all goes well you would be able to re-attach to a existing screen
> session, and cancel the reboot.
> If anything goes wrong - you'll have your host alive and kicking after
> 30 minutes of waiting.

Cheers - given it's not my machine, I think I'll just wait till I can go
in, hopefully tomorrow :-)

Thanks,
Richard

Re: Re-exec dhclient without stopping network?

[Reco]

Hi.

On Wed, Feb 24, 2016 at 08:54:50PM +1300, Richard Hector wrote:
> Anyone know if/how I can restart dhclient without stopping the network?
> 
> It's the only process left holding open the old libc after the
> upgrade, and I'd rather avoid restarting the network (or rebooting),
> since I'm working remotely.
> 
> This is on a wheezy box. It shouldn't be using dhcp, really, but
> that's an issue for another day ...

Short version (assuming that you're using stock isc-dhcp-client and your
network interface is called eth0):

pkill -9 -f dhclient
ifup --force eth0


Long version:

Sending a SIGKILL to dhclient will force it to terminate, but won't
leave it time to deconfigure a network interface. Hence your network
interface configuration should be leaved as is.

Forcing a network interface into UP state with ifupdown(1) will launch a
fresh version of dhclient, which should try to reuse existing lease file
at /var/lib/dhcp/dhclient.eth0.leases. And by reusing said lease file
dhclient should ask DHCP server for the same client IP.


Of course, if you're trying to do it over a network connection, it would
be a good idea to do the whole sequence in a screen(1) (or tmux), and to
add a timed reboot just in case. I.e:

pkill -9 -f dhclient
ifup --force eth0
sleep 1800
reboot

If all goes well you would be able to re-attach to a existing screen
session, and cancel the reboot.
If anything goes wrong - you'll have your host alive and kicking after
30 minutes of waiting.

Reco

Re-exec dhclient without stopping network?

[Richard Hector]

Anyone know if/how I can restart dhclient without stopping the network?

It's the only process left holding open the old libc after the
upgrade, and I'd rather avoid restarting the network (or rebooting),
since I'm working remotely.

This is on a wheezy box. It shouldn't be using dhcp, really, but
that's an issue for another day ...

Richard

Re: câble non branché au démarrage mais dhclient s'exécute

[Pascal Hambourg]

Prego Jérémy a écrit :
> 
> je suis sous debian jessie noyau 4.2.0. Lorsque je démarre mon 
> ordinateur sans câble branché sur eth0 j'ai  dhclient qui cherche un 
> dhcp en permanence ce qui me pose un petit problème.
> 
> je précise que je n'ai pas de gestionnaire de connection graphique
> 
> un ethtool eth0 me donne bien: Link detected: no
> 
> et mon fichier /etc/network/interfaces concernant eth0
> 
> allow-hotplug eth0
> iface eth0 inet dhcp

Fonctionnement normal (je n'ai pas écrit "souhaitable") d'ifupdown.
"hotplug" fait référence à la présence de l'interface, pas de la
liaison. Et malheureusement, dhclient ne semble pas se préoccuper de
l'état de la liaison non plus.

Voir ifplugd comme conseillé.

Re: câble non branché au démarrage mais dhclient s'exécute

[Sylvain L. Sauvage]

Le samedi 17 octobre 2015, 11:18:42 Pascal Hambourg a écrit :
>[…]
> Voir ifplugd comme conseillé.

  Voir aussi systemd-networkd (attention : il remplace aussi 
ifupdown et dhclient (et il fait le café…)).

-- 
 Sylvain Sauvage

Re: câble non branché au démarrage mais dhclient s'exécute

[Prego Jérémy]

Le 17/10/2015 12:05, Sylvain L. Sauvage a écrit :

Le samedi 17 octobre 2015, 11:18:42 Pascal Hambourg a écrit :

[…]
Voir ifplugd comme conseillé.

je vais tester la solution je viens d'installer le paquet.

   Voir aussi systemd-networkd (attention : il remplace aussi
ifupdown et dhclient (et il fait le café…)).


systemd ? surtout pas, je suis revenu asysvinit pour mon system d'init.

merci pour vos réponses

jerem

câble non branché au démarrage mais dhclient s'exécute

[Prego Jérémy]

bonjour,

je suis sous debian jessie noyau 4.2.0. Lorsque je démarre mon 
ordinateur sans câble branché sur eth0 j'ai  dhclient qui cherche un 
dhcp en permanence ce qui me pose un petit problème.


je précise que je n'ai pas de gestionnaire de connection graphique

un ethtool eth0 me donne bien: Link detected: no

et mon fichier /etc/network/interfaces concernant eth0

allow-hotplug eth0
iface eth0 inet dhcp

donc je pense que tout es bon mais pas pour lui visiblement ...


merci,

jerem.

Re: câble non branché au démarrage mais dhclient s'exécute

[Alexandre Hoïde]

On Fri, Oct 16, 2015 at 11:38:45PM +0200, Prego Jérémy wrote:
> bonjour,
  'Lo,
> je suis sous debian jessie noyau 4.2.0. Lorsque je démarre mon ordinateur
> sans câble branché sur eth0 j'ai  dhclient qui cherche un dhcp en permanence
> ce qui me pose un petit problème.
> 
> je précise que je n'ai pas de gestionnaire de connection graphique
> 
> un ethtool eth0 me donne bien: Link detected: no
> 
> et mon fichier /etc/network/interfaces concernant eth0
> 
> allow-hotplug eth0
> iface eth0 inet dhcp
> 
> donc je pense que tout es bon mais pas pour lui visiblement ...

  Peut-être devrais-tu installer le paquet « ifplugd » :

« ifplugd is a daemon which will automatically configure your ethernet
device when a cable is plugged in and automatically de-configure it if
the cable is pulled out. This is useful on laptops with onboard network
adapters, since it will only configure the interface when a cable is
really connected »
  
  (J'ai la flemme de traduire)

  Sinon, essayer de bidouiller la valeur de 'timeout' dans
/etc/dhcp/dhclient.conf ? (pas sûr que ça suffise).

> merci,
  Je t'en prie

-- 
 ___
| $ post_tenebras ↲ |   waouh !
| GNU\ /|  /
|  -- * --  | o
| $ who ↲/ \|_-- ~_|
| Alexandre Hoïde   |  _/| |
 ---

[Bug] Dhclient gets hostname correctly on 64-bit Debian 8.0, but not on 32-bit

[Nicolas Kovacs]

Hi,

I've had some weird problems with central hostname management. After a
week of pulling out my hair, I can say definitely that I've found a bug.

I'm fiddling with two different Debian sandbox PC's. They don't have any
'hardcoded' hostname definition, only 'localhost' in /etc/hostname and
'localhost.localdomain' in /etc/hosts. They should get their hostname
(FQDN) on boot time from the local Dnsmasq server.

The two boxes only have a minimal Debian install. No X, no GUI, only an
SSH server.

On the 64-bit machine, everything happens as expected, and 'hostname' as
well as 'hostname --fqdn' return the correct values.

On the 32-bit machine, I only get 'localhost' and 'localdomain'.

The thing is: the hostname *sometimes* (!!!) gets sent to the 32-bit
Debian client. But more often than not, it fails.

Maybe the devs can look into this.

Cheers,

Niki Kovacs
-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Web  : http://www.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55a682fc.8000...@microlinux.fr

Re: Debian jessie: DHCP v6 in interfaces does not start dhclient

[Stefan Pietsch]

* Stefan Pietsch stefan.piet...@lsexperts.de [2015-04-29 10:50]:
 Dear list,
 
 a fresh installation of Debian jessie does not start dhclient for IPv6
 at boot.
 
 This is the interfaces file:
 
 ~
 
 source /etc/network/interfaces.d/*
 
 auto lo
 iface lo inet loopback
 
 auto eth0
 iface eth0 inet dhcp
 iface eth0 inet6 dhcp
 
 ~
 
 
 Doing a manual ifup eth0 after boot starts dhclient -6.
 
 Can anyone confirm this behaviour?


This is a timing issue.



auto eth0
iface eth0 inet dhcp
post-up sleep 2
iface eth0 inet6 dhcp



The sleep in post-up is a workaround and dhclient for v6 starts correctly.

Ubuntu 15.04 is also affected:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1447715



Regards,
Stefan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150504111731.fvz1nzbxyyglfmjvxlg...@consulting.lsexperts.de

Debian jessie: DHCP v6 in interfaces does not start dhclient

[Stefan Pietsch]

Dear list,

a fresh installation of Debian jessie does not start dhclient for IPv6
at boot.

This is the interfaces file:

~

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
iface eth0 inet6 dhcp

~


Doing a manual ifup eth0 after boot starts dhclient -6.

Can anyone confirm this behaviour?


Regards,
Stefan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150429104502.pl6k0xp4cnob0qnfiwz...@consulting.lsexperts.de

script bash et retour commande dhclient

[Prego Jérémy]

bonjour, sous une debian jessie, je n'arrive pas a trouver le moyen de 
savoir si un dhclient c'est bien ou mal fini. en effet, le code de 
retour de la commande dhclient $interface reste a 0 et l'ancienne 
adresse ip reste afficher dans ifconfig. comment savoir si un dhclient 
c'est bien ou mal exécuté dans un script ? (sous entendu si il a eu une 
adresse ip ou non). merci d'avance, jerem



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/55262fc4.1060...@prego-network.net

Re: script bash et retour commande dhclient

[Guillaume]

Bonjour,

Peut être regarder du côté des logs (syslog).

Sinon dhclient possède un mode verbeux (-v).

Le 09/04/2015 09:52, Prego Jérémy a écrit :
bonjour, sous une debian jessie, je n'arrive pas a trouver le moyen de 
savoir si un dhclient c'est bien ou mal fini. en effet, le code de 
retour de la commande dhclient $interface reste a 0 et l'ancienne 
adresse ip reste afficher dans ifconfig. comment savoir si un dhclient 
c'est bien ou mal exécuté dans un script ? (sous entendu si il a eu 
une adresse ip ou non). merci d'avance, jerem






--
Guillaume

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/552642f8.6080...@gwilhom.fr

Re: script bash et retour commande dhclient

[Prego Jérémy]

bonjour,
j'ai bien pensé a cette solution, mais pour un script, c'est pas très 
optimal et voulant l'éviter, je venais voir si il y avai pas un remède 
miracle...


jerem

Le 09/04/2015 11:14, Guillaume a écrit :

Bonjour,

Peut être regarder du côté des logs (syslog).

Sinon dhclient possède un mode verbeux (-v).

Le 09/04/2015 09:52, Prego Jérémy a écrit :
bonjour, sous une debian jessie, je n'arrive pas a trouver le moyen 
de savoir si un dhclient c'est bien ou mal fini. en effet, le code de 
retour de la commande dhclient $interface reste a 0 et l'ancienne 
adresse ip reste afficher dans ifconfig. comment savoir si un 
dhclient c'est bien ou mal exécuté dans un script ? (sous entendu si 
il a eu une adresse ip ou non). merci d'avance, jerem








--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/55264a4e.4010...@prego-network.net