Re: NM changes DHCP address too easily

2016-06-08 Thread matti kaasinen
Thanks for this information,

This sounds like dhclient bug
> https://bugzilla.redhat.com/show_bug.cgi?id=1093803
>
> The internal DHCP plugin (from systemd's network library) doesn't have
> issue with resetting time.
>
I hope internal DHCP plugin can also tolerate/ignore IPv4LL addresses so
that I need not bothering you again when TI gets their meta-ti 2.1 layer
mature enough so that I get more recent NM available.
Thanks,
Matti

2016-06-08 12:35 GMT+03:00 Thomas Haller :

> On Wed, 2016-06-08 at 12:14 +0300, matti kaasinen wrote:
> > Hi!
> >
> > I got into same conclusion as as Eli (http://billauer.co.il/blog/2012
> > /10/dhcp-ip-ntpdate-rtc/) that dhclient notices that time has
> > advanced over lease "expire" moment after time jump due to ntpdate.
> > As a consequence it rejects old IP and claims new one. I tried more
> > elegant way to get this solved so that I first check difference
> > between local and NTP time. If it is big enough, I switch from dhcp
> > mode to manual mode using the IP from dhcp lease. Then I run ntpdate
> > and switch back to dhcp mode. Sound elegant (and complicated), but
> > really from logs it seems pretty the same as what Eli got.
> >
> > This works somehow, IP does not change change. However, Avahi does
> > not tolerate this quite perfectly. It usually does, but sometimes it
> > gets confused and does not discuss with avahi-browse/avahi-discover.
> > This can quite well come from the fact that I need to run dhclient-
> > enter-hook to keep IPv4LL address.
> >
> > In fact, wouldn't this issue been fixed in dhclient just by
> > monitoring lease trials: It should not reject the old lease if there
> > are no refresh trials before time exceeds the "expire" moment. I hope
> > you do something like that in NM-dhclient. I also hope that you could
> > figure out some policy to maitain IPc4LL address when dhcp client
> > gets lease.
>
>
> This sounds like dhclient bug
> https://bugzilla.redhat.com/show_bug.cgi?id=1093803
>
> The internal DHCP plugin (from systemd's network library) doesn't have
> issue with resetting time.
>
>
> Thomas
>
>
>
>
> >
> > Thanks,
> > Matti
> >
> > 2016-05-17 10:15 GMT+03:00 matti kaasinen :
> > > Hi!
> > > Some more information - lease log from board after re-installation
> > > and dhcp server log:
> > > 
> > > lease {
> > >   interface "eth0";
> > >   fixed-address 111.111.3.15;
> > >   option subnet-mask 255.255.252.0;
> > >   option dhcp-lease-time 7200;
> > >   option routers 111.111.1.2;
> > >   option dhcp-message-type 5;
> > >   option dhcp-server-identifier 111.111.1.2;
> > >   option domain-name-servers 111.111.1.2;
> > >   option broadcast-address 111.111.3.255;
> > >   option domain-name "domain.fi";
> > >   renew 5 2016/03/11 14:46:10;
> > >   rebind 5 2016/03/11 15:41:49;
> > >   expire 5 2016/03/11 15:56:49;
> > > }
> > > lease {
> > >   interface "eth0";
> > >   fixed-address 111.111.3.15;
> > >   option subnet-mask 255.255.252.0;
> > >   option routers 111.111.1.2;
> > >   option dhcp-lease-time 7200;
> > >   option dhcp-message-type 5;
> > >   option domain-name-servers 111.111.1.2;
> > >   option dhcp-server-identifier 111.111.1.2;
> > >   option broadcast-address 111.111.3.255;
> > >   option domain-name "domain.fi";
> > >   renew 5 2016/03/11 14:44:36;
> > >   rebind 5 2016/03/11 15:41:52;
> > >   expire 5 2016/03/11 15:56:52;
> > > }
> > > lease {
> > >   interface "eth0";
> > >   fixed-address 111.111.3.11;
> > >   option subnet-mask 255.255.252.0;
> > >   option routers 111.111.1.2;
> > >   option dhcp-lease-time 7200;
> > >   option dhcp-message-type 5;
> > >   option domain-name-servers 111.111.1.2;
> > >   option dhcp-server-identifier 111.111.1.2;
> > >   option broadcast-address 111.111.3.255;
> > >   option domain-name "domain.fi";
> > >   renew 2 2016/05/17 06:39:51;
> > >   rebind 2 2016/05/17 07:37:25;
> > >   expire 2 2016/05/17 07:52:25;
> > > }
> > > 
> > > As you can see, board gets two leases pretty rapidly, then it gets
> > > NTP time and new lease with new IP. Is this problem coming from the
> > > fact that when board gets NTP time, it notices that time is over
> > > expiration time and it has to drop its lease.
> > >
> > > I suppose that this is what Connman handles differently.
> > >
> > > Communication log from dhcp server:
> > > ===
> > > May 17 08:49:33 ubuntu1 dhcpd: DHCPDISCOVER from 84:eb:18:96:a2:14
> > > via eth1
> > > May 17 08:49:34 ubuntu1 dhcpd: DHCPOFFER on 111.111.3.15 to
> > > 84:eb:18:96:a2:14 via eth1
> > > May 17 08:49:34 ubuntu1 dhcpd: DHCPREQUEST for 111.111.3.15
> > > (111.111.1.2) from 84:eb:18:96:a2:14 via eth1
> > > May 17 08:49:34 ubuntu1 dhcpd: DHCPACK on 111.111.3.15 to
> > > 84:eb:18:96:a2:14 via eth1
> > >
> > > May 17 08:49:36 ubuntu1 dhcpd: DHCPREQUEST for 111.111.3.15 from
> > > 84:eb:18:96:a2:14 via eth1
> > > May 17 08:49:36 ubuntu1 dhcpd: DHCPACK on 111.111.3.15 to
> > > 84:eb:18:96:a2:14 via eth1
> > >
>

Re: NM changes DHCP address too easily

2016-06-08 Thread Thomas Haller
On Wed, 2016-06-08 at 12:14 +0300, matti kaasinen wrote:
> Hi!
> 
> I got into same conclusion as as Eli (http://billauer.co.il/blog/2012
> /10/dhcp-ip-ntpdate-rtc/) that dhclient notices that time has
> advanced over lease "expire" moment after time jump due to ntpdate.
> As a consequence it rejects old IP and claims new one. I tried more
> elegant way to get this solved so that I first check difference
> between local and NTP time. If it is big enough, I switch from dhcp
> mode to manual mode using the IP from dhcp lease. Then I run ntpdate
> and switch back to dhcp mode. Sound elegant (and complicated), but
> really from logs it seems pretty the same as what Eli got. 
> 
> This works somehow, IP does not change change. However, Avahi does
> not tolerate this quite perfectly. It usually does, but sometimes it
> gets confused and does not discuss with avahi-browse/avahi-discover.
> This can quite well come from the fact that I need to run dhclient-
> enter-hook to keep IPv4LL address.
> 
> In fact, wouldn't this issue been fixed in dhclient just by
> monitoring lease trials: It should not reject the old lease if there
> are no refresh trials before time exceeds the "expire" moment. I hope
> you do something like that in NM-dhclient. I also hope that you could
> figure out some policy to maitain IPc4LL address when dhcp client
> gets lease.


This sounds like dhclient bug
https://bugzilla.redhat.com/show_bug.cgi?id=1093803 

The internal DHCP plugin (from systemd's network library) doesn't have
issue with resetting time.


Thomas




> 
> Thanks,
> Matti
> 
> 2016-05-17 10:15 GMT+03:00 matti kaasinen :
> > Hi!
> > Some more information - lease log from board after re-installation
> > and dhcp server log:
> > 
> > lease {
> >   interface "eth0";
> >   fixed-address 111.111.3.15;
> >   option subnet-mask 255.255.252.0;
> >   option dhcp-lease-time 7200;
> >   option routers 111.111.1.2;
> >   option dhcp-message-type 5;
> >   option dhcp-server-identifier 111.111.1.2;
> >   option domain-name-servers 111.111.1.2;
> >   option broadcast-address 111.111.3.255;
> >   option domain-name "domain.fi";
> >   renew 5 2016/03/11 14:46:10;
> >   rebind 5 2016/03/11 15:41:49;
> >   expire 5 2016/03/11 15:56:49;
> > }
> > lease {
> >   interface "eth0";
> >   fixed-address 111.111.3.15;
> >   option subnet-mask 255.255.252.0;
> >   option routers 111.111.1.2;
> >   option dhcp-lease-time 7200;
> >   option dhcp-message-type 5;
> >   option domain-name-servers 111.111.1.2;
> >   option dhcp-server-identifier 111.111.1.2;
> >   option broadcast-address 111.111.3.255;
> >   option domain-name "domain.fi";
> >   renew 5 2016/03/11 14:44:36;
> >   rebind 5 2016/03/11 15:41:52;
> >   expire 5 2016/03/11 15:56:52;
> > }
> > lease {
> >   interface "eth0";
> >   fixed-address 111.111.3.11;
> >   option subnet-mask 255.255.252.0;
> >   option routers 111.111.1.2;
> >   option dhcp-lease-time 7200;
> >   option dhcp-message-type 5;
> >   option domain-name-servers 111.111.1.2;
> >   option dhcp-server-identifier 111.111.1.2;
> >   option broadcast-address 111.111.3.255;
> >   option domain-name "domain.fi";
> >   renew 2 2016/05/17 06:39:51;
> >   rebind 2 2016/05/17 07:37:25;
> >   expire 2 2016/05/17 07:52:25;
> > }
> > 
> > As you can see, board gets two leases pretty rapidly, then it gets
> > NTP time and new lease with new IP. Is this problem coming from the
> > fact that when board gets NTP time, it notices that time is over
> > expiration time and it has to drop its lease. 
> > 
> > I suppose that this is what Connman handles differently. 
> > 
> > Communication log from dhcp server:
> > ===
> > May 17 08:49:33 ubuntu1 dhcpd: DHCPDISCOVER from 84:eb:18:96:a2:14
> > via eth1
> > May 17 08:49:34 ubuntu1 dhcpd: DHCPOFFER on 111.111.3.15 to
> > 84:eb:18:96:a2:14 via eth1
> > May 17 08:49:34 ubuntu1 dhcpd: DHCPREQUEST for 111.111.3.15
> > (111.111.1.2) from 84:eb:18:96:a2:14 via eth1
> > May 17 08:49:34 ubuntu1 dhcpd: DHCPACK on 111.111.3.15 to
> > 84:eb:18:96:a2:14 via eth1
> > 
> > May 17 08:49:36 ubuntu1 dhcpd: DHCPREQUEST for 111.111.3.15 from
> > 84:eb:18:96:a2:14 via eth1
> > May 17 08:49:36 ubuntu1 dhcpd: DHCPACK on 111.111.3.15 to
> > 84:eb:18:96:a2:14 via eth1
> > 
> > May 17 08:52:16 ubuntu1 dhcpd: DHCPDISCOVER from 84:eb:18:96:a2:14
> > via eth1
> > May 17 08:52:16 ubuntu1 dhcpd: ICMP Echo reply while lease
> > 111.111.3.15 valid.
> > May 17 08:52:16 ubuntu1 dhcpd: Abandoning IP address 111.111.3.15:
> > pinged before offer
> > 
> > May 17 08:52:24 ubuntu1 dhcpd: DHCPDISCOVER from 84:eb:18:96:a2:14
> > via eth1
> > May 17 08:52:25 ubuntu1 dhcpd: DHCPOFFER on 111.111.3.11 to
> > 84:eb:18:96:a2:14 via eth1
> > May 17 08:52:25 ubuntu1 dhcpd: DHCPREQUEST for 111.111.3.11
> > (111.111.1.2) from 84:eb:18:96:a2:14 via eth1
> > May 17 08:52:25 ubuntu1 dhcpd: DHCPACK on 111.111.3.11 to
> > 84:eb:18:96:a2:14 via eth1
> > 
> > May 17 09:39:51 ubuntu1 dh

Re: NM changes DHCP address too easily

2016-06-08 Thread matti kaasinen
Hi!

I got into same conclusion as as Eli (
http://billauer.co.il/blog/2012/10/dhcp-ip-ntpdate-rtc/) that dhclient
notices that time has advanced over lease "expire" moment after time jump
due to ntpdate. As a consequence it rejects old IP and claims new one. I
tried more elegant way to get this solved so that I first check difference
between local and NTP time. If it is big enough, I switch from dhcp mode to
manual mode using the IP from dhcp lease. Then I run ntpdate and switch
back to dhcp mode. Sound elegant (and complicated), but really from logs it
seems pretty the same as what Eli got.

This works somehow, IP does not change change. However, Avahi does not
tolerate this quite perfectly. It usually does, but sometimes it gets
confused and does not discuss with avahi-browse/avahi-discover. This can
quite well come from the fact that I need to run dhclient-enter-hook to
keep IPv4LL address.

In fact, wouldn't this issue been fixed in dhclient just by monitoring
lease trials: It should not reject the old lease if there are no refresh
trials before time exceeds the "expire" moment. I hope you do something
like that in NM-dhclient. I also hope that you could figure out some policy
to maitain IPc4LL address when dhcp client gets lease.

Thanks,
Matti

2016-05-17 10:15 GMT+03:00 matti kaasinen :

> Hi!
> Some more information - lease log from board after re-installation and
> dhcp server log:
> 
> lease {
>   interface "eth0";
>   fixed-address 111.111.3.15;
>   option subnet-mask 255.255.252.0;
>   option dhcp-lease-time 7200;
>   option routers 111.111.1.2;
>   option dhcp-message-type 5;
>   option dhcp-server-identifier 111.111.1.2;
>   option domain-name-servers 111.111.1.2;
>   option broadcast-address 111.111.3.255;
>   option domain-name "domain.fi";
>   renew 5 2016/03/11 14:46:10;
>   rebind 5 2016/03/11 15:41:49;
>   expire 5 2016/03/11 15:56:49;
> }
> lease {
>   interface "eth0";
>   fixed-address 111.111.3.15;
>   option subnet-mask 255.255.252.0;
>   option routers 111.111.1.2;
>   option dhcp-lease-time 7200;
>   option dhcp-message-type 5;
>   option domain-name-servers 111.111.1.2;
>   option dhcp-server-identifier 111.111.1.2;
>   option broadcast-address 111.111.3.255;
>   option domain-name "domain.fi";
>   renew 5 2016/03/11 14:44:36;
>   rebind 5 2016/03/11 15:41:52;
>   expire 5 2016/03/11 15:56:52;
> }
> lease {
>   interface "eth0";
>   fixed-address 111.111.3.11;
>   option subnet-mask 255.255.252.0;
>   option routers 111.111.1.2;
>   option dhcp-lease-time 7200;
>   option dhcp-message-type 5;
>   option domain-name-servers 111.111.1.2;
>   option dhcp-server-identifier 111.111.1.2;
>   option broadcast-address 111.111.3.255;
>   option domain-name "domain.fi";
>   renew 2 2016/05/17 06:39:51;
>   rebind 2 2016/05/17 07:37:25;
>   expire 2 2016/05/17 07:52:25;
> }
> 
> As you can see, board gets two leases pretty rapidly, then it gets NTP
> time and new lease with new IP. Is this problem coming from the fact that
> when board gets NTP time, it notices that time is over expiration time and
> it has to drop its lease.
>
> I suppose that this is what Connman handles differently.
>
> Communication log from dhcp server:
> ===
> May 17 08:49:33 ubuntu1 dhcpd: DHCPDISCOVER from 84:eb:18:96:a2:14 via eth1
> May 17 08:49:34 ubuntu1 dhcpd: DHCPOFFER on 111.111.3.15 to
> 84:eb:18:96:a2:14 via eth1
> May 17 08:49:34 ubuntu1 dhcpd: DHCPREQUEST for 111.111.3.15 (111.111.1.2)
> from 84:eb:18:96:a2:14 via eth1
> May 17 08:49:34 ubuntu1 dhcpd: DHCPACK on 111.111.3.15 to
> 84:eb:18:96:a2:14 via eth1
>
> May 17 08:49:36 ubuntu1 dhcpd: DHCPREQUEST for 111.111.3.15 from
> 84:eb:18:96:a2:14 via eth1
> May 17 08:49:36 ubuntu1 dhcpd: DHCPACK on 111.111.3.15 to
> 84:eb:18:96:a2:14 via eth1
>
> May 17 08:52:16 ubuntu1 dhcpd: DHCPDISCOVER from 84:eb:18:96:a2:14 via eth1
> May 17 08:52:16 ubuntu1 dhcpd: ICMP Echo reply while lease 111.111.3.15
> valid.
> May 17 08:52:16 ubuntu1 dhcpd: Abandoning IP address 111.111.3.15: pinged
> before offer
>
> May 17 08:52:24 ubuntu1 dhcpd: DHCPDISCOVER from 84:eb:18:96:a2:14 via eth1
> May 17 08:52:25 ubuntu1 dhcpd: DHCPOFFER on 111.111.3.11 to
> 84:eb:18:96:a2:14 via eth1
> May 17 08:52:25 ubuntu1 dhcpd: DHCPREQUEST for 111.111.3.11 (111.111.1.2)
> from 84:eb:18:96:a2:14 via eth1
> May 17 08:52:25 ubuntu1 dhcpd: DHCPACK on 111.111.3.11 to
> 84:eb:18:96:a2:14 via eth1
>
> May 17 09:39:51 ubuntu1 dhcpd: DHCPREQUEST for 111.111.3.11 from
> 84:eb:18:96:a2:14 via eth1
> May 17 09:39:51 ubuntu1 dhcpd: DHCPACK on 111.111.3.11 to
> 84:eb:18:96:a2:14 via eth1
> ==
>
> I hope someone can sort out what goes wrong / howto fix it.
> Thanks,
> Matti
>
>
> 2016-04-25 21:33 GMT+03:00 matti kaasinen :
>
>> It is dedicated dhcp server for local area network called dhcpd3. I don't
>> know how many free leases it has, but it do have very much free addressing
>> space. I don't beleave server

Re: NM changes DHCP address too easily

2016-05-17 Thread matti kaasinen
Hi!
Some more information - lease log from board after re-installation and dhcp
server log:

lease {
  interface "eth0";
  fixed-address 111.111.3.15;
  option subnet-mask 255.255.252.0;
  option dhcp-lease-time 7200;
  option routers 111.111.1.2;
  option dhcp-message-type 5;
  option dhcp-server-identifier 111.111.1.2;
  option domain-name-servers 111.111.1.2;
  option broadcast-address 111.111.3.255;
  option domain-name "domain.fi";
  renew 5 2016/03/11 14:46:10;
  rebind 5 2016/03/11 15:41:49;
  expire 5 2016/03/11 15:56:49;
}
lease {
  interface "eth0";
  fixed-address 111.111.3.15;
  option subnet-mask 255.255.252.0;
  option routers 111.111.1.2;
  option dhcp-lease-time 7200;
  option dhcp-message-type 5;
  option domain-name-servers 111.111.1.2;
  option dhcp-server-identifier 111.111.1.2;
  option broadcast-address 111.111.3.255;
  option domain-name "domain.fi";
  renew 5 2016/03/11 14:44:36;
  rebind 5 2016/03/11 15:41:52;
  expire 5 2016/03/11 15:56:52;
}
lease {
  interface "eth0";
  fixed-address 111.111.3.11;
  option subnet-mask 255.255.252.0;
  option routers 111.111.1.2;
  option dhcp-lease-time 7200;
  option dhcp-message-type 5;
  option domain-name-servers 111.111.1.2;
  option dhcp-server-identifier 111.111.1.2;
  option broadcast-address 111.111.3.255;
  option domain-name "domain.fi";
  renew 2 2016/05/17 06:39:51;
  rebind 2 2016/05/17 07:37:25;
  expire 2 2016/05/17 07:52:25;
}

As you can see, board gets two leases pretty rapidly, then it gets NTP time
and new lease with new IP. Is this problem coming from the fact that when
board gets NTP time, it notices that time is over expiration time and it
has to drop its lease.

I suppose that this is what Connman handles differently.

Communication log from dhcp server:
===
May 17 08:49:33 ubuntu1 dhcpd: DHCPDISCOVER from 84:eb:18:96:a2:14 via eth1
May 17 08:49:34 ubuntu1 dhcpd: DHCPOFFER on 111.111.3.15 to
84:eb:18:96:a2:14 via eth1
May 17 08:49:34 ubuntu1 dhcpd: DHCPREQUEST for 111.111.3.15 (111.111.1.2)
from 84:eb:18:96:a2:14 via eth1
May 17 08:49:34 ubuntu1 dhcpd: DHCPACK on 111.111.3.15 to 84:eb:18:96:a2:14
via eth1

May 17 08:49:36 ubuntu1 dhcpd: DHCPREQUEST for 111.111.3.15 from
84:eb:18:96:a2:14 via eth1
May 17 08:49:36 ubuntu1 dhcpd: DHCPACK on 111.111.3.15 to 84:eb:18:96:a2:14
via eth1

May 17 08:52:16 ubuntu1 dhcpd: DHCPDISCOVER from 84:eb:18:96:a2:14 via eth1
May 17 08:52:16 ubuntu1 dhcpd: ICMP Echo reply while lease 111.111.3.15
valid.
May 17 08:52:16 ubuntu1 dhcpd: Abandoning IP address 111.111.3.15: pinged
before offer

May 17 08:52:24 ubuntu1 dhcpd: DHCPDISCOVER from 84:eb:18:96:a2:14 via eth1
May 17 08:52:25 ubuntu1 dhcpd: DHCPOFFER on 111.111.3.11 to
84:eb:18:96:a2:14 via eth1
May 17 08:52:25 ubuntu1 dhcpd: DHCPREQUEST for 111.111.3.11 (111.111.1.2)
from 84:eb:18:96:a2:14 via eth1
May 17 08:52:25 ubuntu1 dhcpd: DHCPACK on 111.111.3.11 to 84:eb:18:96:a2:14
via eth1

May 17 09:39:51 ubuntu1 dhcpd: DHCPREQUEST for 111.111.3.11 from
84:eb:18:96:a2:14 via eth1
May 17 09:39:51 ubuntu1 dhcpd: DHCPACK on 111.111.3.11 to 84:eb:18:96:a2:14
via eth1
==

I hope someone can sort out what goes wrong / howto fix it.
Thanks,
Matti


2016-04-25 21:33 GMT+03:00 matti kaasinen :

> It is dedicated dhcp server for local area network called dhcpd3. I don't
> know how many free leases it has, but it do have very much free addressing
> space. I don't beleave server changes addres for lack of addresses. There
> are only couple of workstations (below 10) using dhcp addressing and
> basically their address never changes.
>
> 2016-04-25 16:58 GMT+03:00 José Queiroz :
>
>>
>>
>> 2016-04-25 2:24 GMT-03:00 matti kaasinen :
>>
>>> dhcpd3
>>>
>>>
>> Sorry. I didn't make myself clear.
>>
>> Which device is your DHCP server? A router (maybe wifi)? A
>> dedicated/generic router? A server?
>>
>> How many free leases the DHCP server have, now?
>>
>>
>> ___
>> networkmanager-list mailing list
>> networkmanager-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/networkmanager-list
>>
>>
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: NM changes DHCP address too easily

2016-04-25 Thread matti kaasinen
It is dedicated dhcp server for local area network called dhcpd3. I don't
know how many free leases it has, but it do have very much free addressing
space. I don't beleave server changes addres for lack of addresses. There
are only couple of workstations (below 10) using dhcp addressing and
basically their address never changes.

2016-04-25 16:58 GMT+03:00 José Queiroz :

>
>
> 2016-04-25 2:24 GMT-03:00 matti kaasinen :
>
>> dhcpd3
>>
>>
> Sorry. I didn't make myself clear.
>
> Which device is your DHCP server? A router (maybe wifi)? A
> dedicated/generic router? A server?
>
> How many free leases the DHCP server have, now?
>
>
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list
>
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: NM changes DHCP address too easily

2016-04-25 Thread José Queiroz
2016-04-25 2:24 GMT-03:00 matti kaasinen :

> dhcpd3
>
>
Sorry. I didn't make myself clear.

Which device is your DHCP server? A router (maybe wifi)? A
dedicated/generic router? A server?

How many free leases the DHCP server have, now?
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: NM changes DHCP address too easily

2016-04-24 Thread matti kaasinen
dhcpd3

2016-04-22 18:05 GMT+03:00 José Queiroz :

>
>
> 2016-04-22 11:59 GMT-03:00 matti kaasinen :
>
>>
>> 2016-04-22 17:07 GMT+03:00 José Queiroz :
>>
>>> Shouldn't the DHCP address be managed by the DHCP server? Even if the
>>> client releases the previous lease, the server should send the same address
>>> on the next DISCOVER, as long as it is free, that's the recommended server
>>> behaviour.
>>
>> I would like that bhaviour, indeed. However, reality is that DHCP server
>> works like that with board supervised with Connman but not with NM. I have
>> tried to make NM and Connman client settings to look exactly the same to
>> DHCP server like for instance dhcp-client-identifier - based on MAC
>> address.  Everyting seems identical from DHCP server lease log and I can't
>> see difference with Wireshark. Unfortunately I have not got traced that
>> event that changes IP address.
>>
>> Who is your network's DHCP server?
>
>
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list
>
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: NM changes DHCP address too easily

2016-04-22 Thread Thomas Haller
On Fri, 2016-04-22 at 10:02 -0500, Dan Williams wrote:
> On Fri, 2016-04-22 at 16:40 +0300, matti kaasinen wrote:
> > 
> > 2016-04-22 16:12 GMT+03:00 Beniamino Galvani :
> > 
> > > 
> > > 
> > > Do you mean that the board is getting a different address at
> > > every
> > > boot? In order to reuse the same lease, a persistent connection
> > > must
> > > be used (i.e. a connection written on disk and not the in-memory
> > > one
> > > automatically generated by NM at every boot).
> > > 
> > Usually it gets that old address at boot but changes it soon after
> > that. My
> > board is using NTP time, so I suppose this happens after NTP time
> > synchronization if the original time was corrupted.
> On boot there's likely a valid lease from the previous run which can
> be
> renewed.  When the time jumps forward, dhclient notices this and must
> expire the lease because it is no longer valid.  dhclient has no
> choice
> but to enter the DISCOVER state and acquire a completely new one.
> 
> One workaround:
> http://billauer.co.il/blog/2012/10/dhcp-ip-ntpdate-rtc/
> 
> It does seem a bit odd that dhclient cannot re-acquire the lease; I'm
> not sure if it's allowed by the standards to renew an expired lease
> or
> not.  But you could argue a chicken/egg problem where DHCP delivers
> your NTP servers which then cause the time to jump forward which then
> kills the lease.  So it seems like something to check into with
> dhclient and whether they have improved things here in recent
> releases.
> 

Not sure that is related, but dhclient also gets confused when
resetting the systemtime:
https://bugzilla.redhat.com/show_bug.cgi?id=1093803#c13


Thomas

signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: NM changes DHCP address too easily

2016-04-22 Thread José Queiroz
2016-04-22 11:59 GMT-03:00 matti kaasinen :

>
> 2016-04-22 17:07 GMT+03:00 José Queiroz :
>
>> Shouldn't the DHCP address be managed by the DHCP server? Even if the
>> client releases the previous lease, the server should send the same address
>> on the next DISCOVER, as long as it is free, that's the recommended server
>> behaviour.
>
> I would like that bhaviour, indeed. However, reality is that DHCP server
> works like that with board supervised with Connman but not with NM. I have
> tried to make NM and Connman client settings to look exactly the same to
> DHCP server like for instance dhcp-client-identifier - based on MAC
> address.  Everyting seems identical from DHCP server lease log and I can't
> see difference with Wireshark. Unfortunately I have not got traced that
> event that changes IP address.
>
> Who is your network's DHCP server?
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: NM changes DHCP address too easily

2016-04-22 Thread Dan Williams
On Fri, 2016-04-22 at 16:40 +0300, matti kaasinen wrote:
> 2016-04-22 16:12 GMT+03:00 Beniamino Galvani :
> 
> > 
> > Do you mean that the board is getting a different address at every
> > boot? In order to reuse the same lease, a persistent connection
> > must
> > be used (i.e. a connection written on disk and not the in-memory
> > one
> > automatically generated by NM at every boot).
> > 
> 
> Usually it gets that old address at boot but changes it soon after
> that. My
> board is using NTP time, so I suppose this happens after NTP time
> synchronization if the original time was corrupted.

On boot there's likely a valid lease from the previous run which can be
renewed.  When the time jumps forward, dhclient notices this and must
expire the lease because it is no longer valid.  dhclient has no choice
but to enter the DISCOVER state and acquire a completely new one.

One workaround:
http://billauer.co.il/blog/2012/10/dhcp-ip-ntpdate-rtc/

It does seem a bit odd that dhclient cannot re-acquire the lease; I'm
not sure if it's allowed by the standards to renew an expired lease or
not.  But you could argue a chicken/egg problem where DHCP delivers
your NTP servers which then cause the time to jump forward which then
kills the lease.  So it seems like something to check into with
dhclient and whether they have improved things here in recent releases.

Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: NM changes DHCP address too easily

2016-04-22 Thread matti kaasinen
2016-04-22 16:12 GMT+03:00 Beniamino Galvani :

> Do you mean that the board is getting a different address at every
> boot? In order to reuse the same lease, a persistent connection must
> be used (i.e. a connection written on disk and not the in-memory one
> automatically generated by NM at every boot).
>


Usually it gets that old address at boot but changes it soon after that. My
board is using NTP time, so I suppose this happens after NTP time
synchronization if the original time was corrupted.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: NM changes DHCP address too easily

2016-04-22 Thread matti kaasinen
2016-04-22 15:55 GMT+03:00 Thomas Haller :

> Which plugin are you using? Does it change when setting "dhcp=internal"
> or "dhcp=dhclient"?
>


Unfortunately I'm still tied to NM v.0.9.8.10 for couple of months. So I
don't have chcp=internal option. I have been using dhclient.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: NM changes DHCP address too easily

2016-04-22 Thread Beniamino Galvani
On Fri, Apr 22, 2016 at 03:28:43PM +0300, matti kaasinen wrote:
> Hi!
> 
> I have found NM switching DHCP address quite frequently, which is pretty
> annoying as this happens on embedded board that has only internet access
> available.

Do you mean that the board is getting a different address at every
boot? In order to reuse the same lease, a persistent connection must
be used (i.e. a connection written on disk and not the in-memory one
automatically generated by NM at every boot).

Beniamino


signature.asc
Description: PGP signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: NM changes DHCP address too easily

2016-04-22 Thread Thomas Haller
On Fri, 2016-04-22 at 15:28 +0300, matti kaasinen wrote:
> Hi!
> 
> I have found NM switching DHCP address quite frequently, which is
> pretty annoying as this happens on embedded board that has only
> internet access available. I read from web that you have borrowed
> Connman internal DHCP client to your latest releases. I hope you have
> also adopted Connman convention also for this addressing as I never
> experienced this feature with Connman. DHCP address assigned first
> time never changed. I found also a lead from web telling that this
> problem could be caused from corrupted initial time to be cured with
> RTC. In fact I do have RTC, but it does not have proper battery back-
> up - just a supercap to keep time over relatively short break. Also
> there is bug in current CPU versions stopping RTC clock when CPU
> power is down. 
> 
> If this problem is an initial time issue together with lease
> information stored in /var/lib/NetworkManager/, would it be possible
> to work this problem out by ignoring timestamp if the current time is
> less than in timestamp stored in above directory? Could this not be
> done relatively easily?
> 

Hi Matti,


NetworkManager supports plugins for DHCP. You configure the plugin via
by putitng "main.dhcp=" to /etc/NetworkManager/NetworkManager.conf.

So your question might depend on which plugin you are using.

Since NM 1.0, there is the "internal" plugin which uses (the not yet
released) libsystemd-network library. That library was also contributed
to systemd by Connman developers, but we don't use any Connman library.

Which plugin are you using? Does it change when setting "dhcp=internal"
or "dhcp=dhclient"?


Thomas

signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list