We have a product that we are selling that uses the Beaglebone Black SBC with Debian
Jessie as a small network appliance in a residential environment. Connman is the network
manager in this distribution. We are experiencing a very random issue where occasionally
the DNS servers being returned by a network DHCP server get corrupted. All other
configurations are fine - IP address, gateway, etc. When this happens, the unit still has
local network connection but loses the connection to the Internet (as you would expect).
This impacts the operation of the unit in a very negative manner. We have a user
interface that shows the configuration settings and when the Primary DNS server gets
corrupted, the user interface field normally shows the DNS server as " [ ".
The Secondary DNS server is mostly blank when this happens. Manually changing the Primary
DNS Server to a good nameserver always resolves the issue.
It happens often enough that it's annoying us because of the support calls we get, but
it happens so infrequently that it's very difficult to reproduce. In fact, I've
never seen it on my test units - I've only seen it on units installed in the field.
In almost all applications, the network appliance is connected directly to the local
network router provided by the ISP or the user. We believe that something happens from
the router that causes this issue (and it could even be with specific routers - we just
don't know). In one particular instance, a unit had been working for several months
just fine, but then there was a power outage, and after rebooting from the power outage,
the Primary DNS was showing the " [ " and the Secondary DNS was blank, and we
had to manually enter a good nameserver.
Since it's so hard to reproduce, I'm looking at some bandaid approaches using some
scripts. But, before I did that, I thought I'd check to see if connman might have
some options that I could use to resolve the issue. One potentially available option I
was reading about was the use of the nodnsproxy option. This one might be extremely hard
to determine if it has resolved the issue or not, as it is so hard to reproduce but would
be simple to implement, if it were a potential solution. This would assume that DNS proxy
feature in connman was in conflict with the external DNS server, as I was reading, which
might be a real stretch.
A second option I was looking at was the "FallbackNameservers" option. However,
I don't understand how this works. Does connman do a test to verify Internet
connection or proper DNS operation, and if it fails that test, it "falls back"
to a secondary DNS server and then if that also fails, it falls back to the
"FallbackNameservers"? If this is how this works, this is a possibility to
explore - I would try setting the FallBack servers to available DNS servers such as the
Google nameserver at 22.214.171.124.
By the way, the connman version on my Debian distribution is V1.32. I see that connman is
up to at least 1.37. Is it possible that upgrading connman might resolve this issue?
I apologize - I'm comfortable with simple networking but I'm by no means a
networking expert and I'm really hoping for a sanctioned option to resolve this
Any guidance would be appreciated.