Update for January failed

Alright, look out. This post got long. Two extra tests:

I unplugged the wire from the back of the OSMC device and plugged it into my laptop (the same one from earlier.)
alexius@Quicksilver:~> curl https://ftp.fau.de/osmc/osmc/apt/pool/main/v/vero2-mediacenter-osmc/vero2-mediacenter-osmc_17.6.0-22_armhf.deb > /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 38.0M 100 38.0M 0 0 958k 0 0:00:40 0:00:40 --:–:-- 2547k

Then I unscrewed the WAP and plugged the OSMC directly into the port that powers the WAP:
root@Oswin:/home/osmc# curl https://ftp.fau.de/osmc/osmc/apt/pool/main/v/vero2-mediacenter-osmc/vero2-mediacenter-osmc_17.6.0-22_armhf.deb > /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
19 38.0M 19 7488k 0 0 2417k 0 0:00:16 0:00:03 0:00:13 2418k
curl: (56) SSL read: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac, errno 0

I also realized I had forgotten a detail, the TP-Link is not in the loop:
Typically: OSMC ----- WAP ------ PoE Adapter — Router — Cable Modem
First Test: OpenSUSE Laptop ----- WAP ------ PoE Adapter — Router — Cable Modem
Second Test: OSMC ----- PoE Adapter — Router — Cable Modem

So, the only thing consistently giving errors is the OSMC’s wired connection. This brings up the obvious next test of the OSMC’s WiFi, so I connected that instead:
wlan0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC> mtu 1500
inet 192.168.23.16 netmask 255.255.255.0 broadcast 192.168.23.255
ether 34:c3:d2:32:83:21 txqueuelen 1000 (Ethernet)
RX packets 897 bytes 251073 (245.1 KiB)
RX errors 0 dropped 11 overruns 0 frame 0
TX packets 438 bytes 96391 (94.1 KiB)
TX errors 0 dropped 2 overruns 0 carrier 0 collisions 0

And the test:
root@Oswin:/home/osmc# curl https://ftp.fau.de/osmc/osmc/apt/pool/main/v/vero2-mediacenter-osmc/vero2-mediacenter-osmc_17.6.0-22_armhf.deb > /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 38.0M 100 38.0M 0 0 801k 0 0:00:48 0:00:48 --:–:-- 1324k

It was slow, but successful. So, while it was on the WiFi…
root@Oswin:/home/osmc# apt-get update && apt-get dist-upgrade
Hit:1 http://security.debian.org stretch/updates InRelease
Hit:2 Index of /osmc/osmc/apt stretch InRelease
Ign:3 Index of /mirror/debian stretch InRelease
Hit:4 Index of /mirror/debian stretch-updates InRelease
Hit:5 Index of /mirror/debian stretch Release
Reading package lists… Done
Reading package lists… Done
Building dependency tree
Reading state information… Done
Calculating upgrade… Done
The following NEW packages will be installed:
vero2-image-3.10.105-9-osmc
The following packages will be upgraded:
armv7-eventlircd-osmc armv7-splash-osmc base-files-osmc curl libcurl3 libcurl3-gnutls libtiff5 mediacenter-addon-osmc vero2-kernel-osmc vero2-mediacenter-osmc
10 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 39.9 MB/57.6 MB of archives.
After this operation, 26.6 MB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 Index of /osmc/osmc/apt stretch/main armhf vero2-mediacenter-osmc armhf 17.6.0-22 [39.9 MB]
Fetched 39.9 MB in 1min 2s (641 kB/s)
Preconfiguring packages …
Selecting previously unselected package vero2-image-3.10.105-9-osmc.
(Reading database … 21928 files and directories currently installed.)
Preparing to unpack …/00-vero2-image-3.10.105-9-osmc_9_armhf.deb …
Examining /etc/kernel/preinst.d/
Done.
Unpacking vero2-image-3.10.105-9-osmc (9) …
Preparing to unpack …/01-armv7-splash-osmc_1.3.6_armhf.deb …
Unpacking armv7-splash-osmc (1.3.6) over (1.3.5) …
Preparing to unpack …/02-base-files-osmc_2.5.0_all.deb …
Unpacking base-files-osmc (2.5.0) over (2.4.7) …
Preparing to unpack …/03-vero2-kernel-osmc_3.9.19_armhf.deb …
Unpacking vero2-kernel-osmc (3.9.19) over (3.9.13) …
Preparing to unpack …/04-curl_7.52.1-5+deb9u4_armhf.deb …
Unpacking curl (7.52.1-5+deb9u4) over (7.52.1-5+deb9u3) …
Preparing to unpack …/05-libcurl3_7.52.1-5+deb9u4_armhf.deb …
Unpacking libcurl3:armhf (7.52.1-5+deb9u4) over (7.52.1-5+deb9u3) …
Preparing to unpack …/06-mediacenter-addon-osmc_3.0.655_all.deb …
Unpacking mediacenter-addon-osmc (3.0.655) over (3.0.654) …
Preparing to unpack …/07-vero2-mediacenter-osmc_17.6.0-22_armhf.deb …
Unpacking vero2-mediacenter-osmc (17.6.0-22) over (17.6.0-15) …
Preparing to unpack …/08-armv7-eventlircd-osmc_1.3.0_armhf.deb …
Unpacking armv7-eventlircd-osmc (1.3.0) over (1.2.8) …
Preparing to unpack …/09-libcurl3-gnutls_7.52.1-5+deb9u4_armhf.deb …
Unpacking libcurl3-gnutls:armhf (7.52.1-5+deb9u4) over (7.52.1-5+deb9u3) …
Preparing to unpack …/10-libtiff5_4.0.8-2+deb9u2_armhf.deb …
Unpacking libtiff5:armhf (4.0.8-2+deb9u2) over (4.0.8-2+deb9u1) …
Setting up vero2-image-3.10.105-9-osmc (9) …

 Hmm. There is a symbolic link /lib/modules/3.10.105-9-osmc/build
 However, I can not read it: No such file or directory
 Therefore, I am deleting /lib/modules/3.10.105-9-osmc/build


 Hmm. The package shipped with a symbolic link /lib/modules/3.10.105-9-osmc/source
 However, I can not read the target: No such file or directory
 Therefore, I am deleting /lib/modules/3.10.105-9-osmc/source

Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 3.10.105-9-osmc /boot/uImage-3.10.105-9-osmc
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal-osmc 3.10.105-9-osmc /boot/uImage-3.10.105-9-osmc
run-parts: executing /etc/kernel/postinst.d/inform-updater 3.10.105-9-osmc /boot/uImage-3.10.105-9-osmc
run-parts: executing /etc/kernel/postinst.d/upload-to-nand 3.10.105-9-osmc /boot/uImage-3.10.105-9-osmc
6+1 records in
6+1 records out
6774784 bytes (6.8 MB, 6.5 MiB) copied, 0.82569 s, 8.2 MB/s
Setting up armv7-splash-osmc (1.3.6) ...
Processing triggers for mime-support (3.60) ...
Setting up libcurl3:armhf (7.52.1-5+deb9u4) ...
Setting up mediacenter-addon-osmc (3.0.655) ...
Setting up libcurl3-gnutls:armhf (7.52.1-5+deb9u4) ...
Setting up armv7-eventlircd-osmc (1.3.0) ...
Setting up libtiff5:armhf (4.0.8-2+deb9u2) ...
Setting up base-files-osmc (2.5.0) ...
Fixing permissions on busybox.
Setting up vero2-kernel-osmc (3.9.19) ...
Setting up vero2-mediacenter-osmc (17.6.0-22) ...
Processing triggers for libc-bin (2.24-11+deb9u1) ...
Setting up curl (7.52.1-5+deb9u4) ...
root@Oswin:/home/osmc# 

After that, a reboot and I am now showing that I am on OSMC January 2018 2017.18-1.

In conclusion, apparently the problem is with the wired port on the OSMC device, or the software using eth0. Is there anything that can be done about that? What was the warranty on this device?

The warranty is one year from date of receipt.
I’m not sure Ethernet is the problem here. It could be a bad switch, or bad router?

At the top of my last post, I tried the exact same cord and port (and switch and router) with a laptop, which worked fine. Switching to WiFi on the OSMC also worked, which points to the eth0.

Just a thought. These in-wall Unifi units are powered using PoE. I don’t know which unit you have but I looked on the Unifi site and the ones I found seem to have two external ethernet ports: one with PoE and one without. If yours is similar, you might have used the one with PoE; you didn’t say.

Here, you clearly used the port with PoE.

So there’s at least a possibility that PoE is adversely affecting the Vero2’s ethernet interface. You need to remove PoE entirely from the picture and test again.

One of the ports in the WAP is a non-POE port (which still failed the test). Additionally, the successful test with the laptop was into the same port (with the PoE) as the OSMC.

Different devices can have different electrical characteristics. You need to be methodical and eliminate all possibilities.

maybe install ethtool and check the negotiation
sudo apt-get install ethtool
sudo ethtool eth0

root@Oswin:/home/osmc# sudo ethtool eth0
Settings for eth0:
Supported ports: [ TP AUI BNC MII FIBRE ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: external
Auto-negotiation: on
Supports Wake-on: ug
Wake-on: d
Current message level: 0x0000003f (63)
drv probe link timer ifdown ifup
Link detected: yes

Have you tried to connect the Vero to the TP-Link and then ran iperf3 against one of the other machines connected to the TP-Link?

No, I have not. I have not worked with iperf3 to know what I would be doing, and the Vero 2 is mounted in such a way that moving it to new locations become more difficult than removing the WAP it is connected to.

Also, since the exact same wiring with a laptop instead of the Vero 2 didn’t give an error, and the Vero 2 worked with WiFi instead of with the wired connection, I think this definitively points to a problem with the Vero 2’s wired connection.

Since the Vero 2 is out of warranty by a good bit at this point, It’ll be easier to manually run the update over the wifi once a month or so until I replace it.

Iperf3: Run a “server” process on one machine:

iperf3 -s

then a client process on another machine

iperf3 -c <IP of server>

Host:
alexius@Chance:~> iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
iperf3: error - unable to receive parameters from client:
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
iperf3: error - unable to receive parameters from client:
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------

OSMC Client:
osmc@Oswin:~$ iperf -c 192.168.23.5 -p 5201
------------------------------------------------------------
Client connecting to 192.168.23.5, TCP port 5201
TCP window size: 20.7 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.23.16 port 47094 connected with 192.168.23.5 port 5201
write failed: Connection reset by peer
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 0.0 sec 22.6 KBytes 56.9 Mbits/sec
osmc@Oswin:~$ iperf -c 192.168.23.5 -p 5201
------------------------------------------------------------
Client connecting to 192.168.23.5, TCP port 5201
TCP window size: 20.7 KByte (default)
------------------------------------------------------------
write failed: Connection reset by peer
[ 3] local 192.168.23.16 port 47095 connected with 192.168.23.5 port 5201
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 0.0 sec 22.6 KBytes 79.0 Mbits/sec

I’m not quite convinced it’s a hardware issue on the Vero 2.

commit e32672b188cdafe8d013cc10818d2dbe69d8a7a9
Author: Sam Nazarko <email@samnazarko.co.uk>
Date:   Thu Jan 5 22:31:53 2017 +0000

    meson8b_vero2: switch to stmmac driver
    
    Signed-off-by: Sam Nazarko <email@samnazarko.co.uk>

Early in 2017, we switched Ethernet driver to the upstream version which was more maintained.

If you try an image like 2016.12-1, and it works, then the problem is caused by the new driver.

I’ve built a new kernel sans CEC log spam.

  1. Login via the command line
  2. Edit the file /etc/apt/sources.list
  3. Add the following line: deb http://apt.osmc.tv stretch-devel main
  4. Run the following commands to update: sudo apt-get update && sudo apt-get dist-upgrade && reboot
  5. Your system should have have received the update.

Please see if the issue is resolved. Updating from a 2016 version would be a pretty good way to test things.

I also recommend you edit /etc/apt/sources.list again and remove the line that you added after updating. This will return you to the normal update channel.

Sam

I am skipping the cut and paste, but I updated the sources.list, ran the updates, which failed due to check-sums. I disconnected the wired network, then used wifi for the updates, which worked.

Is there a way to just switch to another Ethernet driver without re-flashing the entire device again?

Not trivially unfortunately, because it also involves a Device Tree change.

Sam

It looks like 2017-01-1 is as far back as it goes:

Hi,

http://ftp.fau.de/osmc/osmc/download/installers/diskimages/OSMC_TGT_vero2_20161224.img.gz

Thanks Tom.

Thank you! Downloading now, will update afterwards.

Once I have 2016 installed, should I just attempt to upgrade again? Or is there a different test you would like?

Try upgrade.
If it works… interesting…

Then try the kernel suggested above and post debug logs.

Sam

I am getting the 2016 kernel now. Here are the debug logs from the 2018 one you just had me install:

Logs available at https://paste.osmc.tv/ucewamuwim