Wired network interface does not work

When I leave it in DHCP mode it is configuring itself repeatedly without end.
When I set it manually, there is no connectivity.

The connection is not registered on router. (Even when plugged in directly into it.)

Strange enough, WiFi works ok.

Here are the logs:
http://paste.osmc.io/ekufohecif

Can you attempt to update from the MyOSMC addon while on wifi and then try again?

No updates available. (cca 10 mins ago)

Can you explain this in a bit more detail?

Have you tried rebooting? It looks like My OSMC may have got stuck configuring your connection. The output of ifconfig after a reboot may yield some clues. Make sure your system is up to date.

What version are you on? 2016.12-1 is the latest version.

It tries to configure itself for about 3 minutes, then settles up with a 169.254.238.138 / 255.255.0.0 (which are probably defaults for no connection…)

Yes. Updated, rebooted, reinstalled from scratch and repeated the whole process over.

osmc@vero2:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 08:61:60:11:26:45
      inet addr:169.254.238.138  Bcast:169.254.255.255  Mask:255.255.0.0
      UP BROADCAST RUNNING MULTICAST DYNAMIC  MTU:1500  Metric:1
      RX packets:2055 errors:0 dropped:0 overruns:0 frame:0
      TX packets:3470 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000
      RX bytes:1219130 (1.1 MiB)  TX bytes:1567049 (1.4 MiB)
      Interrupt:40

lo        Link encap:Local Loopback
      inet addr:127.0.0.1  Mask:255.0.0.0
      inet6 addr: ::1/128 Scope:Host
      UP LOOPBACK RUNNING  MTU:65536  Metric:1
      RX packets:0 errors:0 dropped:0 overruns:0 frame:0
      TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:0
      RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr 34:c3:d2:43:0a:9e
      inet addr:192.168.1.115  Bcast:192.168.1.255  Mask:255.255.255.0
      UP BROADCAST RUNNING MULTICAST DYNAMIC  MTU:1500  Metric:1
      RX packets:142330 errors:0 dropped:706 overruns:0 frame:0
      TX packets:76652 errors:0 dropped:2 overruns:0 carrier:0
      collisions:0 txqueuelen:1000
      RX bytes:189815753 (181.0 MiB)  TX bytes:12078498 (11.5 MiB)

Yes.

osmc@vero2:~$ grep VERSION_ID /etc/os-release
VERSION_ID="2016.12-1"

Tried a different cable? Or a different port on your switch/router?

Yes. Tried different ports, different cables. Raspberry PI2 and 3 with OSMC are working on this cable without problems. Also any other device I tried to plug in. The cabling in walls is CAT7, the patch cable is higher quality CAT6.

The behavior is the same regardless of port it is plugged in (tried both switch and router).

I had a closer look at your log. It looks like OSMC can obtain an IP address via DHCP of 192.168.1.158, and manages to do so early on in the boot:

Dec 30 17:03:30 vero2 connmand[321]: eth0 {del} route fe80:: gw :: scope 0 <UNIVERSE>
Dec 30 17:03:30 vero2 connmand[321]: eth0 {del} route ff00:: gw :: scope 0 <UNIVERSE>
Dec 30 17:03:30 vero2 connmand[321]: eth0 {add} address 192.168.1.158/24 label eth0 family 2
Dec 30 17:03:30 vero2 connmand[321]: eth0 {add} route 192.168.1.0 gw 0.0.0.0 scope 253 <LINK>
Dec 30 17:03:30 vero2 connmand[321]: eth0 {add} route 192.168.1.1 gw 0.0.0.0 scope 253 <LINK>
Dec 30 17:03:30 vero2 connmand[321]: eth0 {add} route 192.168.100.1 gw 192.168.1.1 scope 0 <UNIVERSE>
Dec 30 17:03:30 vero2 connmand[321]: eth0 {add} route 8.8.8.8 gw 192.168.1.1 scope 0 <UNIVERSE>
Dec 30 17:03:30 vero2 connmand[321]: eth0 {RX} 18 packets 2561 bytes
Dec 30 17:03:30 vero2 connmand[321]: eth0 {TX} 16 packets 3063 bytes
Dec 30 17:03:30 vero2 connmand[321]: eth0 {update} flags 36867 <UP>

However it also looks like the link is going down sporadically. There can be a few reasons for this:

  • Bad patch cable
  • A conflict on the network
  • Some software conflict on the device itself
  • Hardware issue

Without knowing more about your network, it’s a little hard to speculate what the issue may be, but I am sure we can get to the bottom of this:

  • Have you experienced any other problems with the device? Is the plug connected directly to the wall? Sometimes if a device isn’t getting enough power, the network can drop in or out. But if this was the case, I would expect to see this with WiFi as well.
  • Does running the following commands help? sudo rmmod am_net8218_osmc && sudo modprobe am_net_8218_osmc. This will reload the Ethernet module and reset the PHY.
  • Have you installed any other software on your device?
  • How familiar are you with the command line and networking? There are a couple of things that we could explore. I would start by running a standard cat5e from the Vero 2 to your Raspberry Pi. You don’t need DHCP etc, but if you can just see if the activity lights stay on and if the link stays up in dmesg, then it may give you some clues.

Yes, saw it myself. But I do not know what it means.

I would leave this one out. Other devices are working on the same cable.

May be, but I find it not probable, because Raspbery Pi 2/3 with OSMC are working well (each one, including vero2 has unique name).

Can’t elaborate on those two, as I am not linux savvy. Even if it was a hardware problem, I would not know where to look.

Nope, did not see other problems.

rmmod: ERROR: Module am_net8218_osmc is not currently loaded

Nope, clean install.

I am a programmer by occupation, so command line will not scare me. Networking is not my field, but I do know some basics. I am up to try to solve this, but I will need precise instructions. With the RbPi setup I am at lost with “if the link stays up in dmesg”… What should I look for?

Maybe related, maybe not, I have found strange error in the logs (http://paste.osmc.io/oqinenaxeg):

19:55:52 T:2825503728   ERROR: EXCEPTION Thrown (PythonToCppException) : -->Python callback/script returned the following error<--
                                             - NOTE: IGNORING THIS CAN LEAD TO MEMORY LEAKS!
                                            Error Type: <class 'dbus.exceptions.DBusException'>
                                            Error Contents: org.freedesktop.DBus.Error.UnknownObject: Method "SetProperty" with signature "sv" on interface "net.connman.Service" doesn't exist
                                            
                                            Traceback (most recent call last):
                                              File "/usr/share/kodi/addons/script.module.osmcsetting.networking/resources/lib/networking_gui.py", line 386, in onClick
                                                self.handle_wired_selection(controlID)
                                              File "/usr/share/kodi/addons/script.module.osmcsetting.networking/resources/lib/networking_gui.py", line 1000, in handle_wired_selection
                                                osmc_network.apply_network_changes(self.current_network_config, self.internet_protocol)
                                              File "/usr/share/kodi/addons/script.module.osmcsetting.networking/resources/lib/osmc_network.py", line 143, in apply_network_changes
                                                service.SetProperty('Nameservers.Configuration', dbus.Array(dns, signature=dbus.Signature('s')))
                                              File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 145, in __call__
                                                **keywords)
                                              File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in call_blocking
                                                message, timeout)
                                            DBusException: org.freedesktop.DBus.Error.UnknownObject: Method "SetProperty" with signature "sv" on interface "net.connman.Service" doesn't exist
                                            
                                            -->End of Python script error report<--

The error above is occurring because the network seems to be dropped in and out, which is causing problems when OSMC tries to assign an IP address to the adapter.

Can you answer these few questions?

If you have a spare SD card (8GB or larger), you could quickly grab the Android image from Download - OSMC and see if the Ethernet works here. This would probably rule out a software issue quite quickly. The Android image runs off the SD card and won’t erase OSMC off the internal storage.

I’m guessing that when the link is going down, the lights are going off on your switch / router. It’s worth checking that, and if it’s the case, plugging a patch between the Pi and Vero 2. The lights should stay on.

Sam

Sometimes it does not response to remote (and wireless keyboard) in realtime, but buffers the input. And the it plays it rapidly at a later time.

Yes, it is. No power surge protection, no UPS, no frequency filter…

Tried this, but it does not seem to boot off the SD card. At least I can see no difference (System info / Summary / Operating system: OSMC 2016.12-1, kernwl Linux 3.10.104-8-osmc). The wired network behaves the same.

It almost never registers with the router. Rarely there is a message in the router’s log about assigning IP to vero2’s MAC, but it stays in the list of connected clients only for a few seconds. That is when vero2 decides to use some 169.254.. address and never recovers.

I have tried the Pi vs vero2 direct link. The lights seems to lit the same way (one is amber, the other one green and blinks from time to time.) Since you did not specify what to look for, I tried this (about 5 minutes after vero2 boot):

osmc@vero2:~$ dmesg | grep eth0
[    9.707956] eth0: PHY ID 02430c54 at 0 IRQ -1 (0:00) active
[   11.135159] eth0: opened (irq 40).
[   11.135291] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   11.778803] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Make sure your remote is plugged in to the rear USB port. It sounds like you have it in a side port.

Via the command line, type ‘reboot androidv2’ or choose Reboot to Android via the Programs menu in Kodi.

That snippet above seems to suggest that once the link is up, it stays up. If the lights aren’t turning off, then the network should remain up.

Short of trying another cable, I am not sure what to immediately suggest.

The port does not matter, happens with any. But strangely not when booted to android.

Did that, as much I can tell, the wired nic works well in android. But tested only in web browser. I do not know how to browse network for video files in this environment.

I tried it at my parents place (=other city, other router, other cables). Did not work either.

Next I tried to completely reset settings on my router. After that I noticed in router logs, that vero2 tries to get IP every 3 secs or so. It just seems to be not happy with the answer…

Jan  2 19:51:54 dnsmasq-dhcp[2827]: DHCPREQUEST(br0) 192.168.1.9 08:61:60:11:26:45 
Jan  2 19:51:54 dnsmasq-dhcp[2827]: DHCPACK(br0) 192.168.1.9 08:61:60:11:26:45 vero2
Jan  2 19:51:58 dnsmasq-dhcp[2827]: DHCPREQUEST(br0) 192.168.1.9 08:61:60:11:26:45 
Jan  2 19:51:58 dnsmasq-dhcp[2827]: DHCPACK(br0) 192.168.1.9 08:61:60:11:26:45 vero2
Jan  2 19:52:02 dnsmasq-dhcp[2827]: DHCPREQUEST(br0) 192.168.1.9 08:61:60:11:26:45 
Jan  2 19:52:02 dnsmasq-dhcp[2827]: DHCPACK(br0) 192.168.1.9 08:61:60:11:26:45 vero2

etc.etc. until it gives up…

This sounds like a software issue. We recommend the remote receiver is placed in the back port. If it is in any other port then the issue is expected (as they are configured differently). If you can take a small video of the problem with the receiver in the back port then we will look and resolve the issue.

That’s fine. If you can browse a few websites without any problems, then it sounds like it is working. But I’m not sure why you have problems under OSMC at all.

Can you check ifconfig shows the MAC on the bottom of the device?

I have one idea, and I’ll produce a test build to confirm if you’re happy to try.

Terribly sorry – this should all simply work, but sometimes we bump in to some stranger network environments.

Best wishes

Sam

Yes, it is a match.

osmc@vero:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 08:61:60:11:26:45
          inet addr:192.168.1.9  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST DYNAMIC  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:258 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:50848 (49.6 KiB)
          Interrupt:40

Certainly.

Well I am sorry to cause so much trouble.

This is not your fault, it’s more that we haven’t encountered this before.

I will let you know when we have something to test.

Hello,

Apologies for the late reply.

Normally I would suspect some hardware problem, but you have reported that the Android release is not causing problems for you.

Android uses a different Ethernet driver, one that I have planned to transition to for a while, as it does provide better performance, and it is officially mainlined, which means that it is supported upstream in the Linux kernel.

I would be very interested in your feedback regarding this driver. Currently you will be first to test this new driver, which may give better speeds. I will get some other users to test it as well.

Here are the commands to run, via SSH, to test:

wget "https://www.dropbox.com/s/z4emzwk3e18gq16/vero2-image-3.10.104-10-osmc.deb?dl=1" -O kernel.deb
sudo dpkg -i kernel.deb

Then

Change /etc/modules-load.d/eth.conf

from am_net_8218_osmc to stmmac

Now run

reboot

If you still have problems, then I would suggest you try plug the Vero 2 in to a network at work or a different location. Of course, if there are still problems, we will replace the unit for you.

Looking forward to your feedback,

Best wishes

Sam

I have replaced the kernel and driver.

I am at my parents this weekend, but for now it seems to be working. Vero2 can now get IP via DHCP, and the link does not drop (tested by leaving open SSH session). I will do more tests at my place on Sunday.

Hi Michal

Thank you for taking time to report back. I am glad that things seem to be improved now, but I will await your further feedback on Sunday.

The Vero 2 however should have worked for you out of the box. I have arranged for a credit to be applied to your account and this will be explained to you shortly.

Lastly, can you later confirm that the remote works as expected when plugged in the back USB port? You will need to reboot after reinserting the receiver, so you may prefer to do this after shutting down and before booting again

Thanks

Sam