That's for the info.
The Beaglebones are a mix of Blacks and Greens but all have the same image.
The Internet equipment is different at almost every site with a mix of 4
I have 12 sites working flawlessly and two that seem to quit in the middle
of the night 3-4 times per week. Because this happens primarily at night I
suspect forced IP changes ( lease revocation) by the provider.
It sounds like Connman should 'just work' and request a real IP after the
edge router gets back online even if it was down for a while.
I have hooked up a Connman Restart every 5 mins of no connectivity and this
did work last night (2am) at one of the 'bad' sites.
Next step for me is to write some Python to interrogate, log and report ETH0
ip and state during the outages.
Once I have some data I will post it so you can take a look.
From: Daniel Wagner [mailto:email@example.com]
Sent: Wednesday, May 3, 2017 4:59 PM
To: Bill <bilmar(a)cfl.rr.com>
Subject: Re: Best Practices to reestablish DHCP Ethernet
On 04/27/2017 01:20 AM, Bill wrote:
I have a number of Debian Jessie Beaglebones running DHCP using
1.33 in the field at various customer sites with multiple Network
providers and routers. All work well except two which seem to lose
ethernet IP's at random intervals but always come back after a
physical box reboot.
All the beaglebones are exactly the same? Are all of them working in the
same network, attached to the same switch?
What is the appropriate action to take in code when connectivity is
lost for say 5 mins due to an unknown problem:
Service connman restart ?
Well in theory ConnMan should handles this correctly. But as quick
workaround having a watchdog restarting ConnMan sounds like a good idea.
Obvoulsy, it would be good to figure out what causes this problem and try to
fix that in ConnMan :)
Do I need to renew dhclient or is it not used by Connman?
ConnMan has an internal DHCP client. If you run dhclient concurrent to
ConnMan you will get two IP address assigned to the same interface.
Further, would you expect Connman to ALWAYS just work & pull a
169 IP after recovery from a router outage because it keeps trying
to get a real address - suggesting something more serious has
happened that may require me to reboot my HW?
If DHCP doesn't work, ConnMan falls back to link local addresses. But it
will keep trying DHCP (using a simple backoff algorithm). Can you check if
ConnMan sees the LOWER_UP on the interface?
I realize that the best approach is to solve the problem but with no
control over the customer's equipment I want to have a reasonable 'get
me back' system.
For the time being until we find the real source of the problem the watchdog
could mitigate the issue.
This email has been checked for viruses by Avast antivirus software.