Re: dhclient/autoconf in singleuser vs. ramdisk kernel

[Theo de Raadt]

Erling Westenvik  wrote:

> Hi,
> 
> When booting bsd.rd I can do:
> 
> # ifconfig  inet autoconf
> 
> and it will negotiate a working IP and gateway setup from my DHCP
> server.
> 
> However, when booting 'boot -s' (singleuser) the only way to have a
> working IP and gateway setup is to specify it manually by entering the
> specific relevant values, like:
> 
> # ifconfig  12.34.56.78 0xff00
> # route add default 12.34.56.1
> 
> Neither 'dhclient ' or 'ifconfig  inet autoconf' works.
> 
> What am I missing?

dhcpleased is not running.

Re: dhclient -d run0

[Stuart Henderson]

On 2022-12-22, Geoff Steckel  wrote:
> Are routes and resolv.conf the only things dhcpleased modifies beyond 
> configuring the interface with the leased IP?

dhcpleased only sets IP/mask and routes, and sends a nameserver proposal
on the route socket, which resolvd picks up if running.

IP/mask/DNS comes from the DHCP negotiation, routes are added based on
routers or classless-static-routes from DHCP, plus a cloning route is added
automatically if needed to reach an out-of-subnet gateway.

There's no setting of ntp server, etc.

The code is really readable and logically laid out if you want to check
anything else about what it does.

Re: dhclient -d run0

[Bodie]

On Fri Dec 23, 2022 at 1:23 AM CET, Geoff Steckel wrote:
> My objection to dhcpleased is not whether the program does useful things.
> I'm sure it does "what it should".
>
> Adding this sentence to the dhcpleased man page would make
> it clear what it does beyond leasing the IP:
>
> "By default, it replaces the DNS server in /etc/resolv.conf
> and replaces the default route using information from the DHCP server."
>
> If it does anything else it's a bug in the documentation or
> the program. Examine many, many man pages for the traditional
> suite of Unix programs. They're contracts.
> Surprises in the .conf leave doubts about all the documentation
> and the program itself.

I would suggest to look at least on RFC 3442 as there are things your
dhcp server provider MUST do and you as client can pick what suits
you with options.


>
> Now I'll shut up.
> Geoff Steckel

Re: dhclient -d run0

[Theo de Raadt]

Geoff Steckel  wrote:

> My objection to dhcpleased is not whether the program does useful things.
> I'm sure it does "what it should".
> 
> Adding this sentence to the dhcpleased man page would make
> it clear what it does beyond leasing the IP:
> 
> "By default, it replaces the DNS server in /etc/resolv.conf
> and replaces the default route using information from the DHCP server."

But that would be a lie.

dhcpleased does not touch resolv.conf
 
It does not work like that at all.  resolvd is the program which modifies
/etc/resolv.conf

resolvd documents how it works quite well.   the resolv.conf file does
not really document how it might come to be changed, but shrug.  one
thing that is missing is that dhcpleased and slaacd do not mention they
are re-advertising dns onto the route socket in a way that resolvd can
act upon.


> If it does anything else it's a bug in the documentation or
> the program. Examine many, many man pages for the traditional
> suite of Unix programs. They're contracts.
> Surprises in the .conf leave doubts about all the documentation
> and the program itself.

When you put it that way, I don't feel like changing a single word
in the documentation.

> Now I'll shut up.

Probably wise.

Re: dhclient -d run0

[Geoff Steckel]

My objection to dhcpleased is not whether the program does useful things.
I'm sure it does "what it should".

Adding this sentence to the dhcpleased man page would make
it clear what it does beyond leasing the IP:

"By default, it replaces the DNS server in /etc/resolv.conf
and replaces the default route using information from the DHCP server."

If it does anything else it's a bug in the documentation or
the program. Examine many, many man pages for the traditional
suite of Unix programs. They're contracts.
Surprises in the .conf leave doubts about all the documentation
and the program itself.

Now I'll shut up.
Geoff Steckel

Re: dhclient -d run0

[Bodie]

On 22.12.2022 01:57, Geoff Steckel wrote:

On 12/21/22 09:05, Crystal Kolipe wrote:

On Wed, Dec 21, 2022 at 01:39:47PM +, Rodrigo Readi wrote:
The command "dhclient -d run0" with or without "-d" seems to 
demonize,

always, and is till now completely silent.

Is this new behaviour normal? How I get it the old way?

You might want to look at the commit message for version 1.727 of
dhclient.c:

http://cvsweb.openbsd.org/src/sbin/dhclient/dhclient.c


dhcpleased appears to be a useful & complete replacement
for dhclient for most users

Right now I run dhclient on my gateway machine.
I cut off its fingers when it tries to e.g. mess with routes or 
resolv.conf.
I disable dhcpleased because I don't know -exactly- what it tries to 
do.




dhcpleased.conf(5)

 ignore routes
 Ignore routes from leases on this interface.  The default 
is to

 not ignore routes.

Replacing resolv.conf and configuring routes can be disabled in 
dhcpleased.conf.

Are routes and resolv.conf the only things dhcpleased modifies beyond
configuring
the interface with the leased IP?

For instance, pair of sentences in dhcpleased(8) to the effect:
"dhcpleased inserts the DNS server information
from the DHCP server at the top of the existing /etc/resolv.conf.
It configures the default route via the interface being configured."



Where do you read that? That is no such sentence in either current or
7.2 and 7.1 man pages


Something like that is implied by using DHCP.
Are other routes changed or deleted?
Exactly what does the updated resolv.conf contain?
DHCP can configure other services. Does dhcpleased do any of that?



It's for clients. Replacement for dhclient(8). If you're not client
then you should have your own dhcpd(8) running serving what you need.
Or having static configuration completely.

If you do not like routes or DNS (this one you can alter with undwind(8)
too) from your ISP then you can avoid them with dhcpleased.conf(5)


thanks
Geoff Steckel

Re: dhclient -d run0

[Theo de Raadt]

we were the last operating system to have dynamic resolv.conf
management and then the whiners who had left the operating systems
with dynamic resolv.conf and come here for static resolv.conf
became upset.

i am very sorry they got upset.  not going to change it. after 2-3 years
of small changes, the behaviour is working very well for everyone.  and
if you don't like it, just like all the other systems the are ways to
turn it off.

you don't need to broccoli.  noone is going to smack you in the head
if you push it to the side of your plate.  but if you bring up your dislike
for brocolli everytime you eat, you will collect a negative reaction.

Geoff Steckel  wrote:

> On 12/21/22 09:05, Crystal Kolipe wrote:
> > On Wed, Dec 21, 2022 at 01:39:47PM +, Rodrigo Readi wrote:
> >> The command "dhclient -d run0" with or without "-d" seems to demonize,
> >> always, and is till now completely silent.
> >>
> >> Is this new behaviour normal? How I get it the old way?
> > You might want to look at the commit message for version 1.727 of
> > dhclient.c:
> >
> > http://cvsweb.openbsd.org/src/sbin/dhclient/dhclient.c
> >
> dhcpleased appears to be a useful & complete replacement
> for dhclient for most users
> 
> Right now I run dhclient on my gateway machine.
> I cut off its fingers when it tries to e.g. mess with routes or resolv.conf.
> I disable dhcpleased because I don't know -exactly- what it tries to do.
> 
> Replacing resolv.conf and configuring routes can be disabled in
> dhcpleased.conf.
> Are routes and resolv.conf the only things dhcpleased modifies beyond
> configuring
> the interface with the leased IP?
> 
> For instance, pair of sentences in dhcpleased(8) to the effect:
> "dhcpleased inserts the DNS server information
> from the DHCP server at the top of the existing /etc/resolv.conf.
> It configures the default route via the interface being configured."
> 
> Something like that is implied by using DHCP.
> Are other routes changed or deleted?
> Exactly what does the updated resolv.conf contain?
> DHCP can configure other services. Does dhcpleased do any of that?
> 
> thanks
> Geoff Steckel
> 

Re: dhclient -d run0

[Geoff Steckel]

On 12/21/22 09:05, Crystal Kolipe wrote:

On Wed, Dec 21, 2022 at 01:39:47PM +, Rodrigo Readi wrote:

The command "dhclient -d run0" with or without "-d" seems to demonize,
always, and is till now completely silent.

Is this new behaviour normal? How I get it the old way?

You might want to look at the commit message for version 1.727 of
dhclient.c:

http://cvsweb.openbsd.org/src/sbin/dhclient/dhclient.c


dhcpleased appears to be a useful & complete replacement
for dhclient for most users

Right now I run dhclient on my gateway machine.
I cut off its fingers when it tries to e.g. mess with routes or resolv.conf.
I disable dhcpleased because I don't know -exactly- what it tries to do.

Replacing resolv.conf and configuring routes can be disabled in 
dhcpleased.conf.
Are routes and resolv.conf the only things dhcpleased modifies beyond 
configuring

the interface with the leased IP?

For instance, pair of sentences in dhcpleased(8) to the effect:
"dhcpleased inserts the DNS server information
from the DHCP server at the top of the existing /etc/resolv.conf.
It configures the default route via the interface being configured."

Something like that is implied by using DHCP.
Are other routes changed or deleted?
Exactly what does the updated resolv.conf contain?
DHCP can configure other services. Does dhcpleased do any of that?

thanks
Geoff Steckel

Re: dhclient -d run0

[Florian Obser]

On 2022-12-21 15:04 UTC, Rodrigo Readi  wrote:
> Too much innovations, too much daemons ... :)

Things kinda went downhill after CSRG disbanded.

Re: dhclient -d run0

[Crystal Kolipe]

On Wed, Dec 21, 2022 at 03:04:01PM +, Rodrigo Readi wrote:
> Am Mi., 21. Dez. 2022 um 14:06 Uhr schrieb Crystal Kolipe
> :
> 
> > You might want to look at the commit message for version 1.727 of
> > dhclient.c:
> >
> > http://cvsweb.openbsd.org/src/sbin/dhclient/dhclient.c
> 
> And also /var/log/messages: "dhclient will go away, stop using it".
> 
> Before dhclient I do "ifconfig run0 nwid ... wpakey ... bssid ... up"
> 
> No idea where to park an "auto" there.

For IPv4 you probably want something like:

# ifconfig run0 inet autoconf

If you are using IPv6 you'll also likely want to use:

# ifconfig run0 inet6 autoconf

... and configure slaacd.

> And since I run unbound, I do not like that dhclient/dhcpleased touch
> resolv.conf.

You can disable resolvd and edit resolv.conf manually without any
interference :).

Re: dhclient -d run0

[Rodrigo Readi]

Am Mi., 21. Dez. 2022 um 14:06 Uhr schrieb Crystal Kolipe
:

> You might want to look at the commit message for version 1.727 of
> dhclient.c:
>
> http://cvsweb.openbsd.org/src/sbin/dhclient/dhclient.c

And also /var/log/messages: "dhclient will go away, stop using it".

Before dhclient I do "ifconfig run0 nwid ... wpakey ... bssid ... up"

No idea where to park an "auto" there.
And since I run unbound, I do not like that dhclient/dhcpleased touch
resolv.conf.

Too much innovations, too much daemons ... :)

Re: dhclient -d run0

[Crystal Kolipe]

On Wed, Dec 21, 2022 at 01:39:47PM +, Rodrigo Readi wrote:
> The command "dhclient -d run0" with or without "-d" seems to demonize,
> always, and is till now completely silent.
> 
> Is this new behaviour normal? How I get it the old way?

You might want to look at the commit message for version 1.727 of
dhclient.c:

http://cvsweb.openbsd.org/src/sbin/dhclient/dhclient.c

Re: dhclient on carp

[David Gwynne]

> On 23 Jul 2020, at 22:28, Guy Godfroy  wrote:
> 
> Doesn't work better.
> I guess Sebastian is right, carp has to be assigned an IP to come up.

yeah, i just read the code a bit. they have to be able to communicate to be 
able to elect which one is the active and which is the backup. i suggest using 
an address like one in 169.254.x.y/16 so the carps can elect.

> 
> Le 23/07/2020 à 03:15, David Gwynne a écrit :
>>> On 22 Jul 2020, at 22:59, Guy Godfroy  wrote:
>>> 
>>> Hello,
>>> 
>>> So I read in 6.7 release note that it's finally possible to use dhclient on 
>>> CARP interface. That's great news.
>>> 
>>> However, I'm not sure how to use it on a hostname.if file. I tried to 
>>> replace inet instruction directly with dhcp:
>>> 
>>>dhcp vhid 11 carpdev em1 pass  description "test"
>>> 
>>> 
>>> But that didn't do the trick: at boot time, none of my nodes carp were in 
>>> master state so dhclient didn't manage to get any lease.
>>> 
>>> So I have first to give a static IP to my carp in order to activate it, and 
>>> only then trigger dhcp:
>>> 
>>>inet [...] vhid 11 carpdev em1 pass  description "test"
>>> 
>>>dhcp
>>> 
>>> It doesn't feel right. Is there a better way to do this?
>> hostname.if0 lines don't have to all be address configurations. generally 
>> netstart just passes the statements directly to ifconfig.
>> does something like the following work in hostname.carp0?
>> description "test"
>> vhid 11 carpdev em1 pass 
>> dhcp
>> dlg
> 

Re: dhclient on carp

[Guy Godfroy]

Doesn't work better.
I guess Sebastian is right, carp has to be assigned an IP to come up.

Le 23/07/2020 à 03:15, David Gwynne a écrit :




On 22 Jul 2020, at 22:59, Guy Godfroy  wrote:

Hello,

So I read in 6.7 release note that it's finally possible to use dhclient on 
CARP interface. That's great news.

However, I'm not sure how to use it on a hostname.if file. I tried to replace 
inet instruction directly with dhcp:

dhcp vhid 11 carpdev em1 pass  description "test"


But that didn't do the trick: at boot time, none of my nodes carp were in 
master state so dhclient didn't manage to get any lease.

So I have first to give a static IP to my carp in order to activate it, and 
only then trigger dhcp:

inet [...] vhid 11 carpdev em1 pass  description "test"

dhcp

It doesn't feel right. Is there a better way to do this?


hostname.if0 lines don't have to all be address configurations. generally 
netstart just passes the statements directly to ifconfig.

does something like the following work in hostname.carp0?

description "test"
vhid 11 carpdev em1 pass 
dhcp

dlg

Re: dhclient on carp

[David Gwynne]

> On 22 Jul 2020, at 22:59, Guy Godfroy  wrote:
> 
> Hello,
> 
> So I read in 6.7 release note that it's finally possible to use dhclient on 
> CARP interface. That's great news.
> 
> However, I'm not sure how to use it on a hostname.if file. I tried to replace 
> inet instruction directly with dhcp:
> 
>dhcp vhid 11 carpdev em1 pass  description "test"
> 
> 
> But that didn't do the trick: at boot time, none of my nodes carp were in 
> master state so dhclient didn't manage to get any lease.
> 
> So I have first to give a static IP to my carp in order to activate it, and 
> only then trigger dhcp:
> 
>inet [...] vhid 11 carpdev em1 pass  description "test"
> 
>dhcp
> 
> It doesn't feel right. Is there a better way to do this?

hostname.if0 lines don't have to all be address configurations. generally 
netstart just passes the statements directly to ifconfig.

does something like the following work in hostname.carp0?

description "test"
vhid 11 carpdev em1 pass 
dhcp

dlg

Re: dhclient on carp

[Sebastian Benoit]

Guy Godfroy(guy.godf...@gugod.fr) on 2020.07.22 14:59:53 +0200:
> Hello,
> 
> So I read in 6.7 release note that it's finally possible to use dhclient 
> on CARP interface. That's great news.
> 
> However, I'm not sure how to use it on a hostname.if file. I tried to 
> replace inet instruction directly with dhcp:
> 
> dhcp vhid 11 carpdev em1 pass  description "test"
> 
> 
> But that didn't do the trick: at boot time, none of my nodes carp were 
> in master state so dhclient didn't manage to get any lease.
> 
> So I have first to give a static IP to my carp in order to activate it, 
> and only then trigger dhcp:
> 
> inet [...] vhid 11 carpdev em1 pass  description "test"
> 
> dhcp
> 
> It doesn't feel right. Is there a better way to do this?

Maybe someone will correct me on this, but I don't think so.
carp(4) needs an ip address to come up, thats how the protocol works.

Just pick one, there are many (from rfc1918 private use of course).

Re: dhclient vio0 -> Segmentation fault

[Stuart Henderson]

Update to a newer snapshot.

On 2019-04-06, Matthew Graybosch  wrote:
> On Thu, Apr 4, 2019, at 1:19 AM, Greg Steuck wrote:
>> April 2 snapshot misbehaves badly on Google Compute Engine.
>> 
>> # dmesg | head
>> OpenBSD 6.5 (GENERIC.MP) #839: Tue Apr  2 20:38:19 MDT 2019
>> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>> # dhclient -v -d vio0
>> vio0: DHCPDISCOVER - interval 1
>> vio0: DHCPOFFER from 169.254.169.254 (42:01:0a:80:00:01)
>> Segmentation fault
>> # ls -l /sbin/dhclient
>
> I don't think this is confined to Google Compute Engine. I just upgraded my 
> ThinkPad T430s to the April 2 snapshot, and I have a similar experience when 
> setting up both wired and wireless connections (em0 and iwn0) using DHCP. My 
> dhclient also segfaults after receiving DHCPOFFER from the local Verizon FIOS 
> router. 
>
> Sorry for the lack of dmesg, but I'm typing this from my phone. 
>

Re: dhclient vio0 -> Segmentation fault

[Matthew Graybosch]

On Thu, Apr 4, 2019, at 1:19 AM, Greg Steuck wrote:
> April 2 snapshot misbehaves badly on Google Compute Engine.
> 
> # dmesg | head
> OpenBSD 6.5 (GENERIC.MP) #839: Tue Apr  2 20:38:19 MDT 2019
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> # dhclient -v -d vio0
> vio0: DHCPDISCOVER - interval 1
> vio0: DHCPOFFER from 169.254.169.254 (42:01:0a:80:00:01)
> Segmentation fault
> # ls -l /sbin/dhclient

I don't think this is confined to Google Compute Engine. I just upgraded my 
ThinkPad T430s to the April 2 snapshot, and I have a similar experience when 
setting up both wired and wireless connections (em0 and iwn0) using DHCP. My 
dhclient also segfaults after receiving DHCPOFFER from the local Verizon FIOS 
router. 

Sorry for the lack of dmesg, but I'm typing this from my phone. 

-- 
Matthew Graybosch
https://www.matthewgraybosch.com
"Out of order? Even in the future nothing works."

Re: dhclient release a lease?

[Rob Schmersel]

On Mon, 14 May 2018 19:36:12 -0400
Quartz  wrote:

> > Currently there is no facility in dhclient(8) to issue RELEASE
> > messages. I had no recollection of adding such a thing, and a
> > quick  
> 
> > confirmed there is no DHCPRELEASE related code.  
> 
> Ergh. OK thanks, that's super annoying that it's not there.
> 
> >Which
> > signal(s) are used elsewhere to trigger RELEASE? Goggle is not
> > coughing up an obvious answer. :-)  
> 
> It varies, IIRC on at least on other linux or bsd distro sending HUP 
> took a more literal approach ("hang up and leave") and sent a DHCP 
> release before nuking its lease cache, and I'm pretty sure somewhere 
> else you could send "SIGUSR2" or something.
> 

On Red Hat/Debian  (and derivatives) they use dhclient which has a -r
switch to release the lease. From the man page:

-r Release  the  current  lease and stop the running DHCP client as
previously recorded in the PID file. When shutdown via this method
dhclient-script will be executed with the specific  reason  for
calling the  script set.  The client normally doesn't release the
current lease as this is not required by the DHCP protocol but some
cable ISPs require their clients to notify the server if they wish  to
release an assigned IP address.

Re: dhclient release a lease?

[Quartz]

Currently there is no facility in dhclient(8) to issue RELEASE
messages. I had no recollection of adding such a thing, and a
quick



confirmed there is no DHCPRELEASE related code.


Ergh. OK thanks, that's super annoying that it's not there.


Which
signal(s) are used elsewhere to trigger RELEASE? Goggle is not
coughing up an obvious answer. :-)


It varies, IIRC on at least on other linux or bsd distro sending HUP 
took a more literal approach ("hang up and leave") and sent a DHCP 
release before nuking its lease cache, and I'm pretty sure somewhere 
else you could send "SIGUSR2" or something.

Re: dhclient expects IPv4 address in dhclient.conf

[Marc Peters]

On Thu, May 03, 2018 at 12:05:40PM +0200, Paul de Weerd wrote:
> Stick a v6 recursor in /etc/resolv.conf.tail.  When dhclient updates
> /etc/resolv.conf, it'll append the contents of /etc/resolv.conf.tail
> to it and you will have your v6 resolver availble that way.  You could
> even ignore the v4 nameserver and use your manually configured
> nameservers only.  See resolv.conf(5).
> 
> The only thing I don't think is possible with base tools is having
> your v6 recursor listed *before* the dhcp offered recursor.
> 
> Cheers,
> 
> Paul 'WEiRD' de Weerd

Thank you for your answers. Actually, i would like to keep them as
backup, when doing upgrades or the bind package is not working as
expected. I will take a deeper dive into resolv.conf to have a look. I
thought, that an /etc/resolv.conf.head file would do the trick, but it seems to 
be
ignored on OpenBSD.

Re: dhclient expects IPv4 address in dhclient.conf

[Paul de Weerd]

On Thu, May 03, 2018 at 10:44:18AM +0200, Marc Peters wrote:
| On Thu, May 03, 2018 at 10:31:27AM +0200, Janne Johansson wrote:
| >Since manpage doesn't mention v6 namespace at all, I'd wager you would
| >have to
| >run something else to pick up v6 resolvers.
| 
| Yeah, that's right. Maybe, i stick to v4 resolvers for now or add it by
| hand, when i reboot it.

Stick a v6 recursor in /etc/resolv.conf.tail.  When dhclient updates
/etc/resolv.conf, it'll append the contents of /etc/resolv.conf.tail
to it and you will have your v6 resolver availble that way.  You could
even ignore the v4 nameserver and use your manually configured
nameservers only.  See resolv.conf(5).

The only thing I don't think is possible with base tools is having
your v6 recursor listed *before* the dhcp offered recursor.

Cheers,

Paul 'WEiRD' de Weerd

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/ 

Re: dhclient expects IPv4 address in dhclient.conf

[Marc Peters]

On Thu, May 03, 2018 at 10:31:27AM +0200, Janne Johansson wrote:
>Since manpage doesn't mention v6 namespace at all, I'd wager you would
>have to
>run something else to pick up v6 resolvers.

Yeah, that's right. Maybe, i stick to v4 resolvers for now or add it by
hand, when i reboot it.

Re: dhclient expects IPv4 address in dhclient.conf

[Janne Johansson]

2018-05-02 18:07 GMT+02:00 Marc Peters :

> On Wed, May 02, 2018 at 04:24:50PM +0200, Janne Johansson wrote:
> > Seems common on other dhcpd's too:
> > https://lists.isc.org/pipermail/dhcp-users/2012-May/015511.html
> >
>
> ah, the option has a different name for IPv6 nameservers. Does the base
> dhclient recognize these different options, or do i have to give
> isc-dhcp-client a try for this?
>

Since manpage doesn't mention v6 namespace at all, I'd wager you would have
to
run something else to pick up v6 resolvers.

-- 
May the most significant bit of your life be positive.

Re: dhclient expects IPv4 address in dhclient.conf

[Marc Peters]

On Wed, May 02, 2018 at 04:24:50PM +0200, Janne Johansson wrote:
> Seems common on other dhcpd's too:
> https://lists.isc.org/pipermail/dhcp-users/2012-May/015511.html
> 

ah, the option has a different name for IPv6 nameservers. Does the base
dhclient recognize these different options, or do i have to give
isc-dhcp-client a try for this? 

Re: dhclient expects IPv4 address in dhclient.conf

[Marc Peters]

Am 2. Mai 2018 16:24:50 MESZ schrieb Janne Johansson :
>2018-05-02 16:06 GMT+02:00 Marc Peters :
>
>> Hi misc,
>> dhclient hates me. I would like to prepend an IPv6 nameserver in the
>> dhclient configuration on my router when connecting to my ISP, but
>> dhclient gives me following error:
>>
>> em1: /etc/dhclient.conf line 17: expecting IPv4 address.
>> em1: prepend domain-name-servers "::1"
>> em1: ^
>> dhclient.conf ist plain simple:
>> ~ $ grep -v "#" /etc/dhclient.conf
>>
>> supersede host-name "router";
>>
>> prepend domain-name-servers 127.0.0.1;
>>
>> prepend domain-name-servers "::1";
>>
>> Is this intended?
>>
>>
>Seems common on other dhcpd's too:
>https://lists.isc.org/pipermail/dhcp-users/2012-May/015511.html

This looks like a server issue and fixed in the meantime, otherwise the Windows 
Clients won't get any v6 nameservers, as they don't get it from the RAs.

My issue is with dhclient setting something in /etc/resolve.conf.

-- 
Sent from my cell phone

Re: dhclient expects IPv4 address in dhclient.conf

[Janne Johansson]

2018-05-02 16:06 GMT+02:00 Marc Peters :

> Hi misc,
> dhclient hates me. I would like to prepend an IPv6 nameserver in the
> dhclient configuration on my router when connecting to my ISP, but
> dhclient gives me following error:
>
> em1: /etc/dhclient.conf line 17: expecting IPv4 address.
> em1: prepend domain-name-servers "::1"
> em1: ^
> dhclient.conf ist plain simple:
> ~ $ grep -v "#" /etc/dhclient.conf
>
> supersede host-name "router";
>
> prepend domain-name-servers 127.0.0.1;
>
> prepend domain-name-servers "::1";
>
> Is this intended?
>
>
Seems common on other dhcpd's too:
https://lists.isc.org/pipermail/dhcp-users/2012-May/015511.html


-- 
May the most significant bit of your life be positive.

Re: dhclient not renewing

[Christer Solskogen]

On Sun, Feb 11, 2018 at 5:05 AM, Kenneth R Westerback  wrote:

> Extraneous "bound to ..." messages are no longer logged on renewal.
>
> So the original "bound to ..." message remains valid until something
> changes.
>
> If you look at the leases file you should see it get a new 'epoch' (the
> time
> the lease was obtained) on renewals.
>

The thing is that when dhclient is doing a renew the ip address doesn't
attach to the interface:

em2: flags=8843 mtu 1500
lladdr 00:0d:b9:41:6f:ca
index 3 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (1000baseT full-duplex)
status: active


Remember that this only happens during renew. Running "dhclient em2"
manually works, until the next renew.

This is how /var/db/dhclient.leases.em2 looks like:
lease {
  fixed-address 51.174.196.170;
  next-server 0.0.0.0;
  option subnet-mask 255.255.224.0;
  option routers 51.174.192.1;
  option domain-name-servers 92.220.228.70,109.247.114.4;
  option domain-name "lyse.net";
  option broadcast-address 255.255.255.255;
  option dhcp-lease-time 14400;
  option dhcp-message-type 5;
  option dhcp-server-identifier 51.174.112.1;
  option bootfile-name "213.167.96.135";
  epoch 1518359436;
  renew 0 2018/02/11 16:30:36 UTC;
  rebind 0 2018/02/11 18:00:36 UTC;
  expire 0 2018/02/11 18:30:36 UTC;
}

Re: dhclient not renewing

[Edgar Pettijohn]

On 02/11/18 05:12, Christer Solskogen wrote:

On Sun, Feb 11, 2018 at 12:47 AM,  wrote:


What is the output of:

$ hostname



hugs# hostname
hugs.antarctica.no
hugs# hostname -s
hugs


I'm out of ideas.  Pretty sure it won't like a hostname without 2 parts ie:

my.domain

Looks like there has been some activity in the cvs log in the last 6 
months so maybe you have uncovered a bug of some sort.

Re: dhclient not renewing

[Christer Solskogen]

On Sun, Feb 11, 2018 at 12:47 AM,  wrote:

> What is the output of:
>
> $ hostname
>
>

hugs# hostname
hugs.antarctica.no
hugs# hostname -s
hugs

Re: dhclient not renewing

[edgar]

On Feb 10, 2018 5:07 PM, Christer Solskogen  
wrote:
>
> On Sat, Feb 10, 2018 at 11:16 PM, Edgar Pettijohn 
> wrote:
>
> > try:
> > supersede host-name "my.hugs";
> >
> >
> Still same warning. But I think this comes from the dhcp server of my ISP.
> Even without the options it says so.

What is the output of:

$ hostname

Re: dhclient not renewing

[Christer Solskogen]

On Sat, Feb 10, 2018 at 11:16 PM, Edgar Pettijohn 
wrote:

> try:
> supersede host-name "my.hugs";
>
>
Still same warning. But I think this comes from the dhcp server of my ISP.
Even without the options it says so.

Re: dhclient not renewing

[Edgar Pettijohn]

On 02/10/18 15:43, Christer Solskogen wrote:

On Sat, Feb 10, 2018 at 8:44 PM, Mihai Popescu  wrote:


Upgraded to latest current snapshot, and it looks like dhclient doesn't

renew the ip anymore. I'm  > running it in debug mode now, to see if there
is anything in the log.

Thank you for letting people know.
It will take forever if it is not correctly setup.

http://www.openbsd.org/faq/faq1.html#MailLists
http://www.openbsd.org/faq/faq1.html#Bugs
http://www.openbsd.org/report.html



em2: DHCPREQUEST to 255.255.255.255
em2: DHCPACK from 51.174.112.1 (00:02:00:01:00:01)
em2: invalid host name in host-name

^

em2: bound to 51.174.196.170 from 51.174.112.1 (00:02:00:01:00:01)



em2: DHCPREQUEST to 51.174.112.1
em2: DHCPNAK from 51.174.112.1 (00:02:00:01:00:01)
em2: DHCPDISCOVER - interval 1
em2: DHCPDISCOVER - interval 1
em2: DHCPOFFER from 51.174.112.1 (00:02:00:01:00:01)
em2: invalid host name in host-name
em2: DHCPREQUEST to 255.255.255.255
em2: DHCPACK from 51.174.112.1 (00:02:00:01:00:01)
em2: invalid host name in host-name
em2 [priv]: writev(RTM_GET) - no default route
em2 [priv]: writev(RTM_GET) - no default route
em2 [priv]: writev(RTM_GET) - no default route


OpenBSD 6.2-current (GENERIC.MP) #0: Sat Feb 10 00:05:49 MST 2018
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

my dhclient.conf looks like this:

interface "em2"
{
 supersede host-name "hugs";

try:
supersede host-name "my.hugs";

 supersede domain-name "antarctica.no";
 supersede domain-name-servers 192.168.0.1, 192.168.0.4;
}

Re: dhclient not renewing

[Christer Solskogen]

On Sat, Feb 10, 2018 at 8:44 PM, Mihai Popescu  wrote:

> > Upgraded to latest current snapshot, and it looks like dhclient doesn't
> renew the ip anymore. I'm  > running it in debug mode now, to see if there
> is anything in the log.
>
> Thank you for letting people know.
> It will take forever if it is not correctly setup.
>
> http://www.openbsd.org/faq/faq1.html#MailLists
> http://www.openbsd.org/faq/faq1.html#Bugs
> http://www.openbsd.org/report.html
>
>
em2: DHCPREQUEST to 255.255.255.255
em2: DHCPACK from 51.174.112.1 (00:02:00:01:00:01)
em2: invalid host name in host-name
em2: bound to 51.174.196.170 from 51.174.112.1 (00:02:00:01:00:01)



em2: DHCPREQUEST to 51.174.112.1
em2: DHCPNAK from 51.174.112.1 (00:02:00:01:00:01)
em2: DHCPDISCOVER - interval 1
em2: DHCPDISCOVER - interval 1
em2: DHCPOFFER from 51.174.112.1 (00:02:00:01:00:01)
em2: invalid host name in host-name
em2: DHCPREQUEST to 255.255.255.255
em2: DHCPACK from 51.174.112.1 (00:02:00:01:00:01)
em2: invalid host name in host-name
em2 [priv]: writev(RTM_GET) - no default route
em2 [priv]: writev(RTM_GET) - no default route
em2 [priv]: writev(RTM_GET) - no default route


OpenBSD 6.2-current (GENERIC.MP) #0: Sat Feb 10 00:05:49 MST 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

my dhclient.conf looks like this:

interface "em2"
{
supersede host-name "hugs";
supersede domain-name "antarctica.no";
supersede domain-name-servers 192.168.0.1, 192.168.0.4;
}

Re: dhclient not renewing

[Mihai Popescu]

> Upgraded to latest current snapshot, and it looks like dhclient doesn't renew 
> the ip anymore. I'm  > running it in debug mode now, to see if there is 
> anything in the log.

Thank you for letting people know.
It will take forever if it is not correctly setup.

http://www.openbsd.org/faq/faq1.html#MailLists
http://www.openbsd.org/faq/faq1.html#Bugs
http://www.openbsd.org/report.html

Re: dhclient won't get any IP

[Christer Solskogen]

On Mon, Jun 19, 2017 at 10:11 AM, Stuart Henderson 
wrote:

> On 2017-06-18, Christer Solskogen  wrote:
> > I'm running the latest snapshot, and I suspect that there is something
> > wrong with dhclient.
> > (or at least, that is the symptom)
> >
> >
> > Jun 18 20:50:14 tugs dhclient[79331]: DHCPDISCOVER on re2 - interval 1
> > Jun 18 20:50:14 tugs dhclient[79331]: DHCPOFFER from 51.174.112.1
> > (00:02:00:01:00:01)
> > Jun 18 20:50:14 tugs dhclient[79331]: lease declined: invalid host name
> in
> > host-name
>
> Please capture the packets:
>
> tcpdump -ni re2 -vvs1500 -X port bootps or bootpc
>
>
>

I've got this from Kenneth R Westerback:

"This would indicate that the DHCP option 12 (host-name) has a value
that is not a invalid DNS domain name. It appears I inadvertantly made
this a fatal error in recent changes, which it probably wasn't
before. i.e. the same error should be in your logs from before the
latest snapshot, but the lease was accepted.

I will check this out. Thanks."

Re: dhclient won't get any IP

[Stuart Henderson]

On 2017-06-18, Christer Solskogen  wrote:
> I'm running the latest snapshot, and I suspect that there is something
> wrong with dhclient.
> (or at least, that is the symptom)
>
>
> Jun 18 20:50:14 tugs dhclient[79331]: DHCPDISCOVER on re2 - interval 1
> Jun 18 20:50:14 tugs dhclient[79331]: DHCPOFFER from 51.174.112.1
> (00:02:00:01:00:01)
> Jun 18 20:50:14 tugs dhclient[79331]: lease declined: invalid host name in
> host-name

Please capture the packets:

tcpdump -ni re2 -vvs1500 -X port bootps or bootpc

Re: dhclient won't get any IP

[Christer Solskogen]

On Sun, Jun 18, 2017 at 10:54 PM, Edgar Pettijohn 
wrote:


>
> What is the `host-name` that it claims to be invalid?
>

I have no idea. dhclient.conf is empty.

Re: dhclient won't get any IP

[Edgar Pettijohn]

On 06/18/17 14:38, Christer Solskogen wrote:

I'm running the latest snapshot, and I suspect that there is something
wrong with dhclient.
(or at least, that is the symptom)


Jun 18 20:50:14 tugs dhclient[79331]: DHCPDISCOVER on re2 - interval 1
Jun 18 20:50:14 tugs dhclient[79331]: DHCPOFFER from 51.174.112.1
(00:02:00:01:00:01)
Jun 18 20:50:14 tugs dhclient[79331]: lease declined: invalid host name in
host-name


What is the `host-name` that it claims to be invalid?


Jun 18 20:50:14 tugs dhclient[79331]: DHCPDECLINE on re2
Jun 18 20:50:14 tugs dhclient[79331]: No acceptable DHCPOFFERS received.
Jun 18 20:50:14 tugs dhclient[79331]: No working leases in persistent
database - sleeping.
Jun 18 20:50:15 tugs dhclient[79331]: DHCPDISCOVER on re2 - interval 1
Jun 18 20:50:15 tugs dhclient[79331]: DHCPOFFER from 51.174.112.1
(00:02:00:01:00:01)
Jun 18 20:50:15 tugs dhclient[79331]: lease declined: invalid host name in
host-name
Jun 18 20:50:15 tugs dhclient[79331]: DHCPDECLINE on re2
Jun 18 20:50:15 tugs dhclient[79331]: No acceptable DHCPOFFERS received.
Jun 18 20:50:15 tugs dhclient[79331]: No working leases in persistent
database - sleeping.
Jun 18 20:50:16 tugs dhclient[79331]: DHCPDISCOVER on re2 - interval 1
Jun 18 20:50:16 tugs dhclient[79331]: DHCPOFFER from 51.174.112.1
(00:02:00:01:00:01)
Jun 18 20:50:16 tugs dhclient[79331]: lease declined: invalid host name in
host-name
Jun 18 20:50:16 tugs dhclient[79331]: DHCPDECLINE on re2

and it continues like this...
I installed isc-dhcp-client to see if the problem was my ISP but with that
client it works.

Re: dhclient iwn0 *and* run0 -> lease duration confusion

[Marcus MERIGHI]

Kenneth Westerback was kind enough to give detailed explanation but
forgot to CC misc@, with his permission here it is:

++
Date: Thu, 4 Feb 2016 10:18:39 -0500
From: Kenneth Westerback <kwesterb...@gmail.com>
Subject: re: dhclient iwn0 *and* run0 -> lease duration confusion

That message does not report the lease time, it reports the real time
left before the lease expires after the bind completes.. Configuring
the interface can take finite time after receiving the lease and
starting the binding.

If you want to see what the actual lease durations are you must look
in the /var/db/dhclient.<if? files. If you are interested in the
unedited information in the lease you must use the -L option to
capture the offered as well as the effective lease.

 Ken
++

Bye, Marcus

mcmer-open...@tor.at (Marcus MERIGHI), 2016.02.02 (Tue) 10:21 (CET):
> Hello,
>
> it seems dhclient gets confused about lease durations when getting
> leases for two (wlan) interfaces from the same dhcp server.
>
> I'm not sure this is a bug or done that way intentionally.
>
> While working on the ds47d issue (bugs@) I had left an additional WLAN
> stick connected to the machine, both hostname.ifs contain
> nwid XX  # <- same on both
> wpakey YY# <- same on both
> dhcp # <- well yes same on both
>
> When booting I get these messages:
>
> First run, when I noticed:
>
> DHCPREQUEST on iwn0 to 255.255.255.255
> DHCPACK from 192.168.188.189 (80:1f:02:c1:fd:86)
> bound to 192.168.188.104 -- renewal in 900 seconds.
>^^^
> DHCPREQUEST on run0 to 255.255.255.255
> DHCPACK from 192.168.188.189 (80:1f:02:c1:fd:86)
> bound to 192.168.188.105 -- renewal in 898 seconds.
>^^^
>
> Second run, to make sure:
>
> DHCPREQUEST on iwn0 to 255.255.255.255
> DHCPACK from 192.168.188.189 (80:1f:02:c1:fd:86)
> bound to 192.168.188.104 -- renewal in 900 seconds.
>^^^
> DHCPREQUEST on run0 to 255.255.255.255
> DHCPACK from 192.168.188.189 (80:1f:02:c1:fd:86)
> bound to 192.168.188.105 -- renewal in 899 seconds.
>^^^
> Bye, Marcus

Re: dhclient iwn0 *and* run0 -> lease duration confusion

[Mihai Popescu]

| DHCPREQUEST on iwn0 to 255.255.255.255
| DHCPACK from 192.168.188.189 (80:1f:02:c1:fd:86)
| bound to 192.168.188.104 -- renewal in 900 seconds.
|
| DHCPREQUEST on run0 to 255.255.255.255
| DHCPACK from 192.168.188.189 (80:1f:02:c1:fd:86)
| bound to 192.168.188.105 -- renewal in 898 seconds.

Subnet mask criteria, maybe?

Re: dhclient broken on 2015-09-21 amd64 snapshot

[Stuart Henderson]

On 2015/09/23 08:16, Kurt Mosiejczuk wrote:
> On Wed, Sep 23, 2015 at 07:37:05AM +, Stuart Henderson wrote:
> > On 2015-09-22, Kurt Mosiejczuk  wrote:
> > > I just updated my current box to yesterdays (2015-09-21) snapshot.  Now
> > > it won't keep a network address.  
> 
> > That's a recent bug - should be fixed if you update again.
> 
> Excellent.  I'll watch my mirror for a newer snapshot.  It just occurred
> to me I didn't have a problem when using bsd.rd.  Hopefully that is still
> true when I try and install the new snapshot.
> 
> Can you point me at the bug fix?  I was looking at cvsweb again and the
> newest change I could see there is 2 weeks ago...

I believe this is the issue fixed by this commit - if you saved the
previous kernel before updating, you might be able to boot with that
instead.

-
PatchSet 4122 
Date: 2015/09/22 11:05:00
Author: mpi
Branch: HEAD
Tag: (none) 
Log:
When a connected route is deleted, pass the corresponding priority to
rtrequest1(9) otherwise the route will remain attached to a stale ifa.

Found by matthieu@

Members: 
route.c:1.240->1.241 

Index: src/sys/net/route.c
diff -u src/sys/net/route.c:1.240 src/sys/net/route.c:1.241
--- src/sys/net/route.c:1.240   Mon Sep 21 11:15:27 2015
+++ src/sys/net/route.c Tue Sep 22 10:05:00 2015
@@ -1,4 +1,4 @@
-/* $OpenBSD: route.c,v 1.240 2015/09/21 11:15:27 mpi Exp $ */
+/* $OpenBSD: route.c,v 1.241 2015/09/22 10:05:00 mpi Exp $ */
 /* $NetBSD: route.c,v 1.14 1996/02/13 22:00:46 christos Exp $  */
 
 /*
@@ -1267,6 +1267,9 @@
 
if (flags & (RTF_LOCAL|RTF_BROADCAST))
prio = RTP_LOCAL;
+
+   if (flags & RTF_CONNECTED)
+   prio = RTP_CONNECTED;
 
error = rtrequest1(RTM_DELETE, , prio, , rtableid);
if (error == 0) {

Re: dhclient broken on 2015-09-21 amd64 snapshot

[Kurt Mosiejczuk]

On Wed, Sep 23, 2015 at 07:37:05AM +, Stuart Henderson wrote:
> On 2015-09-22, Kurt Mosiejczuk  wrote:
> > I just updated my current box to yesterdays (2015-09-21) snapshot.  Now
> > it won't keep a network address.  

> That's a recent bug - should be fixed if you update again.

Excellent.  I'll watch my mirror for a newer snapshot.  It just occurred
to me I didn't have a problem when using bsd.rd.  Hopefully that is still
true when I try and install the new snapshot.

Can you point me at the bug fix?  I was looking at cvsweb again and the
newest change I could see there is 2 weeks ago...

> > Did the dhclient change get overlooked?  Am I doing something else
> > obviously wrong?

> This is unrelated, but dhclient just needed recompiling with the updated
> headers ("include files") to know about the larger ifmedia struct, it
> just uses it to check link status and didn't require any code changes.
> On the other hand ifconfig does more processing with the media status,
> e.g. passing the type to another function to look up the text description,
> so the variable types need changing so that the larger values fit.

Okay, good.  Also glad I didn't work hard on getting an up to date source
tree on the machine with no network currently to try and fix it :)

> BTW this ifmedia change was because we were running out of space in
> the structure for different media types (10base2, 10baseT, 100baseTX,
> 1000baseSX, 1000baseT etc for ethernet, various modulation types for
> 802.11 wireless, etc), the change allows space for more types for
> future use (e.g. there's an IEEE working group, 802.3bz, looking at
> standardizing 2.5/5Gb over cat5e, and other existing standards we don't
> support yet).

Cool.  Thanks for the explanation on the change.

--Kurt

Re: dhclient broken on 2015-09-21 amd64 snapshot

[Kurt Mosiejczuk]

On Wed, Sep 23, 2015 at 01:27:27PM +0100, Stuart Henderson wrote:
> On 2015/09/23 08:16, Kurt Mosiejczuk wrote:

> > Can you point me at the bug fix?  I was looking at cvsweb again and the
> > newest change I could see there is 2 weeks ago...

> I believe this is the issue fixed by this commit - if you saved the
> previous kernel before updating, you might be able to boot with that
> instead.

Ah.  So the bug is even more unrelated to dhclient than I was
thinking.  

A newer snapshot (from yesterday, 2015-09-22) was on my mirror today, and
booting from the bsd.rd worked for upgrading to the newer snapshot with
the fix.  I'm guessing whatever caused the bug isn't enabled for the
RAMDISK kernel.

--Kurt

Re: dhclient broken on 2015-09-21 amd64 snapshot

[Stuart Henderson]

On 2015-09-22, Kurt Mosiejczuk  wrote:
> I just updated my current box to yesterdays (2015-09-21) snapshot.  Now
> it won't keep a network address.  

That's a recent bug - should be fixed if you update again.

> I'm seeing a note on the current FAQ from the 12th indicating the
> ifmedia options have been extended to 64 bits.  I'm seeing a change to
> ifconfig in the tree for this, but I don't see a corresponding change to
> dhclient in the tree (looking at cvsweb).  
>
> Did the dhclient change get overlooked?  Am I doing something else
> obviously wrong?

This is unrelated, but dhclient just needed recompiling with the updated
headers ("include files") to know about the larger ifmedia struct, it
just uses it to check link status and didn't require any code changes.
On the other hand ifconfig does more processing with the media status,
e.g. passing the type to another function to look up the text description,
so the variable types need changing so that the larger values fit.

BTW this ifmedia change was because we were running out of space in
the structure for different media types (10base2, 10baseT, 100baseTX,
1000baseSX, 1000baseT etc for ethernet, various modulation types for
802.11 wireless, etc), the change allows space for more types for
future use (e.g. there's an IEEE working group, 802.3bz, looking at
standardizing 2.5/5Gb over cat5e, and other existing standards we don't
support yet).

Re: dhclient question

[Marcus MERIGHI]

kwesterb...@gmail.com (Kenneth Westerback), 2014.06.23 (Mon) 18:53 (CEST):
 On 23 June 2014 06:24, Avi Cohen av...@rad.com wrote:
  In my application  (it is a router in the access)  I'm initially  running
  dhclient daemon without any  interface specified for dhcp.
  Then - on user request - we  add  interfaces  to dhclient.conf on run-time
 
  I have 3 questions  - that I'll appreciate if you can answer
 
 You can read dhclient(8) and dhclient.conf(5) man pages for details.
 But to summarize ...
 
 (You seem to ask 4 questions, so which one will you not appreciate an
 answer to? :-))
 
 
  1.   Is it possible to append  interfaces  to an existing dhclient.conf 
  ?
  or just to add a new (for example)  dhclient.conf-eth1?  [BTW - where to
  locate this file ?]
 
 You can append as many 'interface' statements as you like in the
 dhclient.conf file. If you want to run with a separate config file for
 a particular instance of dhclient you can use the '-c' option to
 specify the non-default file.
 
 
  2.When the daemon will  start the dhcp-request for this new  
  interface
  ?
 
 When you start it. Every interface's dhclient must be started
 separately. If you start a dhclient without specifying the interface
 it attempts to find an interface in the 'egress' group. If there is
 one and only one such interface then dhclient will use it. For other
 interfaces you must start other instances of dhclient, usually by
 creating a /etc/hostname.if file for that interface. The
 /etc/hostname.if file will be used at system startup or you can 'sh
 /etc/netstart if' as root.
 
  3.   Our application need to be informed whenever a new IP-address 
  (dhcp)
  is assigned for the interface.  How to do it ? by polling the 
  dhclient.leases
  ?  is there a notification from dhclient to  our application that we can use
  ?
 
 The best way to do that is with a program that monitors the routing
 socket, where you can see all address changes.

hint: route(8) monitor

Bye, Marcus

 Alternatively you can monitor the leases file or use the '-L' option
 to write out the offered and effective lease information if you want
 complete information on what is being received and used. Some people
 use the entr port (/usr/ports/sysutils/entr, http://entrproject.org/)
 to monitor the file(s).
 
 
  4.   4 - if I start the dhclient daemon without interface specified - I
  see that it sends  dhcp-request for all my exiting interfaces ? why ? how to
  disable this behavior and to send request for only
 
  Specified interfaces ? (but without specifying  it in the command line- but
  via dhclient.conf  ?
 
 Now you make me doubt you are running OpenBSD. Our dhclient does not
 send dhcp-request for all interfaces -- it sends dhcp-requests out one
 and only one interface. At least for the last 10 years or more.
 
 You must specify the interface via the command line, or have the
 /etc/netstart command build the command line for you from a
 hostname.if file.
 
  Ken
 
  Regards,
  Avi
 
 !DSPAM:53a85bed101242941456129!

Re: dhclient question

[Stuart Henderson]

On 2014-06-23, Kenneth Westerback kwesterb...@gmail.com wrote:
 Alternatively you can monitor the leases file or use the '-L' option
 to write out the offered and effective lease information if you want
 complete information on what is being received and used. Some people
 use the entr port (/usr/ports/sysutils/entr, http://entrproject.org/)
 to monitor the file(s).

FWIW, I'm doing this to monitor nameserver changes, here's an example.
Note that it relies on support that was added to dhclient post-5.5.

(entr is from packages; it's a nice simple kqueue watcher, so it
works by a trigger when the file is changed, rather than needing to
poll it periodically).

$ cat /etc/dhcp-watcher  
#!/bin/sh
gw=$(route -n get -inet 0.0.0.0 | awk '/interface/ {print $2}')
dns=$(awk '/domain-name-servers/ {gsub([;,],  , $3); print $3;}' 
/etc/dhclient.lease.$gw)
unbound-control forward_add . $dns  /dev/null
echo default now on $gw: $(unbound-control list_forwards) | logger -t 
dhcp-watcher

$ cat /etc/dhcp-watcher.run  
#!/bin/sh
/etc/dhcp-watcher
echo /etc/dhclient.lease.* | tr ' ' '\n' | entr /etc/dhcp-watcher

$ cat /etc/hostname.em0 
 
up -autoconfprivacy
!dhclient -L /etc/dhclient.lease.em0 em0
rtsol

$ cat /etc/hostname.iwn0
 
nwid rarara wpakey ackackmacaque wpaprotos wpa2 wpaciphers ccmp
!dhclient -L /etc/dhclient.lease.iwn0 iwn0
rtsol

Re: dhclient question

[Kenneth Westerback]

On 23 June 2014 06:24, Avi Cohen av...@rad.com wrote:
 Hello
 In my application  (it is a router in the access)  I'm initially  running
 dhclient daemon without any  interface specified for dhcp.
 Then - on user request - we  add  interfaces  to dhclient.conf on run-time

 I have 3 questions  - that I'll appreciate if you can answer

You can read dhclient(8) and dhclient.conf(5) man pages for details.
But to summarize ...

(You seem to ask 4 questions, so which one will you not appreciate an
answer to? :-))


 1.   Is it possible to append  interfaces  to an existing dhclient.conf ?
 or just to add a new (for example)  dhclient.conf-eth1?  [BTW - where to
 locate this file ?]

You can append as many 'interface' statements as you like in the
dhclient.conf file. If you want to run with a separate config file for
a particular instance of dhclient you can use the '-c' option to
specify the non-default file.


 2.When the daemon will  start the dhcp-request for this new  interface
 ?

When you start it. Every interface's dhclient must be started
separately. If you start a dhclient without specifying the interface
it attempts to find an interface in the 'egress' group. If there is
one and only one such interface then dhclient will use it. For other
interfaces you must start other instances of dhclient, usually by
creating a /etc/hostname.if file for that interface. The
/etc/hostname.if file will be used at system startup or you can 'sh
/etc/netstart if' as root.


 3.   Our application need to be informed whenever a new IP-address (dhcp)
 is assigned for the interface.  How to do it ? by polling the dhclient.leases
 ?  is there a notification from dhclient to  our application that we can use
 ?

The best way to do that is with a program that monitors the routing
socket, where you can see all address changes.

Alternatively you can monitor the leases file or use the '-L' option
to write out the offered and effective lease information if you want
complete information on what is being received and used. Some people
use the entr port (/usr/ports/sysutils/entr, http://entrproject.org/)
to monitor the file(s).


 4.   4 - if I start the dhclient daemon without interface specified - I
 see that it sends  dhcp-request for all my exiting interfaces ? why ? how to
 disable this behavior and to send request for only

 Specified interfaces ? (but without specifying  it in the command line- but
 via dhclient.conf  ?

Now you make me doubt you are running OpenBSD. Our dhclient does not
send dhcp-request for all interfaces -- it sends dhcp-requests out one
and only one interface. At least for the last 10 years or more.

You must specify the interface via the command line, or have the
/etc/netstart command build the command line for you from a
hostname.if file.

 Ken




 Regards,
 Avi

Re: dhclient fallback lease declaration doesn't configure the interface

[Alessandro DE LAURENZIS]

On Sun 27/04, Kenneth R Westerback wrote:
 On Fri, Apr 25, 2014 at 12:31:16PM +0200, Alessandro DE LAURENZIS wrote:
  On Tue 22/04, Kenneth Westerback wrote:
   
Another thing: as highlighted in my initial message, I'm using the
loopback i/f as router address in the lease declaration section:
   
# Lease declarations (fallback)
lease {
interface trunk0;
fixed-address 192.168.1.103;
option subnet-mask 255.255.255.0;
option routers 127.0.0.1;
option domain-name-servers 127.0.0.1;
option dhcp-lease-time 259200;
renew  4 2020/12/31 23:59:59 UTC;
rebind 4 2020/12/31 23:59:59 UTC;
expire 4 2020/12/31 23:59:59 UTC;
}
   
(this is the only way to make the router ping-able when trying to
configure a crossover cable connection between 2 PCs). Tomas Bodzar from
misc@ pointed me out it is in a different subnet w.r.t. the fixed 
address;
do you think it may be relevant?
   
   Shouldn't be relevant for the dhclient part. Unless there is a check
   which I'm not aware of. But I'll look to make sure.
   
    Ken
   
  
 
 And now a version that doesn't loop after trying a static lease. :-)
 
  Ken
 

Hello Ken,

Your last patch doesn't apply to 5.4-Stable as is, some hunks required a
bit of manual code modifications, but finally... it worked!

Now the i/f (both the physical eth and the virtual trunk) are correctly
configured after having acquired the fallback lease.

If you need to experiment with other modifications/adjustments, please
let me know.

Great achievement, in my opinion! Thanks a lot for your support,
kindness and patience.

Cheers

-- 
Alessandro DE LAURENZIS
[mailto:just22@gmail.com]
LinkedIn: http://it.linkedin.com/in/delaurenzis

Re: dhclient fallback lease declaration doesn't configure the interface

[Tomas Bodzar]

On Mon, Apr 21, 2014 at 4:29 PM, Alessandro DE LAURENZIS 
just22@gmail.com wrote:

 Hello,

 5.4-Rel here, GENERIC.MP kernel.

 Rather often I need to connect my laptop to networks without DHCP service
 (sometimes I use a direct connection through a crossover cable, too); so
 it would be nice to have a semi-automatic configuration procedure.

 I'm trying to exploit the dhclient's lease declaration feature; this
 is an excerpt of my /etc/dhclient.conf:

 # Lease declarations (fallback)
 lease {
 interface trunk0;
 fixed-address 192.168.1.103;
 option subnet-mask 255.255.255.0;
 option routers 127.0.0.1;
 option domain-name-servers 127.0.0.1;
 option dhcp-lease-time 259200;
 renew  4 2020/12/31 23:59:59 UTC;
 rebind 4 2020/12/31 23:59:59 UTC;
 expire 4 2020/12/31 23:59:59 UTC;
 }

 (note that I used the loopback address for routers and
 domain-name-servers fields, in order to bound them to something
 ping-able). When I connect the Eth i/f to a DHCP-less network and
 restart the service, I obtain:

 just22@poseidon:[~] sudo sh /etc/netstart trunk0
 [...]
 DHCPREQUEST on trunk0 to 255.255.255.255 port 67
 DHCPREQUEST on trunk0 to 255.255.255.255 port 67
 DHCPREQUEST on trunk0 to 255.255.255.255 port 67
 [...]
 No acceptable DHCPOFFERS received.
 Trying recorded lease 192.168.1.103
 bound: renewal in 128358 seconds.

 So it seems that the lease has been obtained as expected; unfortunately,
 the interface is still not configured:

 just22@poseidon:[~] ifconfig trunk0
 trunk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAS
 lladdr 00:21:86:94:34:8e
 priority: 0
 trunk: trunkproto failover
 trunkport iwn0
 trunkport em0 master,active
 groups: trunk egress
 media: Ethernet autoselect
 status: active
 inet6 fe80::221:86ff:fe94:348e%trunk0 prefixlen

 Am I doing anything wrong? Is this an expected behavior? Could you point
 me in the right direction?

 Thanks in advance for your time and patience

 --
 Alessandro DE LAURENZIS
 [mailto:just22@gmail.com]
 LinkedIn: http://it.linkedin.com/in/delaurenzis



From man dhclient:

A mobile host which may sometimes need to access a network on which no
 DHCP server exists may be preloaded with a lease for a fixed address on
 that network.  When all attempts to contact a DHCP server have failed,
 *dhclient* will try to validate the static lease, and if it succeeds, it
 will use that lease until it is restarted.

 . First of all not good idea having router with 127. and your IP
192... Give them same subnet. Second can you try with real interface
directly to skip trunk (if there's not something wrong with trunk itself)?
Third try to enable debug for dhclient and network interface if it does
show something more. Did you try if your config is working directly defined
in interface file and what it shows during debug run?
http://www.openbsd.org/faq/faq6.html#Setup

Re: dhclient

[sven falempin]

On Wed, Mar 26, 2014 at 3:13 PM, Theo de Raadt dera...@cvs.openbsd.org wrote:
 Using pkill(1) correctly should be more efficient than opening a
 file, reading its contents, then passing those as an argument to
 kill(1).

 None of the mechanisms removes the race.

 However, of all the mechanisms, pidfiles are the worst.  They
 even persist over reboot.



Sometimes i feel curse (or maybe just tired) :

main::(/bin/check_network.pl:164):  my $src =
system('/usr/bin/pkill -HUP -f dhclient: trunk0');
  DB2 n
main::(/bin/check_network.pl:165):if ($src) {
  DB2 p $src
33024

Of course pkill is supposed to return 0,1,2 or 3 and it does in the shell
I wont even try to think further about that.

All i wanted was to ask again for a lease , i guess i will just
relaunch because -HUP is
a lie, the pid change .

Simplicity shall prevail ?

IMHO , lets remove the HUP signal for dhclient i do not like it anymore !!!

Best regards,

--

mans says : Conversely, if the interface is later manipulated to add
or delete addresses then dhclient will automatically exit.  It thus
automatically exits whenever a new dhclient is run on the same interface.



-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: dhclient

[Philip Guenther]

On Thu, Mar 27, 2014 at 2:28 PM, sven falempin sven.falem...@gmail.com wrote:
 Sometimes i feel curse (or maybe just tired) :

 main::(/bin/check_network.pl:164):  my $src =
 system('/usr/bin/pkill -HUP -f dhclient: trunk0');
   DB2 n
 main::(/bin/check_network.pl:165):if ($src) {
   DB2 p $src
 33024

 Of course pkill is supposed to return 0,1,2 or 3 and it does in the shell

perldoc -f system
...
   The return value is the exit status of the program as returned
   by the wait call.  To get the actual exit value, shift right
   by eight (see below).  See also exec.  This is not what you

33024  8 == 129




 I wont even try to think further about that.

 All i wanted was to ask again for a lease , i guess i will just
 relaunch because -HUP is
 a lie, the pid change .

 Simplicity shall prevail ?

 IMHO , lets remove the HUP signal for dhclient i do not like it anymore !!!

 Best regards,

 --

 mans says : Conversely, if the interface is later manipulated to add
 or delete addresses then dhclient will automatically exit.  It thus
 automatically exits whenever a new dhclient is run on the same interface.



 --
 -
 () ascii ribbon campaign - against html e-mail
 /\

Re: dhclient

[Philip Guenther]

On Thu, Mar 27, 2014 at 3:00 PM, Philip Guenther guent...@gmail.com wrote:
 On Thu, Mar 27, 2014 at 2:28 PM, sven falempin sven.falem...@gmail.com 
 wrote:
 Sometimes i feel curse (or maybe just tired) :

 main::(/bin/check_network.pl:164):  my $src =
 system('/usr/bin/pkill -HUP -f dhclient: trunk0');
   DB2 n
 main::(/bin/check_network.pl:165):if ($src) {
   DB2 p $src
 33024

 Of course pkill is supposed to return 0,1,2 or 3 and it does in the shell

 perldoc -f system
 ...
The return value is the exit status of the program as returned
by the wait call.  To get the actual exit value, shift right
by eight (see below).  See also exec.  This is not what you

 33024  8 == 129

(Stupid gmail control-enter==Send)

So, why is it returning 129?  Well, since you gave system() a single
string it's actually invoked via the shell.  Why would the shell
report a status of 129?
 ?The exit status of the last non-asynchronous command executed.
  If the last command was killed by a signal, $? is set to 128
  plus the signal number.

So, pkill is dying with signal 1 == HUP.  Hey, wait a minute, pkill's
criteria matches its own command line, so it will kill itself!  Time
to be more clever about the criteria...



Philip Guenther

Re: dhclient

[Alexander Hall]

On 03/27/14 23:07, Philip Guenther wrote:

On Thu, Mar 27, 2014 at 3:00 PM, Philip Guenther guent...@gmail.com wrote:

On Thu, Mar 27, 2014 at 2:28 PM, sven falempin sven.falem...@gmail.com wrote:

Sometimes i feel curse (or maybe just tired) :

main::(/bin/check_network.pl:164):  my $src =
system('/usr/bin/pkill -HUP -f dhclient: trunk0');
   DB2 n
main::(/bin/check_network.pl:165):if ($src) {
   DB2 p $src
33024

Of course pkill is supposed to return 0,1,2 or 3 and it does in the shell


perldoc -f system
...
The return value is the exit status of the program as returned
by the wait call.  To get the actual exit value, shift right
by eight (see below).  See also exec.  This is not what you

33024  8 == 129


(Stupid gmail control-enter==Send)

So, why is it returning 129?  Well, since you gave system() a single
string it's actually invoked via the shell.  Why would the shell
report a status of 129?
  ?The exit status of the last non-asynchronous command executed.
   If the last command was killed by a signal, $? is set to 128
   plus the signal number.

So, pkill is dying with signal 1 == HUP.  Hey, wait a minute, pkill's
criteria matches its own command line, so it will kill itself!  Time
to be more clever about the criteria...


If I'm not totally mistaken, pkill is expected not to kill itself, just 
as pgrep is expected not to list itself either.


/Alexander





Philip Guenther

Re: dhclient

[Alexander Hall]

On 03/27/14 23:26, Alexander Hall wrote:

On 03/27/14 23:07, Philip Guenther wrote:

On Thu, Mar 27, 2014 at 3:00 PM, Philip Guenther guent...@gmail.com
wrote:

On Thu, Mar 27, 2014 at 2:28 PM, sven falempin
sven.falem...@gmail.com wrote:

Sometimes i feel curse (or maybe just tired) :

main::(/bin/check_network.pl:164):  my $src =
system('/usr/bin/pkill -HUP -f dhclient: trunk0');
   DB2 n
main::(/bin/check_network.pl:165):if ($src) {
   DB2 p $src
33024

Of course pkill is supposed to return 0,1,2 or 3 and it does in the
shell


perldoc -f system
...
The return value is the exit status of the program as
returned
by the wait call.  To get the actual exit value,
shift right
by eight (see below).  See also exec.  This is not
what you

33024  8 == 129


(Stupid gmail control-enter==Send)

So, why is it returning 129?  Well, since you gave system() a single
string it's actually invoked via the shell.  Why would the shell
report a status of 129?
  ?The exit status of the last non-asynchronous command
executed.
   If the last command was killed by a signal, $? is set
to 128
   plus the signal number.

So, pkill is dying with signal 1 == HUP.  Hey, wait a minute, pkill's
criteria matches its own command line, so it will kill itself!  Time
to be more clever about the criteria...


If I'm not totally mistaken, pkill is expected not to kill itself, just
as pgrep is expected not to list itself either.


Ah, but it could be killing the shell that system() spawns to run pkill!

If so (and even if not), lession to learn (#2): Don't invoce system() 
with a single argument unless you really need the shell parsing.


/Alexander

Re: dhclient

[Adam Thompson]

On 2014-03-27 17:07, Philip Guenther wrote: 

 On Thu, Mar 27, 2014
at 3:00 PM, Philip Guenther guent...@gmail.com wrote:
 
 On Thu,
Mar 27, 2014 at 2:28 PM, sven falempin sven.falem...@gmail.com [1]
wrote: 
 
 Sometimes i feel curse (or maybe just tired) :
main::(/bin/check_network.pl:164): my $src = system('/usr/bin/pkill -HUP
-f dhclient: trunk0'); DBn main::(/bin/check_network.pl:165): if
($src) { DBp $src 33024 Of course pkill is supposed to return 0,1,2 or 3
and it does in the shell
 perldoc -f system ... The return value is
the exit status of the program as returned by the wait call. To get
the actual exit value, shift right by eight (see below). See also
exec. This is not what you 33024  8 == 129
 
 (Stupid gmail
control-enter==Send)
 
 So, why is it returning 129? Well, since you
gave system() a single
 string it's actually invoked via the shell. Why
would the shell
 report a status of 129?
 ? The exit status of the
last non-asynchronous command executed.
 If the last command was killed
by a signal, $? is set to 128
 plus the signal number.
 
 So, pkill
is dying with signal 1 == HUP. Hey, wait a minute, pkill's
 criteria
matches its own command line, so it will kill itself! Time
 to be more
clever about the criteria...

Which goes back quite neatly to my comment
about correct pkill usage not necessarily being self-evident. 

I
thought pgrep/pkill specifically excluded themselves? 

Oh - it's
killing the subshell that invokes pkill, isn't it? Which propagates the
signal through the process group, which includes pkill... argh! 

Yup,
confirmed: 

 # sh -c pgrep -lf pgrep
 31775 sh -c pgrep -lf pgrep


but... 

 # sh -c pgrep -lfx pgrep
 # 

Perhaps more useful than the
-x option in this case is the fact that pgrep/pkill take REs as
patterns, so just use ^: 

 my $src = system('/usr/bin/pkill -HUP -f
^dhclient: trunk0'); 

-Adam 
 

Links:
--
[1]
mailto:sven.falem...@gmail.com

Re: dhclient

[Alexander Hall]

On 03/27/14 23:36, Adam Thompson wrote:


  my $src = system('/usr/bin/pkill -HUP -f ^dhclient: trunk0');


my $src = system('/usr/bin/pkill', '-HUP', '-f', '^dhclient: trunk0');

/Alexander

Re: dhclient

[sven falempin]

On Thu, Mar 27, 2014 at 6:42 PM, Alexander Hall alexan...@beard.se wrote:
 On 03/27/14 23:36, Adam Thompson wrote:

   my $src = system('/usr/bin/pkill -HUP -f ^dhclient: trunk0');


 my $src = system('/usr/bin/pkill', '-HUP', '-f', '^dhclient: trunk0');

 /Alexander



Thank you all, i'll put the begin of line next time i use pkill in the
spawned subshell.

-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: dhclient

[Alexander Hall]

On 03/27/14 23:58, sven falempin wrote:

On Thu, Mar 27, 2014 at 6:42 PM, Alexander Hall alexan...@beard.se wrote:

On 03/27/14 23:36, Adam Thompson wrote:


   my $src = system('/usr/bin/pkill -HUP -f ^dhclient: trunk0');



my $src = system('/usr/bin/pkill', '-HUP', '-f', '^dhclient: trunk0');

/Alexander




Thank you all, i'll put the begin of line next time i use pkill in the
spawned subshell.


Not sure if you're being ironic or not, and the ^ is a good thing 
anyway, but the reason for passing multiple parameters to system() 
rather than just a single expression, is to avoid creating a subshell at 
all.

Re: dhclient

[sven falempin]

On Thu, Mar 27, 2014 at 6:58 PM, sven falempin sven.falem...@gmail.com wrote:
 On Thu, Mar 27, 2014 at 6:42 PM, Alexander Hall alexan...@beard.se wrote:
 On 03/27/14 23:36, Adam Thompson wrote:

   my $src = system('/usr/bin/pkill -HUP -f ^dhclient: trunk0');


 my $src = system('/usr/bin/pkill', '-HUP', '-f', '^dhclient: trunk0');

 /Alexander



Because you was all so helpful,
i now have the reflex to ask, nevertheless it is not that good to
abuse good think,

Because i saw pkill -HUP was kinda restarting the dhclient,
and because i did read the manpage, AND alexander mail I simply did:

system('/sbin/dhclient', '-l', '/run/dhclient.leases.trunk0', 'trunk0');

(instead of sendind -HUP)
how foolish of me !
The dhclient start, get a lease ...

and die (leaving the trunk0 unconfigured) 

logs :

  DB7
DHCPDISCOVER on trunk0 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on trunk0 to 255.255.255.255 port 67 interval 6
DHCPOFFER from 10.0.0.254 (96:4f:87:9c:ad:67)
DHCPREQUEST on trunk0 to 255.255.255.255 port 67
DHCPACK from 10.0.0.254 (96:4f:87:9c:ad:67)
bound to 10.0.0.101 -- renewal in 21600 seconds.
main::(/etc/network.pl:202):  });
  DB7 n
route: writing to routing socket: Network is unreachable
add host 10.0.0.171: gateway 10.0.0.254: Network is unreachable
  DB7 q

# ifconfig trunk0
trunk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr fe:e1:ba:d1:b4:76
priority: 0
trunk: trunkproto roundrobin
trunkport tun1 active
trunkport tun0 master,active
groups: trunk
media: Ethernet autoselect
status: active
inet6 fe80::200:24ff:fed0:8ed0%trunk0 prefixlen 64 scopeid 0xb

-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: dhclient

[sven falempin]

On Tue, Mar 25, 2014 at 4:02 PM, Theo de Raadt dera...@cvs.openbsd.org wrote:
 well openBSD is so neat it provides a nice call:

 http://www.openbsd.org/cgi-bin/man.cgi?query=pidfileapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html

 but i failed to patch :'(  this make the dhclient quit instead of
 going background, the fact there is two process may also explain why
 there is no pidfile. One is root he other dropped privilege, all of
 this is just giving me a headache at the moment.

 pidfile() is a dangerous subsystem.  The files stay around long after
 the process has died.  There is no interlock.

 If you signal a process lists in a pidfile, who knows what you are
 sending a signal to.  Since the signals are often termination related,
 this can have dangerous effects.

 We don't add more pidfile use, we actually remove them where we can.
 This mechanism has applicability in some situations, but in the big
 picture it is sloppy practice.


Ok.

Listing process takes also times, and deleting the listed PID may also
end in deleting another process in a race condition case.
Or is there some kind of smart lock inside pkill ?

Because pidfile subsystems exists, would it be possible to let the
kernel create and delete a read_only pidfile when forking/cleaning the
process ?

-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: dhclient

[Jan Stary]

On Mar 26 09:29:16, sven.falem...@gmail.com wrote:
 Listing process takes also times,

pkill doesn't list anything.
No really, read the manpage.

 and deleting the listed PID may also
 end in deleting another process in a race condition case.
 Or is there some kind of smart lock inside pkill ?

No.

 Because pidfile subsystems exists, would it be possible to let the
 kernel create and delete a read_only pidfile when forking/cleaning the
 process ?

Lets save the process table in individual files!

Re: dhclient

[sven falempin]

On Wed, Mar 26, 2014 at 1:55 PM, Jan Stary h...@stare.cz wrote:
 On Mar 26 09:29:16, sven.falem...@gmail.com wrote:
 Listing process takes also times,

 pkill doesn't list anything.
 No really, read the manpage.

 and deleting the listed PID may also
 end in deleting another process in a race condition case.
 Or is there some kind of smart lock inside pkill ?

 No.

 Because pidfile subsystems exists, would it be possible to let the
 kernel create and delete a read_only pidfile when forking/cleaning the
 process ?

 Lets save the process table in individual files!


lets talk about /proc :p

-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: dhclient

[Adam Thompson]

On 2014-03-26 13:31, sven falempin wrote: 

 On Wed, Mar 26, 2014
at 1:55 PM, Jan Stary h...@stare.cz wrote:
 
 On Mar 26 09:29:16,
sven.falem...@gmail.com [1]wrote: 
 
 Listing process takes also
times,
 pkill doesn't list anything. No really, read the manpage. 


 and deleting the listed PID may also end in deleting another
process in a race condition case. Or is there some kind of smart lock
inside pkill ?
 No.
 
 lets talk about /proc :p

Quoting from
http://en.wikipedia.org/wiki/Everything_is_a_file, 

 However, this is
typically not considered a fast or portable approach and should be
avoided in most code. 

I personally don't have a problem with, say,
/proc being the canonical source of process data instead of whatever
ps(1) calls, but that takes us out of the traditional realm of UNIX and
into Plan9 territory. 

Also note the existence of /dev/mem and
/dev/kmem... technically you could therefore say that *everything* is
accessible through a file :-). Peeking and pokeing individual bytes in
memory has long since been relegated to device drivers because it's a
PITA. 

Using pkill(1) correctly should be more efficient than opening a
file, reading its contents, then passing those as an argument to
kill(1). 

Of interest, it appears that to use pkill(1) to signal
dhclient(8), in the case where you could have multiple dhclient(8)
instances running, you must use the -f flag to pkill and match
dhclient: ifname, or you'll signal every dhclient instance on the
system. (Yes, I have legitimate cases where I have dhclient running on
two or more interfaces.) 

The privileged process of dhclient does not
appear to share the same process group id as the other two processes,
and I can't see any way of linking them through PPIDs, process groups,
tty groups, or anything else like that. I'd like to know if I'm missing
something here... 

-Adam 
 

Links:
--
[1]
mailto:sven.falem...@gmail.com

Re: dhclient

[Theo de Raadt]

 Using pkill(1) correctly should be more efficient than opening a
 file, reading its contents, then passing those as an argument to
 kill(1). 

None of the mechanisms removes the race.

However, of all the mechanisms, pidfiles are the worst.  They
even persist over reboot.

Re: dhclient

[Kevin Chadwick]

previously on this list Adam Thompson contributed:

 The flip side is that correct usage of pkill in the face of proctitle 
 alterations is far from obvious.

It's never been a problem for me and I thought avoiding pid files was
going against the grain. Glad I was doing it right after all. If you
can you use the commandline and especially have root acces then this
should be very easy. If not, you will simply configure and reboot.

Lets hope this doesn't become a problem with the take-up of cgroups and
monstrous sized /sbin/init or the rediculously
placed /usr/lib/systemd/systemd to cater/replace needlessly monstrously
sized linux initscripts. It would be really annoying if ps output became
needlessly dynamic but I guess any packages that decides to do that
probably won't be worth running anyway.

reflecting back on that tiny sentence it seems quite astonishing how
much dumb stuff *some* linux devs have managed to strive for in recent
years.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd

I have no idea why RTFM is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.

(Kevin Chadwick)

___

Re: dhclient

[Theo de Raadt]

 previously on this list Adam Thompson contributed:
 
  The flip side is that correct usage of pkill in the face of proctitle 
  alterations is far from obvious.
 
 It's never been a problem for me and I thought avoiding pid files was
 going against the grain. Glad I was doing it right after all. If you
 can you use the commandline and especially have root acces then this
 should be very easy. If not, you will simply configure and reboot.
 
 Lets hope this doesn't become a problem with the take-up of cgroups and
 monstrous sized /sbin/init or the rediculously
 placed /usr/lib/systemd/systemd to cater/replace needlessly monstrously
 sized linux initscripts. It would be really annoying if ps output became
 needlessly dynamic but I guess any packages that decides to do that
 probably won't be worth running anyway.
 
 reflecting back on that tiny sentence it seems quite astonishing how
 much dumb stuff *some* linux devs have managed to strive for in recent
 years.

Pushing complexity into a captured market is a good way to become
rich.

It worked for Microsoft and Apple, and some new boys are trying the
same recipe.

On the other hand, it has backfired before too...

Re: dhclient

[Jan Stary]

On Mar 25 11:19:12, sven.falem...@gmail.com wrote:
 Dealing with the removal of user script for dhclient is ok.
 On the other where's the PID file of this daemon 
 This soft answer HUP,INT.QUIT,USR1 et 2 yet i dont find a way to get
 the pid (listing process is dirty)

No it's not: pkill(1), pgrep(1).

 Is there a reason for dhclient
 to not have a --pid-file or at least a default one in
 /var/run/dhclient.$if.pid ?

Yes.

Re: dhclient

[sven falempin]

On Tue, Mar 25, 2014 at 1:11 PM, Jan Stary h...@stare.cz wrote:
 On Mar 25 11:19:12, sven.falem...@gmail.com wrote:
 Dealing with the removal of user script for dhclient is ok.
 On the other where's the PID file of this daemon 
 This soft answer HUP,INT.QUIT,USR1 et 2 yet i dont find a way to get
 the pid (listing process is dirty)

 No it's not: pkill(1), pgrep(1).

#  ps auxww | grep dhclient
root 21826  0.0  0.1   776   396 ??  Is 3:33PM0:00.01
dhclient: vr0 [priv] (dhclient)
_dhcp12556  0.0  0.1   928   500 ??  Is 3:33PM0:00.01
dhclient: vr0 (dhclient)
# pgrep -f dhclient: vr0 [priv] (dhclient)
# pgrep -f dhclient: vr0 [priv]
# pgrep -f dhclient: vr0
12556
21826


Where do I kill ? (there is also a few other dhclient running)


 Is there a reason for dhclient
 to not have a --pid-file or at least a default one in
 /var/run/dhclient.$if.pid ?

 Yes.


Would you please gives at least one reason ?



-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: dhclient

[Josh Grosse]

On 2014-03-25 14:49, sven falempin wrote:


# pgrep -f dhclient: vr0 [priv] (dhclient)
# pgrep -f dhclient: vr0 [priv]
# pgrep -f dhclient: vr0
12556
21826


Where do I kill ? (there is also a few other dhclient running)


kill(1) isn't actually required.  Try:

# ifconfig vr0 down

Re: dhclient

[sven falempin]

On Tue, Mar 25, 2014 at 3:08 PM, Josh Grosse j...@jggimi.homeip.net wrote:
 On 2014-03-25 14:49, sven falempin wrote:

 # pgrep -f dhclient: vr0 [priv] (dhclient)
 # pgrep -f dhclient: vr0 [priv]
 # pgrep -f dhclient: vr0
 12556
 21826


 Where do I kill ? (there is also a few other dhclient running)


 kill(1) isn't actually required.  Try:

 # ifconfig vr0 down

i would like to throw HUP,  kill -HUP



-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: dhclient

[Adam Thompson]

On Tue 25 Mar 2014 02:08:17 PM CDT, Josh Grosse wrote:

On 2014-03-25 14:49, sven falempin wrote:


# pgrep -f dhclient: vr0 [priv] (dhclient)
# pgrep -f dhclient: vr0 [priv]
# pgrep -f dhclient: vr0
12556
21826


Where do I kill ? (there is also a few other dhclient running)


kill(1) isn't actually required.  Try:

# ifconfig vr0 down



===
TL;DR version: it doesn't appear to matter which one gets signaled with 
HUP, but I can see that it might make a difference for the other 
signals.

===

That actually causes problems if you need the link to stay up while 
changing from DHCP to static assignment; my cable modem does weird 
things every time it loses carrier on the ethernet side.
Besides, the OP was asking which process to send a signal to when he 
wants to control dhclient's behaviour, not just how to terminate the 
process outright.


As it happens, I agree that having a PID file is an easy solution for 
daemons (like this) that fork and/or modify their proctitle.  It's not 
entirely clean, as there's no 100%-standard place to put pidfiles, and 
they don't always get cleaned up correctly.
The flip side is that correct usage of pkill in the face of proctitle 
alterations is far from obvious.  Requiring that skill just to signal a 
daemon seems to me about as sensible as requiring intimate knowledge of 
find(1) just to view a directory listing.


(...says the guy who still occasionally kills entire systems by 
accident when he tries to use pkill for anything complicated.  I'm good 
with find(1), thanks!)


On the other hand, dhclient hasn't written a pidfile since 2004 and a 
missing pidfile is not exactly a common complaint.

There are two answers:
   1. you can figure out which is the parent/child fairly easily 
through ps(1) output.  Admittedly this is not trivial to do in a 
script, but certainly possible.  Also, you only have to figure it out 
once, then apply that pattern to grep.  e.g.  PID=$(ps alxww|awk 
'$3==1  $13~/^dhclient: vr0/ {print $2}')
   2. use dhcpcd from ports/packages if you want all the bells and 
whistles.


Oh.  Actually, now I see sven's point - there are always at least two 
processes with PPID=1 and the docs don't specify which one responds to 
signals.  That's a bug in the manpage, at the very least.


Sven: you should probably file a bugreport against dhclient for that, 
the docs should be clear.  Preferably by including a patch, but even 
just suggested wording that would make sense to you is good.


--
-Adam Thompson
athom...@athompso.net

Re: dhclient

[Jan Stary]

On Mar 25 14:49:23, sven.falem...@gmail.com wrote:
 On Tue, Mar 25, 2014 at 1:11 PM, Jan Stary h...@stare.cz wrote:
  On Mar 25 11:19:12, sven.falem...@gmail.com wrote:
  Dealing with the removal of user script for dhclient is ok.
  On the other where's the PID file of this daemon 
  This soft answer HUP,INT.QUIT,USR1 et 2 yet i dont find a way to get
  the pid (listing process is dirty)
 
  No it's not: pkill(1), pgrep(1).
 
 #  ps auxww | grep dhclient
 root 21826  0.0  0.1   776   396 ??  Is 3:33PM0:00.01
 dhclient: vr0 [priv] (dhclient)
 _dhcp12556  0.0  0.1   928   500 ??  Is 3:33PM0:00.01
 dhclient: vr0 (dhclient)
 # pgrep -f dhclient: vr0 [priv] (dhclient)
 # pgrep -f dhclient: vr0 [priv]
 # pgrep -f dhclient: vr0
 12556
 21826
 
 Where do I kill ? (there is also a few other dhclient running)

Have you actually read pill(1)?

  Is there a reason for dhclient
  to not have a --pid-file or at least a default one in
  /var/run/dhclient.$if.pid ?
 
  Yes.
 
 Would you please gives at least one reason ?

Think hard. Think harder.

Re: dhclient

[Theo de Raadt]

 On Tue, Mar 25, 2014 at 1:11 PM, Jan Stary h...@stare.cz wrote:
  On Mar 25 11:19:12, sven.falem...@gmail.com wrote:
  Dealing with the removal of user script for dhclient is ok.
  On the other where's the PID file of this daemon 
  This soft answer HUP,INT.QUIT,USR1 et 2 yet i dont find a way to get
  the pid (listing process is dirty)
 
  No it's not: pkill(1), pgrep(1).
 
 #  ps auxww | grep dhclient
 root 21826  0.0  0.1   776   396 ??  Is 3:33PM0:00.01
 dhclient: vr0 [priv] (dhclient)
 _dhcp12556  0.0  0.1   928   500 ??  Is 3:33PM0:00.01
 dhclient: vr0 (dhclient)
 # pgrep -f dhclient: vr0 [priv] (dhclient)
 # pgrep -f dhclient: vr0 [priv]
 # pgrep -f dhclient: vr0
 12556
 21826
 
 
 Where do I kill ? (there is also a few other dhclient running)

All of our privsep daemons are specifically designed to accept all
signals at any process, and then handle things properly.

(Unless there are bugs.. hopefully not)

Re: dhclient

[sven falempin]

On Tue, Mar 25, 2014 at 3:44 PM, Adam Thompson athom...@athompso.net wrote:
 On Tue 25 Mar 2014 02:08:17 PM CDT, Josh Grosse wrote:

 On 2014-03-25 14:49, sven falempin wrote:

 # pgrep -f dhclient: vr0 [priv] (dhclient)
 # pgrep -f dhclient: vr0 [priv]
 # pgrep -f dhclient: vr0
 12556
 21826


 Where do I kill ? (there is also a few other dhclient running)


 kill(1) isn't actually required.  Try:

 # ifconfig vr0 down


 ===
 TL;DR version: it doesn't appear to matter which one gets signaled with HUP,
 but I can see that it might make a difference for the other signals.
 ===

 That actually causes problems if you need the link to stay up while changing
 from DHCP to static assignment; my cable modem does weird things every time
 it loses carrier on the ethernet side.
 Besides, the OP was asking which process to send a signal to when he wants
 to control dhclient's behaviour, not just how to terminate the process
 outright.

 As it happens, I agree that having a PID file is an easy solution for
 daemons (like this) that fork and/or modify their proctitle.  It's not
 entirely clean, as there's no 100%-standard place to put pidfiles, and they
 don't always get cleaned up correctly.

well openBSD is so neat it provides a nice call:

http://www.openbsd.org/cgi-bin/man.cgi?query=pidfileapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html

but i failed to patch :'(  this make the dhclient quit instead of
going background, the fact there is two process may also explain why
there is no pidfile. One is root he other dropped privilege, all of
this is just giving me a headache at the moment.

Index: dhclient.c
===
RCS file: /cvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.260
diff -u -p -r1.260 dhclient.c
--- dhclient.c  15 Jul 2013 14:03:01 -  1.260
+++ dhclient.c  25 Mar 2014 19:50:10 -
@@ -61,6 +61,7 @@
 #include poll.h
 #include pwd.h
 #include resolv.h
+#include util.h

 #defineCLIENT_PATH PATH=/usr/bin:/usr/sbin:/bin:/sbin
 #define DEFAULT_LEASE_TIME 43200   /* 12 hours. */
@@ -1742,6 +1743,7 @@ void
 go_daemon(void)
 {
static int state = 0;
+char* pidname = NULL;

if (no_daemon || state)
return;
@@ -1762,6 +1764,12 @@ go_daemon(void)
close(nullfd);
nullfd = -1;
}
+
+if (!asprintf(pidname, dhclient.%s, ifi-name))
+error(pidname);
+if (pidfile(pidname))
+error(pidfile);
+free(pidname);

/* Catch stuff that might be trying to terminate the program. */
signal(SIGHUP, sighdlr);


 The flip side is that correct usage of pkill in the face of proctitle
 alterations is far from obvious.  Requiring that skill just to signal a
 daemon seems to me about as sensible as requiring intimate knowledge of
 find(1) just to view a directory listing.

 (...says the guy who still occasionally kills entire systems by accident
 when he tries to use pkill for anything complicated.  I'm good with find(1),
 thanks!)

 On the other hand, dhclient hasn't written a pidfile since 2004 and a
 missing pidfile is not exactly a common complaint.
 There are two answers:
1. you can figure out which is the parent/child fairly easily through
 ps(1) output.  Admittedly this is not trivial to do in a script, but
 certainly possible.  Also, you only have to figure it out once, then apply
 that pattern to grep.  e.g.  PID=$(ps alxww|awk '$3==1  $13~/^dhclient:
 vr0/ {print $2}')
2. use dhcpcd from ports/packages if you want all the bells and whistles.

 Oh.  Actually, now I see sven's point - there are always at least two
 processes with PPID=1 and the docs don't specify which one responds to
 signals.  That's a bug in the manpage, at the very least.

 Sven: you should probably file a bugreport against dhclient for that, the
 docs should be clear.  Preferably by including a patch, but even just
 suggested wording that would make sense to you is good.

 --
 -Adam Thompson
 athom...@athompso.net




-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: dhclient

[Theo de Raadt]

 well openBSD is so neat it provides a nice call:
 
 http://www.openbsd.org/cgi-bin/man.cgi?query=pidfileapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html
 
 but i failed to patch :'(  this make the dhclient quit instead of
 going background, the fact there is two process may also explain why
 there is no pidfile. One is root he other dropped privilege, all of
 this is just giving me a headache at the moment.

pidfile() is a dangerous subsystem.  The files stay around long after
the process has died.  There is no interlock.

If you signal a process lists in a pidfile, who knows what you are
sending a signal to.  Since the signals are often termination related,
this can have dangerous effects.

We don't add more pidfile use, we actually remove them where we can.
This mechanism has applicability in some situations, but in the big
picture it is sloppy practice.

Re: dhclient

[Adam Thompson]

On Tue 25 Mar 2014 03:02:19 PM CDT, Theo de Raadt wrote:

[...] the fact there is two process may also explain why
there is no pidfile. One is root he other dropped privilege, all of
this is just giving me a headache at the moment.



Based on 5.4-RELEASE, then, since I agree the situation is confusing:


--- dhclient.8  Sun Jul 21 11:43:44 2013
+++ dhclient.8.new  Tue Mar 25 15:07:52 2014
@@ -255,7 +255,9 @@
.Sh SIGNALS
While running,
.Nm
-reacts to a few different signals:
+uses a privilege-separation model, so there will be two processes (one 
with

+[priv] in its process title and one without),
+either of which will react to a few different signals:
.Bl -tag -width USR1, USR2XXX
.It Dv HUP
On receiving



(I can't find an mdoc(7) equivalent to PRE for formatting the 
[priv] token.  Suggestions welcome.)



--
-Adam Thompson
athom...@athompso.net

Re: dhclient

[Ingo Schwarze]

Hi Adam,

Adam Thompson wrote on Tue, Mar 25, 2014 at 03:11:49PM -0500:

 .Sh SIGNALS
 While running,
 .Nm
 uses a privilege-separation model, so there will be two processes
 (one with [priv] in its process title and one without),
 either of which will react to a few different signals:
 
 (I can't find an mdoc(7) equivalent to PRE

The mdoc(7) equivalent of pre is

  .Bd -literal

However, you cannot use that here because pre (and .Bd)
are for block displays, while you want an in-line element.

In HTML, you might use samp.  In mdoc(7), there is no
semantic markup for program output, so you'd fall back to
physical formatting, probably with

  .Li

 for formatting the [priv] token.  Suggestions welcome.)

In mdoc(7), you could also choose to not mark it up at all.

I'm not commenting on your (mangled) diff itself.  It looks
a bit like documenting a general principle in a special place,
but i'm not sure what to think.

Yours,
  Ingo

Re: dhclient

[Holger Glaess]

Am 03.02.2014 17:54, schrieb Kenneth Westerback:

Reactivating the dhclient-script is not going to happen.

I am interested in what you would see syntax in dhclient.conf looking like.

Would multi-path routing modifications to all routes be needed? How should this
be combined with supersede/default/append commands for the relevant
options? Would it apply to all members of each option, or route by
route?

If all else fails you can always use the ISC dhclient from ports to
gain access to a dhclient-script again.

 Ken

On 31 January 2014 02:04, Holger Glaess gla...@glaessixs.de wrote:

Am 30.01.2014 13:10, schrieb Giancarlo Razzolini:


Em 29-01-2014 18:13, Holger Glaess escreveu:

hi

i try to setup and multipath configuration with 2 line provider

1 cable with dhcp(client)
1 with pppoe

just dynamic ips.

the pppoe config create well the new default route with -math
but dhclient dont.

[snip pppoe config]

inet 0.0.0.0 255.255.255.255 NONE \
pppoedev msk0 authproto pap \
authname 'bla@blub' authkey 'blub' up
dest 0.0.0.1
!/sbin/route add -mpath default -ifp pppoe0 0.0.0.1

[/snip pppoe config]


after a couple of days i found that the dhclient not use the
dhclient-script since 5.3 anymore.


so how can i setup the -math option at the dhclient config ?


or it is possible to add some lines in dhclient that he check the
sysctl and , if net.inet.ip.multipath=1 ,
he add the default route with ( for ) multipathing.






holger


Check if your dhcp server always gives you the same router ip address.
If so, you can tweak with your dhclient.conf to reject and not ask for
routers, and then set it up manually as you do in your hostname.pppoe0.
And you can always run a script that is run after the dhcp negotiation,
looks for the gateway related entry, deletes it and then re-adds it with
the mpath modifier. There are a lot of options in this regard.

Cheers,


hi

shure , i can write a wrap around solution for the but this not the
dynamic way like
pppoe or  dhcp  to get and set ips.

i'm not the C programmer but i think  it is not mutch work to add a solution
in dhclient,
or as option to reaktivate the dhclient-script part.


holger

hi

at moment i have following setup

# cat hostname.pppoe0
inet 0.0.0.0 255.255.255.255 NONE \
pppoedev msk0 authproto pap \
authname 'bla' authkey 'blub' up
dest 0.0.0.1
#!/sbin/route add default -ifp pppoe0 0.0.0.1
#!/sbin/route add -inet6 default -ifp pppoe0 ::0.0.0.1
#
!/sbin/route add -mpath default -ifp pppoe0 0.0.0.1
!/sbin/route add -inet6 -mpath default -ifp pppoe0 ::0.0.0.1

# cat /etc/hostname.vlan5
dhcp vlandev msk1
!/sbin/route add -mpath default xww.x.yy.zz.


# cat /etc/dhclient.conf

timeout 15;
retry 5;
reboot 2;
select-timeout 5;
initial-interval 2;


interface vlan5 {
ignore domain-name-servers;
ignore host-name;
ignore routers;
send dhcp-lease-time 3600;
request subnet-mask, broadcast-address, time-offset, routers,
domain-name-servers, host-name, ntp-servers;
}


it work for a while with the mpath settings after the start but if the 
dhclient renew his setting he set the default route
i his standard way , hi ignore the settings in his config ( is this 
right ? )



holger

Re: dhclient

[Kenneth Westerback]

On 5 February 2014 06:35, Holger Glaess gla...@glaessixs.de wrote:
 Am 03.02.2014 17:54, schrieb Kenneth Westerback:

 Reactivating the dhclient-script is not going to happen.

 I am interested in what you would see syntax in dhclient.conf looking
 like.

 Would multi-path routing modifications to all routes be needed? How should
 this
 be combined with supersede/default/append commands for the relevant
 options? Would it apply to all members of each option, or route by
 route?

 If all else fails you can always use the ISC dhclient from ports to
 gain access to a dhclient-script again.

  Ken

 On 31 January 2014 02:04, Holger Glaess gla...@glaessixs.de wrote:

 Am 30.01.2014 13:10, schrieb Giancarlo Razzolini:

 Em 29-01-2014 18:13, Holger Glaess escreveu:

 hi

 i try to setup and multipath configuration with 2 line provider

 1 cable with dhcp(client)
 1 with pppoe

 just dynamic ips.

 the pppoe config create well the new default route with -math
 but dhclient dont.

 [snip pppoe config]

 inet 0.0.0.0 255.255.255.255 NONE \
 pppoedev msk0 authproto pap \
 authname 'bla@blub' authkey 'blub' up
 dest 0.0.0.1
 !/sbin/route add -mpath default -ifp pppoe0 0.0.0.1

 [/snip pppoe config]


 after a couple of days i found that the dhclient not use the
 dhclient-script since 5.3 anymore.


 so how can i setup the -math option at the dhclient config ?


 or it is possible to add some lines in dhclient that he check the
 sysctl and , if net.inet.ip.multipath=1 ,
 he add the default route with ( for ) multipathing.






 holger

 Check if your dhcp server always gives you the same router ip address.
 If so, you can tweak with your dhclient.conf to reject and not ask for
 routers, and then set it up manually as you do in your hostname.pppoe0.
 And you can always run a script that is run after the dhcp negotiation,
 looks for the gateway related entry, deletes it and then re-adds it with
 the mpath modifier. There are a lot of options in this regard.

 Cheers,

 hi

 shure , i can write a wrap around solution for the but this not the
 dynamic way like
 pppoe or  dhcp  to get and set ips.

 i'm not the C programmer but i think  it is not mutch work to add a
 solution
 in dhclient,
 or as option to reaktivate the dhclient-script part.


 holger

 hi

 at moment i have following setup

 # cat hostname.pppoe0

 inet 0.0.0.0 255.255.255.255 NONE \
 pppoedev msk0 authproto pap \
 authname 'bla' authkey 'blub' up
 dest 0.0.0.1
 #!/sbin/route add default -ifp pppoe0 0.0.0.1
 #!/sbin/route add -inet6 default -ifp pppoe0 ::0.0.0.1

 #
 !/sbin/route add -mpath default -ifp pppoe0 0.0.0.1
 !/sbin/route add -inet6 -mpath default -ifp pppoe0 ::0.0.0.1

 # cat /etc/hostname.vlan5
 dhcp vlandev msk1
 !/sbin/route add -mpath default xww.x.yy.zz.


 # cat /etc/dhclient.conf

 timeout 15;
 retry 5;
 reboot 2;
 select-timeout 5;
 initial-interval 2;


 interface vlan5 {
 ignore domain-name-servers;
 ignore host-name;
 ignore routers;
 send dhcp-lease-time 3600;
 request subnet-mask, broadcast-address, time-offset, routers,
 domain-name-servers, host-name, ntp-servers;
 }


 it work for a while with the mpath settings after the start but if the
 dhclient renew his setting he set the default route
 i his standard way , hi ignore the settings in his config ( is this right ?
 )

I've never tried mixing vlans and dhclient, so I'm not 100% sure what
the behaviour is going to be. :-)

If you can run dhclient from the command line, and specify the '-L' option and a
file location, I'd be interested in what the offered and effective
dhcp leases look
like. Also a tcpdump of the interaction could supply valuable
information. Again,
not sure of tcpdump vs vlan interfaces, but something like

tcpdump -i msk1 -s 2000 -w filename

running when you start dhclient should generate a useful file I can peruse.

After that I can send you some dhclient debugging diffs if necessary.

 Ken



 holger

Re: dhclient

[Kenneth Westerback]

Reactivating the dhclient-script is not going to happen.

I am interested in what you would see syntax in dhclient.conf looking like.

Would multi-path routing modifications to all routes be needed? How should this
be combined with supersede/default/append commands for the relevant
options? Would it apply to all members of each option, or route by
route?

If all else fails you can always use the ISC dhclient from ports to
gain access to a dhclient-script again.

 Ken

On 31 January 2014 02:04, Holger Glaess gla...@glaessixs.de wrote:
 Am 30.01.2014 13:10, schrieb Giancarlo Razzolini:

 Em 29-01-2014 18:13, Holger Glaess escreveu:

 hi

 i try to setup and multipath configuration with 2 line provider

 1 cable with dhcp(client)
 1 with pppoe

 just dynamic ips.

 the pppoe config create well the new default route with -math
 but dhclient dont.

 [snip pppoe config]

 inet 0.0.0.0 255.255.255.255 NONE \
 pppoedev msk0 authproto pap \
 authname 'bla@blub' authkey 'blub' up
 dest 0.0.0.1
 !/sbin/route add -mpath default -ifp pppoe0 0.0.0.1

 [/snip pppoe config]


 after a couple of days i found that the dhclient not use the
 dhclient-script since 5.3 anymore.


 so how can i setup the -math option at the dhclient config ?


 or it is possible to add some lines in dhclient that he check the
 sysctl and , if net.inet.ip.multipath=1 ,
 he add the default route with ( for ) multipathing.






 holger

 Check if your dhcp server always gives you the same router ip address.
 If so, you can tweak with your dhclient.conf to reject and not ask for
 routers, and then set it up manually as you do in your hostname.pppoe0.
 And you can always run a script that is run after the dhcp negotiation,
 looks for the gateway related entry, deletes it and then re-adds it with
 the mpath modifier. There are a lot of options in this regard.

 Cheers,


 hi

 shure , i can write a wrap around solution for the but this not the
 dynamic way like
 pppoe or  dhcp  to get and set ips.

 i'm not the C programmer but i think  it is not mutch work to add a solution
 in dhclient,
 or as option to reaktivate the dhclient-script part.


 holger

Re: dhclient

[Giancarlo Razzolini]

Em 03-02-2014 14:54, Kenneth Westerback escreveu:
 Reactivating the dhclient-script is not going to happen.

 I am interested in what you would see syntax in dhclient.conf looking like.

 Would multi-path routing modifications to all routes be needed? How should 
 this
 be combined with supersede/default/append commands for the relevant
 options? Would it apply to all members of each option, or route by
 route?

 If all else fails you can always use the ISC dhclient from ports to
 gain access to a dhclient-script again.

  Ken

 On 31 January 2014 02:04, Holger Glaess gla...@glaessixs.de wrote:
 Am 30.01.2014 13:10, schrieb Giancarlo Razzolini:

 Em 29-01-2014 18:13, Holger Glaess escreveu:
 hi

 i try to setup and multipath configuration with 2 line provider

 1 cable with dhcp(client)
 1 with pppoe

 just dynamic ips.

 the pppoe config create well the new default route with -math
 but dhclient dont.

 [snip pppoe config]

 inet 0.0.0.0 255.255.255.255 NONE \
 pppoedev msk0 authproto pap \
 authname 'bla@blub' authkey 'blub' up
 dest 0.0.0.1
 !/sbin/route add -mpath default -ifp pppoe0 0.0.0.1

 [/snip pppoe config]


 after a couple of days i found that the dhclient not use the
 dhclient-script since 5.3 anymore.


 so how can i setup the -math option at the dhclient config ?


 or it is possible to add some lines in dhclient that he check the
 sysctl and , if net.inet.ip.multipath=1 ,
 he add the default route with ( for ) multipathing.






 holger

 Check if your dhcp server always gives you the same router ip address.
 If so, you can tweak with your dhclient.conf to reject and not ask for
 routers, and then set it up manually as you do in your hostname.pppoe0.
 And you can always run a script that is run after the dhcp negotiation,
 looks for the gateway related entry, deletes it and then re-adds it with
 the mpath modifier. There are a lot of options in this regard.

 Cheers,

 hi

 shure , i can write a wrap around solution for the but this not the
 dynamic way like
 pppoe or  dhcp  to get and set ips.

 i'm not the C programmer but i think  it is not mutch work to add a solution
 in dhclient,
 or as option to reaktivate the dhclient-script part.


 holger
Yep, it would be very messy to add the multipath option to the dhclient
configuration. But I believe that before dhclient gets changed, the
whole multipath thing needs some love. I'm using it for some years now,
but there where lots of issues the documentation would not cover. I want
to take some time soon to address them. It is a great feature that is
not widely used yet.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: dhclient

[Remi Locherer]

Quoting Holger Glaess gla...@glaessixs.de:


Am 30.01.2014 13:10, schrieb Giancarlo Razzolini:

Em 29-01-2014 18:13, Holger Glaess escreveu:

hi

i try to setup and multipath configuration with 2 line provider

1 cable with dhcp(client)
1 with pppoe

just dynamic ips.

the pppoe config create well the new default route with -math
but dhclient dont.

[snip pppoe config]

inet 0.0.0.0 255.255.255.255 NONE \
pppoedev msk0 authproto pap \
authname 'bla@blub' authkey 'blub' up
dest 0.0.0.1
!/sbin/route add -mpath default -ifp pppoe0 0.0.0.1

[/snip pppoe config]


after a couple of days i found that the dhclient not use the
dhclient-script since 5.3 anymore.


so how can i setup the -math option at the dhclient config ?


or it is possible to add some lines in dhclient that he check the
sysctl and , if net.inet.ip.multipath=1 ,
he add the default route with ( for ) multipathing.






holger


Check if your dhcp server always gives you the same router ip address.
If so, you can tweak with your dhclient.conf to reject and not ask for
routers, and then set it up manually as you do in your hostname.pppoe0.
And you can always run a script that is run after the dhcp negotiation,
looks for the gateway related entry, deletes it and then re-adds it with
the mpath modifier. There are a lot of options in this regard.

Cheers,



hi

shure , i can write a wrap around solution for the but this not the  
dynamic way like

pppoe or  dhcp  to get and set ips.

i'm not the C programmer but i think  it is not mutch work to add a  
solution in dhclient,

or as option to reaktivate the dhclient-script part.


holger


You can get an event and trigger your acctions as before with the  
dhclient-script
by watching changes in the routing table. Something like this might  
work for you:


# route -n monitor | { while read l; do [[ $l = RTM_NEWADDR* ]]   
echo do your stuff here; done }

Re: dhclient

[Giancarlo Razzolini]

Em 29-01-2014 18:13, Holger Glaess escreveu:
 hi

 i try to setup and multipath configuration with 2 line provider

 1 cable with dhcp(client)
 1 with pppoe

 just dynamic ips.

 the pppoe config create well the new default route with -math
 but dhclient dont.

 [snip pppoe config]

 inet 0.0.0.0 255.255.255.255 NONE \
 pppoedev msk0 authproto pap \
 authname 'bla@blub' authkey 'blub' up
 dest 0.0.0.1
 !/sbin/route add -mpath default -ifp pppoe0 0.0.0.1

 [/snip pppoe config]


 after a couple of days i found that the dhclient not use the
 dhclient-script since 5.3 anymore.


 so how can i setup the -math option at the dhclient config ?


 or it is possible to add some lines in dhclient that he check the
 sysctl and , if net.inet.ip.multipath=1 ,
 he add the default route with ( for ) multipathing.






 holger

Check if your dhcp server always gives you the same router ip address.
If so, you can tweak with your dhclient.conf to reject and not ask for
routers, and then set it up manually as you do in your hostname.pppoe0.
And you can always run a script that is run after the dhcp negotiation,
looks for the gateway related entry, deletes it and then re-adds it with
the mpath modifier. There are a lot of options in this regard.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: dhclient

[Holger Glaess]

Am 30.01.2014 13:10, schrieb Giancarlo Razzolini:

Em 29-01-2014 18:13, Holger Glaess escreveu:

hi

i try to setup and multipath configuration with 2 line provider

1 cable with dhcp(client)
1 with pppoe

just dynamic ips.

the pppoe config create well the new default route with -math
but dhclient dont.

[snip pppoe config]

inet 0.0.0.0 255.255.255.255 NONE \
pppoedev msk0 authproto pap \
authname 'bla@blub' authkey 'blub' up
dest 0.0.0.1
!/sbin/route add -mpath default -ifp pppoe0 0.0.0.1

[/snip pppoe config]


after a couple of days i found that the dhclient not use the
dhclient-script since 5.3 anymore.


so how can i setup the -math option at the dhclient config ?


or it is possible to add some lines in dhclient that he check the
sysctl and , if net.inet.ip.multipath=1 ,
he add the default route with ( for ) multipathing.






holger


Check if your dhcp server always gives you the same router ip address.
If so, you can tweak with your dhclient.conf to reject and not ask for
routers, and then set it up manually as you do in your hostname.pppoe0.
And you can always run a script that is run after the dhcp negotiation,
looks for the gateway related entry, deletes it and then re-adds it with
the mpath modifier. There are a lot of options in this regard.

Cheers,



hi

shure , i can write a wrap around solution for the but this not the 
dynamic way like

pppoe or  dhcp  to get and set ips.

i'm not the C programmer but i think  it is not mutch work to add a 
solution in dhclient,

or as option to reaktivate the dhclient-script part.


holger

Re: dhclient exiting on lease expiry

[Kenneth R Westerback]

On Mon, May 13, 2013 at 09:40:59AM +0100, Mike Williams wrote:
 Hi,
 
 I have been upgrading my machines to 5.3 this weekend and I am
 seeing some strange behaviours with dhclient.  The config is simple:
 
 /etc/dhclient.conf
 send host-name pc-1;
 request subnet-mask, broadcast-address, routers, domain-name,
 domain-name-servers, host-name;
 
 (FWIW The dhcp server serves up constant IP addresses based on the MAC)
 
 There is only one i/f with the wrinkle that I am temporarily running
 an inet alias off the i/f as well:
 
 /etc/hostname.re0
 dhcp NONE NONE NONE NONE
 inet alias 192.168.67.24 255.255.255.0 NONE

Upgraded from what version?

Yes, the 5.3 dhclient will remove all aliases as part of taking
control of the interface. So a renewal will remove the interface. In
fact adding the alias should either cause dhclient to exit, or the
alias will be removed when the lease is obtained.

This behaviour was mentioned in the release notes:

all existing addresses on the interface are deleted when binding
a new lease.

 
 Up to the upgrade this was ticking along with no problems.
 
 Now, whenever the lease expires the dhclient daemon exits taking the
 inet alias with it, and I have no connectivity.  I can restart
 dhclient but this leaves the inet alias dead.
 
 /var/log/daemon shows the following (*):
 
 May 13 03:50:46 pc-1 dhclient[28001]: DHCPREQUEST on re0 to
 192.168.67.2 port 67
 May 13 03:50:46 pc-1 dhclient[28001]: DHCPACK from 192.168.67.2
 (00:40:63:dd:9f:c0)
 ...
 May 13 03:50:46 pc-1 dhclient[28001]: 192.168.67.40, not
 192.168.67.40, deleted from re0; exiting

Now that is an unfortunate and insufficiently useful error message.

 
 However if I force a renewal with pkill -HUP dhclient I see this:
 
 May 13 09:10:41 pc-1 dhclient[25646]: bound to 192.168.67.40 --
 renewal in 43200 seconds.

And that does NOT remove the alias? That would be contrary to my
expectation.

 
 So it looks like an issue when the lease times out.  There was
 nothing in the upgrade notes, and a search through the lists on
 marc.info only brings up to release note improvements, nothing about
 any configuration changes that may be needed.
 
 (*) For full context I have avahi-daemon installed so the full
 daemon log for the time the lease expired is as follows:
 
 May 13 01:32:24 pc-1 identd[23433]: Connection from xxx.yyy.zzz
 May 13 03:50:46 pc-1 dhclient[28001]: DHCPREQUEST on re0 to
 192.168.67.2 port 67
 May 13 03:50:46 pc-1 dhclient[28001]: DHCPACK from 192.168.67.2
 (00:40:63:dd:9f:c0)
 May 13 03:50:46 pc-1 avahi-daemon[10755]: Withdrawing address record
 for 192.168.67.40 on re0.
 May 13 03:50:46 pc-1 avahi-daemon[10755]: Withdrawing address record
 for 192.168.67.24 on re0.
 May 13 03:50:46 pc-1 avahi-daemon[10755]: Leaving mDNS multicast
 group on interface re0.IPv4 with address 192.168.67.24.
 May 13 03:50:46 pc-1 avahi-daemon[10755]: IP_DROP_MEMBERSHIP failed:
 Can't assign requested address
 May 13 03:50:46 pc-1 avahi-daemon[10755]: Interface re0.IPv4 no
 longer relevant for mDNS.
 May 13 03:50:46 pc-1 avahi-daemon[10755]: Joining mDNS multicast
 group on interface re0.IPv4 with address 192.168.67.40.
 May 13 03:50:46 pc-1 avahi-daemon[10755]: New relevant interface
 re0.IPv4 for mDNS.
 May 13 03:50:46 pc-1 avahi-daemon[10755]: Registering new address
 record for 192.168.67.40 on re0.IPv4.
 May 13 03:50:46 pc-1 dhclient[28001]: 192.168.67.40, not
 192.168.67.40, deleted from re0; exiting
 May 13 03:50:46 pc-1 avahi-daemon[10755]: Withdrawing address record
 for 192.168.67.40 on re0.
 May 13 03:50:46 pc-1 avahi-daemon[10755]: Leaving mDNS multicast
 group on interface re0.IPv4 with address 192.168.67.40.
 May 13 03:50:46 pc-1 avahi-daemon[10755]: IP_DROP_MEMBERSHIP failed:
 Can't assign requested address
 May 13 03:50:46 pc-1 avahi-daemon[10755]: Interface re0.IPv4 no
 longer relevant for mDNS.
 May 13 04:10:10 pc-1 ntpd[18186]: 0 out of 1 peers valid
 
 Let the beatings with the clue bat begin.
 
 -- 
 Mike
 

Not sure what Avahi is doing. :-) If you capture the output from
'route monitor', you can see what RTM_NEWADDR, RTM_DELADDR, etc.
messages are flying around that dhclient will be paying attention
to.

Bottom line: alias and dhclient do not play well together. They never have
in a general sense, and 5.3 tightens things up significantly. We are looking
at making them work together safely and reliably.

 Ken

Re: dhclient exiting on lease expiry

[Mike Williams]

On 05/13/13 15:19, Kenneth R Westerback wrote:

On Mon, May 13, 2013 at 09:40:59AM +0100, Mike Williams wrote:

Hi,

I have been upgrading my machines to 5.3 this weekend and I am
seeing some strange behaviours with dhclient.  The config is simple:

/etc/dhclient.conf
send host-name pc-1;
request subnet-mask, broadcast-address, routers, domain-name,
 domain-name-servers, host-name;

(FWIW The dhcp server serves up constant IP addresses based on the MAC)

There is only one i/f with the wrinkle that I am temporarily running
an inet alias off the i/f as well:

/etc/hostname.re0
dhcp NONE NONE NONE NONE
inet alias 192.168.67.24 255.255.255.0 NONE


Upgraded from what version?


5.2 release.


Yes, the 5.3 dhclient will remove all aliases as part of taking
control of the interface. So a renewal will remove the interface. In
fact adding the alias should either cause dhclient to exit, or the
alias will be removed when the lease is obtained.

This behaviour was mentioned in the release notes:

all existing addresses on the interface are deleted when binding
a new lease.


Ok, I can live with that, time to sort out the temporariness (sp?) of 
the alias.




Up to the upgrade this was ticking along with no problems.

Now, whenever the lease expires the dhclient daemon exits taking the
inet alias with it, and I have no connectivity.  I can restart
dhclient but this leaves the inet alias dead.

/var/log/daemon shows the following (*):

May 13 03:50:46 pc-1 dhclient[28001]: DHCPREQUEST on re0 to
192.168.67.2 port 67
May 13 03:50:46 pc-1 dhclient[28001]: DHCPACK from 192.168.67.2
(00:40:63:dd:9f:c0)
...
May 13 03:50:46 pc-1 dhclient[28001]: 192.168.67.40, not
192.168.67.40, deleted from re0; exiting


Now that is an unfortunate and insufficiently useful error message.


I feel a new tagline in the offing ;-)



However if I force a renewal with pkill -HUP dhclient I see this:

May 13 09:10:41 pc-1 dhclient[25646]: bound to 192.168.67.40 --
renewal in 43200 seconds.


And that does NOT remove the alias? That would be contrary to my
expectation.


No, it does remove the alias as well.  I was comparing the behaviour of 
a forced renewal to lease expiry on the dhclient daemon.




So it looks like an issue when the lease times out.  There was
nothing in the upgrade notes, and a search through the lists on
marc.info only brings up to release note improvements, nothing about
any configuration changes that may be needed.

(*) For full context I have avahi-daemon installed so the full
daemon log for the time the lease expired is as follows:

May 13 01:32:24 pc-1 identd[23433]: Connection from xxx.yyy.zzz
May 13 03:50:46 pc-1 dhclient[28001]: DHCPREQUEST on re0 to
192.168.67.2 port 67
May 13 03:50:46 pc-1 dhclient[28001]: DHCPACK from 192.168.67.2
(00:40:63:dd:9f:c0)
May 13 03:50:46 pc-1 avahi-daemon[10755]: Withdrawing address record
for 192.168.67.40 on re0.
May 13 03:50:46 pc-1 avahi-daemon[10755]: Withdrawing address record
for 192.168.67.24 on re0.
May 13 03:50:46 pc-1 avahi-daemon[10755]: Leaving mDNS multicast
group on interface re0.IPv4 with address 192.168.67.24.
May 13 03:50:46 pc-1 avahi-daemon[10755]: IP_DROP_MEMBERSHIP failed:
Can't assign requested address
May 13 03:50:46 pc-1 avahi-daemon[10755]: Interface re0.IPv4 no
longer relevant for mDNS.
May 13 03:50:46 pc-1 avahi-daemon[10755]: Joining mDNS multicast
group on interface re0.IPv4 with address 192.168.67.40.
May 13 03:50:46 pc-1 avahi-daemon[10755]: New relevant interface
re0.IPv4 for mDNS.
May 13 03:50:46 pc-1 avahi-daemon[10755]: Registering new address
record for 192.168.67.40 on re0.IPv4.
May 13 03:50:46 pc-1 dhclient[28001]: 192.168.67.40, not
192.168.67.40, deleted from re0; exiting
May 13 03:50:46 pc-1 avahi-daemon[10755]: Withdrawing address record
for 192.168.67.40 on re0.
May 13 03:50:46 pc-1 avahi-daemon[10755]: Leaving mDNS multicast
group on interface re0.IPv4 with address 192.168.67.40.
May 13 03:50:46 pc-1 avahi-daemon[10755]: IP_DROP_MEMBERSHIP failed:
Can't assign requested address
May 13 03:50:46 pc-1 avahi-daemon[10755]: Interface re0.IPv4 no
longer relevant for mDNS.
May 13 04:10:10 pc-1 ntpd[18186]: 0 out of 1 peers valid

Let the beatings with the clue bat begin.

--
Mike



Not sure what Avahi is doing. :-) If you capture the output from
'route monitor', you can see what RTM_NEWADDR, RTM_DELADDR, etc.
messages are flying around that dhclient will be paying attention
to.


Me neither, but there is a functional link and avahi does seem to be 
acting in relation to dhclient behaviour.  I provided the context if 
anyone had a light-bulb moment because of it.


I'll report what route monitor reports when the lease next expires.


Bottom line: alias and dhclient do not play well together. They never have
in a general sense, and 5.3 tightens things up significantly. We are looking
at making them work together safely and reliably.


Nice to hear, I'll sort myself out re aliases.

--
Mike

Re: DHCLIENT v5.3

[Jiri B]

On Wed, May 08, 2013 at 07:58:26PM -0700, Chris Cappuccio wrote:
 For now you'll need to call your dns script from dhclient. A system() will do 
 the trick.

Is planned to have an ability to fire a script/command from dhclient
in the future? I used to be putting on/off various dns servers for
my pdnsd setup...

j.

Re: DHCLIENT v5.3

[Kenneth R Westerback]

On Thu, May 09, 2013 at 07:38:55AM -0400, Jiri B wrote:
 On Wed, May 08, 2013 at 07:58:26PM -0700, Chris Cappuccio wrote:
  For now you'll need to call your dns script from dhclient. A system() will 
  do the trick.
 
 Is planned to have an ability to fire a script/command from dhclient
 in the future? I used to be putting on/off various dns servers for
 my pdnsd setup...
 
 j.

At the moment it is not planned.

 Ken

Re: DHCLIENT v5.3

[Chris Cappuccio]

For now you'll need to call your dns script from dhclient. A system() will do 
the trick.

Scott [8f27e...@gmail.com] wrote:
 Hi everyone,
 
 Migrated to v5.3. I had a mod to the former dhclient-script that would fire
 a wget to my dns provider, which in turn, would act as a dynamic update
 and cause my dns A records to be updated with the current IP address.
 This event-based hook-fire point was better than a time-based cron script
 as it only fired when a dhclient-script event occurred.
 
 I would like to carry the general idea forward but am unable to find a new
 v5.3 hook or fire point to nit my wget into.
 
 Any help greatly appreciated.
 
 With thanks,

-- 
Forget magic. Any technology distinguishable from divine power is
insufficiently advanced.

Re: dhclient drops address on re-exec in 5.3 bsd.rd

[Kenneth R Westerback]

On Sun, Apr 28, 2013 at 02:41:36PM -0400, David Higgs wrote:
 Confirmed in 5.3-current downloaded several minutes ago.
 
 Steps to reproduce:
 - Boot bsd.rd
 - Select upgrade, hit enter until dhclient gets and assigns an address
 - Complete upgrade or control-C, then restart the upgrade process
 - dhclient on 2nd run REMOVES the assigned address
 
 Probably affects the bsd.rd install option as well. This does not
 happen with 5.2 bsd.rd.
 
 Easy to work around, but probably not right.
 
 Thanks!
 
 --david
 

dhclient will *always* remove all existing address on interfaces it is
binding a lease to. Are you saying that the 2nd time around it is not
re-assigning the address? Is your easy workaround to re-run dhclient, or
is it something else?

As soon as some builds finish here I will try to reproduce.

 Ken

Re: dhclient drops address on re-exec in 5.3 bsd.rd

[Kenneth R Westerback]

On Sun, Apr 28, 2013 at 02:41:36PM -0400, David Higgs wrote:
 Confirmed in 5.3-current downloaded several minutes ago.
 
 Steps to reproduce:
 - Boot bsd.rd
 - Select upgrade, hit enter until dhclient gets and assigns an address
 - Complete upgrade or control-C, then restart the upgrade process
 - dhclient on 2nd run REMOVES the assigned address
 
 Probably affects the bsd.rd install option as well. This does not
 happen with 5.2 bsd.rd.
 
 Easy to work around, but probably not right.
 
 Thanks!
 
 --david
 

Can't reproduce on amd64 -current here. I did control-C after getting
dhclient lease, entered 'upgrade' at command prompt, and re-started
upgrade. dhclient worked fine. Checked 'ifconfig' and the expected
address was present.

So more info you what exactly you are doing, on what machine are
you doing it, and perhaps anything interesting in your dhclient.conf
would be helpful. Thanks.

 Ken

Re: dhclient drops address on re-exec in 5.3 bsd.rd

[David Higgs]

On Sun, Apr 28, 2013 at 4:00 PM, Kenneth R Westerback
kwesterb...@rogers.com wrote:
 On Sun, Apr 28, 2013 at 02:41:36PM -0400, David Higgs wrote:
 Confirmed in 5.3-current downloaded several minutes ago.

 Steps to reproduce:
 - Boot bsd.rd
 - Select upgrade, hit enter until dhclient gets and assigns an address
 - Complete upgrade or control-C, then restart the upgrade process
 - dhclient on 2nd run REMOVES the assigned address

 Probably affects the bsd.rd install option as well. This does not
 happen with 5.2 bsd.rd.

 Easy to work around, but probably not right.

 Thanks!

 --david


 Can't reproduce on amd64 -current here. I did control-C after getting
 dhclient lease, entered 'upgrade' at command prompt, and re-started
 upgrade. dhclient worked fine. Checked 'ifconfig' and the expected
 address was present.

 So more info you what exactly you are doing, on what machine are
 you doing it, and perhaps anything interesting in your dhclient.conf
 would be helpful. Thanks.

  Ken

I would have provided output, but I haven't figured out how to log
console output from VMware images.  Hopefully this will suffice:

i386 / 5.3-current / RAMDISK_CD #120

dhclient #1 (good)
DHCPDISCOVER on vic0 to 255.255.255.255 port 67 interval 1
DHCPOFFER from 172.16.223.254 (mac addr)
DHCPREQUEST on vic0 to 255.255.255.255 port 67
DHCPACK from 172.16.223.254 (mac addr)
bound to 172.16.223.131 -- renewal in 900 seconds

dhclient #2 (bad)
DHCPREQUEST on vic0 to 255.255.255.255 port 67
Active address (172.16.223.131) deleted; exiting

dhclient #3 (good)
DHCPREQUEST on vic0 to 255.255.255.255 port 67
DHCPACK from 172.16.223.254 (mac addr)
bound to 172.16.223.131 -- renewal in 900 seconds

amd64 / 5.3-current / RAMDISK_CD #132

dhclient #1 (good)
DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 1
DHCPOFFER from 172.16.223.254 (mac addr)
DHCPREQUEST on em0 to 255.255.255.255 port 67
DHCPACK from 172.16.223.254 (mac addr)
bound to 172.16.223.130 -- renewal in 900 seconds

dhclient #2 (still good)
DHCPREQUEST on em0 to 255.255.255.255 port 67
DHCPACK from 172.16.223.254 (mac addr)
bound to 172.16.223.130 -- renewal in 900 seconds

/etc/dhclient.conf appears to be identical to between i386 and amd64.
I am sending an identical hostname FWIW, but I am only launching only
one VM at a time.

initial-interval 1;
send host-name vm;
request subnet-mask, broadcast-address, routers, domain-name,
domain-name-servers, host-name;

Let me know if you want me to try anything else.

--david

Re: dhclient drops address on re-exec in 5.3 bsd.rd

[Kenneth R Westerback]

On Sun, Apr 28, 2013 at 05:29:05PM -0400, David Higgs wrote:
 On Sun, Apr 28, 2013 at 4:00 PM, Kenneth R Westerback
 kwesterb...@rogers.com wrote:
  On Sun, Apr 28, 2013 at 02:41:36PM -0400, David Higgs wrote:
  Confirmed in 5.3-current downloaded several minutes ago.
 
  Steps to reproduce:
  - Boot bsd.rd
  - Select upgrade, hit enter until dhclient gets and assigns an address
  - Complete upgrade or control-C, then restart the upgrade process
  - dhclient on 2nd run REMOVES the assigned address
 
  Probably affects the bsd.rd install option as well. This does not
  happen with 5.2 bsd.rd.
 
  Easy to work around, but probably not right.
 
  Thanks!
 
  --david
 
 
  Can't reproduce on amd64 -current here. I did control-C after getting
  dhclient lease, entered 'upgrade' at command prompt, and re-started
  upgrade. dhclient worked fine. Checked 'ifconfig' and the expected
  address was present.
 
  So more info you what exactly you are doing, on what machine are
  you doing it, and perhaps anything interesting in your dhclient.conf
  would be helpful. Thanks.
 
   Ken
 
 I would have provided output, but I haven't figured out how to log
 console output from VMware images.  Hopefully this will suffice:
 
 i386 / 5.3-current / RAMDISK_CD #120
 
 dhclient #1 (good)
 DHCPDISCOVER on vic0 to 255.255.255.255 port 67 interval 1
 DHCPOFFER from 172.16.223.254 (mac addr)
 DHCPREQUEST on vic0 to 255.255.255.255 port 67
 DHCPACK from 172.16.223.254 (mac addr)
 bound to 172.16.223.131 -- renewal in 900 seconds
 
 dhclient #2 (bad)
 DHCPREQUEST on vic0 to 255.255.255.255 port 67
 Active address (172.16.223.131) deleted; exiting

Is there a configured ip address on the interface at this point?
This is a message emitted by one dhclient on noticing that another
one is active and has deleted the address the first one configured.
It *shouldn't* mean that no ip address is configured.

Now what is different in the virtual environment you are using that
makes i386 timing different than amd64 ... dunno.

 Ken

 
 dhclient #3 (good)
 DHCPREQUEST on vic0 to 255.255.255.255 port 67
 DHCPACK from 172.16.223.254 (mac addr)
 bound to 172.16.223.131 -- renewal in 900 seconds
 
 amd64 / 5.3-current / RAMDISK_CD #132
 
 dhclient #1 (good)
 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 1
 DHCPOFFER from 172.16.223.254 (mac addr)
 DHCPREQUEST on em0 to 255.255.255.255 port 67
 DHCPACK from 172.16.223.254 (mac addr)
 bound to 172.16.223.130 -- renewal in 900 seconds
 
 dhclient #2 (still good)
 DHCPREQUEST on em0 to 255.255.255.255 port 67
 DHCPACK from 172.16.223.254 (mac addr)
 bound to 172.16.223.130 -- renewal in 900 seconds
 
 /etc/dhclient.conf appears to be identical to between i386 and amd64.
 I am sending an identical hostname FWIW, but I am only launching only
 one VM at a time.
 
 initial-interval 1;
 send host-name vm;
 request subnet-mask, broadcast-address, routers, domain-name,
 domain-name-servers, host-name;
 
 Let me know if you want me to try anything else.
 
 --david

Re: dhclient drops address on re-exec in 5.3 bsd.rd

[Kenneth R Westerback]

On Sun, Apr 28, 2013 at 05:29:05PM -0400, David Higgs wrote:
 On Sun, Apr 28, 2013 at 4:00 PM, Kenneth R Westerback
 kwesterb...@rogers.com wrote:
  On Sun, Apr 28, 2013 at 02:41:36PM -0400, David Higgs wrote:
  Confirmed in 5.3-current downloaded several minutes ago.
 
  Steps to reproduce:
  - Boot bsd.rd
  - Select upgrade, hit enter until dhclient gets and assigns an address
  - Complete upgrade or control-C, then restart the upgrade process
  - dhclient on 2nd run REMOVES the assigned address
 
  Probably affects the bsd.rd install option as well. This does not
  happen with 5.2 bsd.rd.
 
  Easy to work around, but probably not right.
 
  Thanks!
 
  --david
 
 
  Can't reproduce on amd64 -current here. I did control-C after getting
  dhclient lease, entered 'upgrade' at command prompt, and re-started
  upgrade. dhclient worked fine. Checked 'ifconfig' and the expected
  address was present.
 
  So more info you what exactly you are doing, on what machine are
  you doing it, and perhaps anything interesting in your dhclient.conf
  would be helpful. Thanks.
 
   Ken
 
 I would have provided output, but I haven't figured out how to log
 console output from VMware images.  Hopefully this will suffice:
 
 i386 / 5.3-current / RAMDISK_CD #120
 
 dhclient #1 (good)
 DHCPDISCOVER on vic0 to 255.255.255.255 port 67 interval 1
 DHCPOFFER from 172.16.223.254 (mac addr)
 DHCPREQUEST on vic0 to 255.255.255.255 port 67
 DHCPACK from 172.16.223.254 (mac addr)
 bound to 172.16.223.131 -- renewal in 900 seconds
 
 dhclient #2 (bad)
 DHCPREQUEST on vic0 to 255.255.255.255 port 67
 Active address (172.16.223.131) deleted; exiting

Trying the exact same RAMDISK_CD #120 on 'real' i386 hardware with
an nfe(4) interface, I cannot reproduce. So I suspect (assuming it
is not just an errant log message) something is broken in the i386/vm
interface you are trying.

 Ken

 
 dhclient #3 (good)
 DHCPREQUEST on vic0 to 255.255.255.255 port 67
 DHCPACK from 172.16.223.254 (mac addr)
 bound to 172.16.223.131 -- renewal in 900 seconds
 
 amd64 / 5.3-current / RAMDISK_CD #132
 
 dhclient #1 (good)
 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 1
 DHCPOFFER from 172.16.223.254 (mac addr)
 DHCPREQUEST on em0 to 255.255.255.255 port 67
 DHCPACK from 172.16.223.254 (mac addr)
 bound to 172.16.223.130 -- renewal in 900 seconds
 
 dhclient #2 (still good)
 DHCPREQUEST on em0 to 255.255.255.255 port 67
 DHCPACK from 172.16.223.254 (mac addr)
 bound to 172.16.223.130 -- renewal in 900 seconds
 
 /etc/dhclient.conf appears to be identical to between i386 and amd64.
 I am sending an identical hostname FWIW, but I am only launching only
 one VM at a time.
 
 initial-interval 1;
 send host-name vm;
 request subnet-mask, broadcast-address, routers, domain-name,
 domain-name-servers, host-name;
 
 Let me know if you want me to try anything else.
 
 --david

Re: dhclient drops address on re-exec in 5.3 bsd.rd

[David Higgs]

On Sun, Apr 28, 2013 at 6:39 PM, Kenneth R Westerback
kwesterb...@rogers.com wrote:
 On Sun, Apr 28, 2013 at 05:29:05PM -0400, David Higgs wrote:
 On Sun, Apr 28, 2013 at 4:00 PM, Kenneth R Westerback
 kwesterb...@rogers.com wrote:
  On Sun, Apr 28, 2013 at 02:41:36PM -0400, David Higgs wrote:
  Confirmed in 5.3-current downloaded several minutes ago.
 
  Steps to reproduce:
  - Boot bsd.rd
  - Select upgrade, hit enter until dhclient gets and assigns an address
  - Complete upgrade or control-C, then restart the upgrade process
  - dhclient on 2nd run REMOVES the assigned address
 
  Probably affects the bsd.rd install option as well. This does not
  happen with 5.2 bsd.rd.
 
  Easy to work around, but probably not right.
 
  Thanks!
 
  --david
 
 
  Can't reproduce on amd64 -current here. I did control-C after getting
  dhclient lease, entered 'upgrade' at command prompt, and re-started
  upgrade. dhclient worked fine. Checked 'ifconfig' and the expected
  address was present.
 
  So more info you what exactly you are doing, on what machine are
  you doing it, and perhaps anything interesting in your dhclient.conf
  would be helpful. Thanks.
 
   Ken

 I would have provided output, but I haven't figured out how to log
 console output from VMware images.  Hopefully this will suffice:

 i386 / 5.3-current / RAMDISK_CD #120

 dhclient #1 (good)
 DHCPDISCOVER on vic0 to 255.255.255.255 port 67 interval 1
 DHCPOFFER from 172.16.223.254 (mac addr)
 DHCPREQUEST on vic0 to 255.255.255.255 port 67
 DHCPACK from 172.16.223.254 (mac addr)
 bound to 172.16.223.131 -- renewal in 900 seconds

 dhclient #2 (bad)
 DHCPREQUEST on vic0 to 255.255.255.255 port 67
 Active address (172.16.223.131) deleted; exiting

 Trying the exact same RAMDISK_CD #120 on 'real' i386 hardware with
 an nfe(4) interface, I cannot reproduce. So I suspect (assuming it
 is not just an errant log message) something is broken in the i386/vm
 interface you are trying.

  Ken

More simple tests on i386 follow.  The every other failure is pretty
repeatable but I have seen a couple cases where it worked.  I wouldn't
be surprised if the opposite applies to the non-zero sleep test.

1. Always OK: from bsd.rd - dhclient vic0
2. Fail: from bsd.rd - ifconfig vic0 down ; dhclient vic0
3. Fail: from bsd.rd - ifconfig vic0 down ; sleep 0 ; dhclient vic0
4. OK: from bsd.rd - ifconfig vic0 down ; sleep 0.001 ; dhclient vic0
5. Always OK: from bsd - ifconfig vic0 down ; dhclient vic0

Smells like a driver timing or hardware emulation bug to me.  I am
running OpenBSD as 32-bit Other, inside VMware Fusion 4.0.4 if that
makes any difference.  Anything else I can do or provide to help?

dmesg output (apologies for gmail's line wrapping):

OpenBSD 5.3-current (RAMDISK_CD) #120: Thu Apr 25 17:10:53 MDT 2013
t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
cpu0: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz (GenuineIntel
686-class) 2.40 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,NXE,LONG,SSE3,SSSE3,CX16,LAHF,PERF,ITSC
real mem  = 267907072 (255MB)
avail mem = 256258048 (244MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 09/20/12, BIOS32 rev. 0 @
0xfd780, SMBIOS rev. 2.4 @ 0xe0010 (364 entries)
bios0: vendor Phoenix Technologies LTD version 6.00 date 09/20/2012
bios0: VMware, Inc. VMware Virtual Platform
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 65MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
bios0: ROM list: 0xc/0x8000 0xc8000/0x1000 0xdc000/0x4000! 0xe/0x8000!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel 82443BX AGP rev 0x01
ppb0 at pci0 dev 1 function 0 Intel 82443BX AGP rev 0x01
pci1 at ppb0 bus 1
pcib0 at pci0 dev 7 function 0 Intel 82371AB PIIX4 ISA rev 0x08
pciide0 at pci0 dev 7 function 1 Intel 82371AB IDE rev 0x01: DMA,
channel 0 configured to compatibility, channel 1 configured to
compatibility
wd0 at pciide0 channel 0 drive 0: VMware Virtual IDE Hard Drive
wd0: 64-sector PIO, LBA, 16384MB, 33554432 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 disabled (no drives)
Intel 82371AB Power rev 0x08 at pci0 dev 7 function 3 not configured
VMware Virtual Machine Communication Interface rev 0x10 at pci0 dev
7 function 7 not configured
vga1 at pci0 dev 15 function 0 VMware Virtual SVGA II rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
ppb1 at pci0 dev 17 function 0 VMware Virtual PCI-PCI rev 0x02
pci2 at ppb1 bus 2
vic0 at pci2 dev 0 function 0 AMD 79c970 PCnet-PCI rev 0x10: apic 1
int 18, address 00:0c:29:71:66:01
ppb2 at pci0 dev 21 function 0 VMware Virtual PCIE-PCIE rev 0x01
pci3 at ppb2 bus 3
ppb3 at pci0 dev 21 

Re: dhclient could not allocate memory

[Marc Peters]

On 02/28/2013 06:58 PM, Marc Peters wrote:
 Hi misc,
 
 i am using OpenBSD on my home router connected to cable internet. A re
 nic is facing the wild and gets its public IP via DHCP from my ISP. I
 have running a 5.3-beta from Feb. 1st, as this one has the powersaving
 fix for athn in HostAP (realised it then, was committed already in
 August). This router was running happily 5.2-RELEASE until then, 24/7,
 without any issues. However, this night dhclient died unexpectedly and
 /var/log/daemon says:
 
 Feb 27 22:05:56 router dhclient[22805]: sysctl retrieval of routes:
 Cannot allocate memory
 Feb 27 22:05:56 router dhclient[10969]: dispatch_imsg in main: pipe closed
 
 dhclient gone and with it my internet connection, too.
 
 I wonder, what could have caused this. The machine has two AMD APUs and
 8GB of memory (dmesg attached) and dhclient shouldn't run out of it (and
 it had no issues like that before with 5.1 and 5.2), but maybe i am
 totally wrong and looking in the wrong place at all.
 
 I know that Realtek cards have had a great history (joking!) and i try
 to avoid them, but this one is onboard and Intel NICs with double
 interfaces aren't as cheap as the PCIe one port desktop grade card i
 already added.
 
 mbufs are also unremarkable:
 marc@router
 ~ $ netstat -m
 133 mbufs in use:
 87 mbufs allocated to data
 14 mbufs allocated to packet headers
 32 mbufs allocated to socket names and addresses
 22/356/6144 mbuf 2048 byte clusters in use (current/peak/max)
 64/73/6144 mbuf 4096 byte clusters in use (current/peak/max)
 0/8/6144 mbuf 8192 byte clusters in use (current/peak/max)
 0/8/6144 mbuf 9216 byte clusters in use (current/peak/max)
 0/8/6144 mbuf 12288 byte clusters in use (current/peak/max)
 0/8/6144 mbuf 16384 byte clusters in use (current/peak/max)
 0/8/6144 mbuf 65536 byte clusters in use (current/peak/max)
 1284 Kbytes allocated to network (25% in use)
 0 requests for memory denied
 0 requests for memory delayed
 0 calls to protocol drain routines
 
 Maybe someone can shed some light on it and knows which knob to turn.
 
 Cheers,
 Marc
 
 
 Uptime provided for reference, not measurement of private parts ;)
 
 marc@router
 ~ $ uptime
  6:54PM  up 24 days,  2:41, 1 user, load averages: 0.24, 0.19, 0.1
 
 dmesg:
 OpenBSD 5.3-beta (GENERIC.MP) #25: Fri Feb  1 16:29:00 MST 2013
 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 8167034880 (7788MB)
 avail mem = 7927136256 (7559MB)
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeaf40 (52 entries)
 bios0: vendor American Megatrends Inc. version 0306 date 08/18/2011
 bios0: ASUSTeK Computer INC. E45M1-I DELUXE
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S3 S4 S5
 acpi0: tables DSDT FACP APIC MCFG HPET SSDT SSDT
 acpi0: wakeup devices SBAZ(S4) PS2K(S4) PS2M(S4) UAR1(S4) P0PC(S4)
 UHC1(S4) UHC2(S4) USB3(S4) UHC4(S4) USB5(S4) UHC6(S4) UHC7(S4) PE20(S4)
 PE21(S4) RLAN(S4) PE22(S4) PE23(S4) BR14(S4) PWRB(S4)
 acpitimer0 at acpi0: 3579545 Hz, 32 bits
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: AMD E-450 APU with Radeon(tm) HD Graphics, 1650.36 MHz
 cpu0:
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
 cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
 64b/line 16-way L2 cache
 cpu0: 8 4MB entries fully associative
 cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
 cpu0: apic clock running at 199MHz
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: AMD E-450 APU with Radeon(tm) HD Graphics, 1649.90 MHz
 cpu1:
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
 cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
 64b/line 16-way L2 cache
 cpu1: 8 4MB entries fully associative
 cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 21, 24 pins
 ioapic0: misconfigured as apic 3, remapped to apid 0
 acpimcfg0 at acpi0 addr 0xe000, bus 0-255
 acpihpet0 at acpi0: 14318180 Hz
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus 3 (PE20)
 acpiprt2 at acpi0: bus 4 (PE21)
 acpiprt3 at acpi0: bus -1 (PE22)
 acpiprt4 at acpi0: bus -1 (PE23)
 acpiprt5 at acpi0: bus -1 (BR15)
 acpiprt6 at acpi0: bus -1 (PCE6)
 acpiprt7 at acpi0: bus -1 (PCE7)
 acpiprt8 at acpi0: bus -1 (PCE8)
 acpiprt9 at acpi0: bus 1 (BR14)
 acpicpu0 at acpi0: C2, PSS
 acpicpu1 at acpi0: C2, PSS
 acpibtn0 at acpi0: PWRB
 cpu0: 1650 MHz: speeds: 1650 1320 825 MHz
 pci0 at mainbus0 bus 0
 pchb0 at pci0 dev 0 function 0 AMD AMD64 14h Host rev 0x00
 vga1 at pci0 dev 1 function 0 ATI Radeon 

Re: dhclient not receiving dhcpoffers with wep connection but fine with wpa

[Kenneth R Westerback]

On Sun, Mar 03, 2013 at 03:10:38PM -0800, Jeff Richards wrote:
 I have been trying to configure a HP Pavilion dv5000(5210us) laptop to connect
 to a WEP network.? I have tried OBSD 5.2 and CURRENT without success using WEP
 but can connect with WPA --personal hotspot.
 
 
 The network interfaces I have
 tried are 
 
 
 Integrated wireless (bwi0 at pci3 dev 2 function 0 Broadcom
 BCM4318 rev 0x02: apic 1 int 21) 
 
 
 USB adapter (rum0 at uhub0 port 1 Ralink
 Technology RT2573 EV 2.00/0.01 addr 2 MAC/BBP RT2573 (rev 0x2573a), RF
 RT2528)
 
 Both adapters fail to obtain a DHCP configuration with No acceptable
 DHCPOFFERS received when using WEP but have no issue when configured for WPA.
 I have used ifconfig interface scan to extract information? to specify the
 channel and BSSID for my hostname.if WEP configuration.
 
 Any ideas will be
 appreciated.
 
 Thanks.
 

Idea 1: Supply the information requested for problem reports in

http://openbsd.org/report.html

including your logs, and a tcpdump of any received DHCPOFFER packets.

Idea 2: manually configure the interface and see if ANY network
traffic (e.g. ping) makes it in or out.

 Ken

Re: dhclient could not allocate memory

[Chris Smith]

On Thu, Feb 28, 2013 at 12:58 PM, Marc Peters m...@mpeters.org wrote:
 dhclient

I've noticed a lot of dhclient changes in cvs over the past few
weeks.You might try a newer snapshot.

Chris

Re: dhclient could not allocate memory

[Marc Peters]

On 02/28/2013 06:58 PM, Marc Peters wrote:
 Hi misc,
 
 i am using OpenBSD on my home router connected to cable internet. A re
 nic is facing the wild and gets its public IP via DHCP from my ISP. I
 have running a 5.3-beta from Feb. 1st, as this one has the powersaving
 fix for athn in HostAP (realised it then, was committed already in
 August). This router was running happily 5.2-RELEASE until then, 24/7,
 without any issues. However, this night dhclient died unexpectedly and
 /var/log/daemon says:
 
 Feb 27 22:05:56 router dhclient[22805]: sysctl retrieval of routes:
 Cannot allocate memory
 Feb 27 22:05:56 router dhclient[10969]: dispatch_imsg in main: pipe closed
 
 dhclient gone and with it my internet connection, too.
 
 I wonder, what could have caused this. The machine has two AMD APUs and
 8GB of memory (dmesg attached) and dhclient shouldn't run out of it (and
 it had no issues like that before with 5.1 and 5.2), but maybe i am
 totally wrong and looking in the wrong place at all.
 
 I know that Realtek cards have had a great history (joking!) and i try
 to avoid them, but this one is onboard and Intel NICs with double
 interfaces aren't as cheap as the PCIe one port desktop grade card i
 already added.
 
 mbufs are also unremarkable:
 marc@router
 ~ $ netstat -m
 133 mbufs in use:
 87 mbufs allocated to data
 14 mbufs allocated to packet headers
 32 mbufs allocated to socket names and addresses
 22/356/6144 mbuf 2048 byte clusters in use (current/peak/max)
 64/73/6144 mbuf 4096 byte clusters in use (current/peak/max)
 0/8/6144 mbuf 8192 byte clusters in use (current/peak/max)
 0/8/6144 mbuf 9216 byte clusters in use (current/peak/max)
 0/8/6144 mbuf 12288 byte clusters in use (current/peak/max)
 0/8/6144 mbuf 16384 byte clusters in use (current/peak/max)
 0/8/6144 mbuf 65536 byte clusters in use (current/peak/max)
 1284 Kbytes allocated to network (25% in use)
 0 requests for memory denied
 0 requests for memory delayed
 0 calls to protocol drain routines
 
 Maybe someone can shed some light on it and knows which knob to turn.
 
 Cheers,
 Marc
 
 
 Uptime provided for reference, not measurement of private parts ;)
 
 marc@router
 ~ $ uptime
  6:54PM  up 24 days,  2:41, 1 user, load averages: 0.24, 0.19, 0.1
 
 dmesg:
 OpenBSD 5.3-beta (GENERIC.MP) #25: Fri Feb  1 16:29:00 MST 2013
 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 8167034880 (7788MB)
 avail mem = 7927136256 (7559MB)
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeaf40 (52 entries)
 bios0: vendor American Megatrends Inc. version 0306 date 08/18/2011
 bios0: ASUSTeK Computer INC. E45M1-I DELUXE
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S3 S4 S5
 acpi0: tables DSDT FACP APIC MCFG HPET SSDT SSDT
 acpi0: wakeup devices SBAZ(S4) PS2K(S4) PS2M(S4) UAR1(S4) P0PC(S4)
 UHC1(S4) UHC2(S4) USB3(S4) UHC4(S4) USB5(S4) UHC6(S4) UHC7(S4) PE20(S4)
 PE21(S4) RLAN(S4) PE22(S4) PE23(S4) BR14(S4) PWRB(S4)
 acpitimer0 at acpi0: 3579545 Hz, 32 bits
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: AMD E-450 APU with Radeon(tm) HD Graphics, 1650.36 MHz
 cpu0:
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
 cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
 64b/line 16-way L2 cache
 cpu0: 8 4MB entries fully associative
 cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
 cpu0: apic clock running at 199MHz
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: AMD E-450 APU with Radeon(tm) HD Graphics, 1649.90 MHz
 cpu1:
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
 cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
 64b/line 16-way L2 cache
 cpu1: 8 4MB entries fully associative
 cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 21, 24 pins
 ioapic0: misconfigured as apic 3, remapped to apid 0
 acpimcfg0 at acpi0 addr 0xe000, bus 0-255
 acpihpet0 at acpi0: 14318180 Hz
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus 3 (PE20)
 acpiprt2 at acpi0: bus 4 (PE21)
 acpiprt3 at acpi0: bus -1 (PE22)
 acpiprt4 at acpi0: bus -1 (PE23)
 acpiprt5 at acpi0: bus -1 (BR15)
 acpiprt6 at acpi0: bus -1 (PCE6)
 acpiprt7 at acpi0: bus -1 (PCE7)
 acpiprt8 at acpi0: bus -1 (PCE8)
 acpiprt9 at acpi0: bus 1 (BR14)
 acpicpu0 at acpi0: C2, PSS
 acpicpu1 at acpi0: C2, PSS
 acpibtn0 at acpi0: PWRB
 cpu0: 1650 MHz: speeds: 1650 1320 825 MHz
 pci0 at mainbus0 bus 0
 pchb0 at pci0 dev 0 function 0 AMD AMD64 14h Host rev 0x00
 vga1 at pci0 dev 1 function 0 ATI Radeon