Hi Fabio,
On 12/29/2016 12:19 PM, Fabio Emiliani wrote:
> Dec 24 22:38:26 daemon.info connmand[294]: *(null) {RX} 776
packets
> 148761 bytes*
> Dec 24 22:38:26 daemon.info connmand[294]: *(null) {TX} 825 packets
> 78648 bytes*
> Dec 24 22:38:26 daemon.info connmand[294]: *(null) {update} flags
> 36866 <DOWN>*
These message are from ipconfig.c::update_stats(). For some reason we do
not know the ifname anymore. __connman_ipconfig_newlink() lookups
the ifname via SIOCGIFNAME. The kernel just retuns NULL for the given
index. So I guess the mapping has already been removed from the kernel.
This is harmless, because we use only the index inside ConnMan, never
the ifname. It is just used for debugging reasons.
> Dec 24 22:38:26 daemon.info connmand[294]: *eth0 {newlink} index
5
> address 00:00:00:01:02:03 mtu 1500*
> Dec 24 22:38:26 daemon.info connmand[294]: *eth0 {newlink} index 5
> operstate 2 <DOWN>*
The newlink message is issued from __connman_ipconfig_newlink()
function. That means the kernel has send ConnMan a RTNL message (see
process_newlink() in rtnl.c).
Until 22:35:02 everything goes fine, eth0 interface is up and
running.
After three minutes, at 22:38:26 I see some strange logs. What does
(null) mean? Why the interface is removed and then added again? What can
be the cause of the problem?
Usually, ConnMan tries to keep a connection up and running, so I guess
something else is disconnecting the link. Check also if the
hardware/firmware is doing something funny. For example certain WiFi
chips are known to do strange stuff. I assume from the logs you have an
Ethernet interface. If you have a free USB slot you could try to use an
externel USB Ethernet dongle and see if that is observable.
Another thing is I assume you are running ConnMan without the debug
option? Maybe if you turn it on you get more info what is happening (-d
command line option).
Next thing is to check if there is any other networking daemon running.
Check for dhclient, systemd-networkd or something like that.
Hope that helps.
Thanks,
Daniel