Send connman mailing list submissions to
connman@lists.01.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
connman-requ...@lists.01.org
You can reach the person managing the list at
connman-ow...@lists.01.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. RE: Retry NTP servers periodically on startup (Craig McQueen)
2. Re: Retry NTP servers periodically on startup (Daniel Wagner)
3. How does connman detect loss of connectivity for ethernet,
when there is no delete link event? (Andreas Koller)
----------------------------------------------------------------------
Message: 1
Date: Thu, 22 Mar 2018 01:31:38 +0000
From: Craig McQueen <craig.mcqu...@innerrange.com>
To: Daniel Wagner <w...@monom.org>, "connman@lists.01.org"
<connman@lists.01.org>
Subject: RE: Retry NTP servers periodically on startup
Message-ID: <5341a9f608bd4167a6da8a497e9ef...@innerrange.com>
Content-Type: text/plain; charset="us-ascii"
Daniel Wagner wrote:
> On 01/17/2018 08:50 AM, Daniel Wagner wrote:
> > This is the attempt to fix the outstanding CM-636 bug. This is still
> > not completely finished. There is some more potential to cleanup the
> > timeserver code. But I thought maybe someone wants to test it. You can
> > install a iptables rule to see if the retry logic works.
> >
> > iptables -A OUTPUT -p tcp --dport 123 -j DROP
> > iptables -A OUTPUT -p udp --dport 123 -j DROP
> >
> > This should do the trick.
>
> After some more debugging and removing of the unnecessary DBG() I
> applied this.
I have a device using ConnMan 1.32, which is connected to the Internet through
a FritzBox home ADSL router. It is configured with NTP servers:
0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org, 3.pool.ntp.org
It additionally gets the IPv4 address of the FritzBox router itself as a
further NTP server, from DHCP.
I have found that if the router is power-cycled just before the time of the
next NTP sync (which occurs at roughly 17 minute intervals), then it
subsequently never does any more NTP syncs.
I saw this recent work on CM-636 in the ConnMan git repository, so I have tried
upgrading the devices to use a recent git commit of ConnMan. Then I retested
power-cycling the router just before a scheduled NTP sync. I did the test
twice, and the first time, it still did a sync a minute later, after the router
rebooted. But the second time I did the test, the device subsequently never has
done any more NTP syncs. That was roughly 14 hours ago.
Any ideas on what is going on?
--
Craig McQueen
------------------------------
Message: 2
Date: Thu, 22 Mar 2018 09:46:15 +0100
From: Daniel Wagner <w...@monom.org>
To: Craig McQueen <craig.mcqu...@innerrange.com>
Cc: "connman@lists.01.org" <connman@lists.01.org>
Subject: Re: Retry NTP servers periodically on startup
Message-ID: <d40c11f7-86d8-0e30-ce08-8b89eda42...@monom.org>
Content-Type: text/plain; charset=utf-8
Hi Craig,
> I have a device using ConnMan 1.32, which is connected to the
> Internet through a FritzBox home ADSL router. It is configured with NTP
> servers:
> 0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org, 3.pool.ntp.org
> It additionally gets the IPv4 address of the FritzBox router itself
> as a further NTP server, from DHCP.
>
> I have found that if the router is power-cycled just before the time
> of the next NTP sync (which occurs at roughly 17 minute intervals), then
> it subsequently never does any more NTP syncs.
So ConnMan tries to sync and the router is down at this point?
> I saw this recent work on CM-636 in the ConnMan git repository, so I
> have tried upgrading the devices to use a recent git commit of ConnMan.
CM-636 should fix the case where ConnMan hasn't done any NTP sync yet.
After the first successful sync it is still the old algorithm. It sounds
like we need to address another fallback scenario.
> Then I retested power-cycling the router just before a scheduled NT> sync. I
> did the test twice, and the first time, it still did a sync a
> minute later, after the router rebooted. But the second time I did the
> test, the device subsequently never has done any more NTP syncs. That
> was roughly 14 hours ago.
Could you post the debug log of both tests? It sounds like that in the
first case, ConnMan falls back to the aggressive retry loop and in the
second case it doesn't happen.
Thanks,
Daniel
------------------------------
Message: 3
Date: Thu, 22 Mar 2018 18:31:16 +0100
From: "Andreas Koller" <kollergef...@gmx.de>
To: connman@lists.01.org
Subject: How does connman detect loss of connectivity for ethernet,
when there is no delete link event?
Message-ID:
<trinity-d7a26ec3-4f30-4a4c-99cf-0139bf381015-1521739876915@3c-app-gmx-bs70>
Content-Type: text/plain; charset=UTF-8
When I pull the network cable from the device, connman detects correctly,
that connectivity is lost and gives default route to wifi.
But when I pull the cable behind the router, there is no delete link detection
and
and ethernet is still shown as online.
Is the online check meant to be repeated automatically?
Or is this optional behaviour, that can be enabled?
Or does it depend on specific events (eg new nameservers, delete link
detection)?
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
connman@lists.01.org
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 29, Issue 25
***************************************
