Issue connecting new Vero 4K

Help and Support Vero 4K / Vero 4K +
1

On initial connection, I followed the install process, enabling ssh and ensuring I was using ethernet.
I picked up configuration with DHCP and found I ended with status: Eth0 (no internet)

Using wifi, similar but status:WLAN0(no internet)

Obviously tried to update, but unsurprisingly got

osmc@osmc:~$ sudo apt-get update
Err:1 Index of /debian buster InRelease
Connection failed [IP: 151.101.18.132 80]
Err:2 http://security.debian.org buster/updates InRelease
Connection failed [IP: 199.232.174.132 80]
Err:3 http://apt.osmc.tv buster InRelease
Connection failed [IP: 77.68.92.173 80]
Err:4 Index of /debian buster-updates InRelease
Connection failed [IP: 151.101.18.132 80]
Reading package lists… Done
W: Failed to fetch http://ftp.debian.org/debian/dists/buster/InRelease Connection failed [IP: 151.101.18.132 80]
W: Failed to fetch http://ftp.debian.org/debian/dists/buster-updates/InRelease Connection failed [IP: 151.101.18.132 80]
W: Failed to fetch http://security.debian.org/dists/buster/updates/InRelease Connection failed [IP: 199.232.174.132 80]
W: Failed to fetch http://apt.osmc.tv/dists/buster/InRelease Connection failed [IP: 77.68.92.173 80]
W: Some index files failed to download. They have been ignored, or old ones used instead.

Ping gives me ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=119 time=23.409 ms
64 bytes from 8.8.8.8: seq=1 ttl=119 time=22.917 ms
64 bytes from 8.8.8.8: seq=2 ttl=119 time=23.288 ms
64 bytes from 8.8.8.8: seq=3 ttl=119 time=22.993 ms
64 bytes from 8.8.8.8: seq=4 ttl=119 time=23.551 ms
64 bytes from 8.8.8.8: seq=5 ttl=119 time=23.166 ms
64 bytes from 8.8.8.8: seq=6 ttl=119 time=23.499 ms
64 bytes from 8.8.8.8: seq=7 ttl=119 time=23.478 ms
^C
— 8.8.8.8 ping statistics —
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max = 22.917/23.287/23.551 ms

Traceroute gives
osmc@osmc:~$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets
1 _gateway (192.168.1.1) 1.485 ms 0.862 ms 1.281 ms
2 * * *
3 63.130.105.134 (63.130.105.134) 19.702 ms 19.884 ms 19.877 ms
4 90.255.251.93 (90.255.251.93) 20.593 ms 20.435 ms 90.255.251.2 (90.255.251.2) 22.362 ms
5 74.125.242.65 (74.125.242.65) 22.180 ms 108.170.246.161 (108.170.246.161) 22.527 ms 108.170.246.129 (108.170.246.129) 22.990 ms
6 216.239.41.241 (216.239.41.241) 24.326 ms 209.85.252.181 (209.85.252.181) 22.264 ms dns.google (8.8.8.8) 23.160 ms

ifconfig
osmc@osmc:~$ ifconfig
eth0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC> mtu 1500
inet 192.168.1.80 netmask 255.255.255.0 broadcast 192.168.1.255
ether 90:0e:b3:2d:8e:a9 txqueuelen 1000 (Ethernet)
RX packets 22340 bytes 2891770 (2.7 MiB)
RX errors 0 dropped 24 overruns 0 frame 0
TX packets 3562 bytes 1063511 (1.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 30

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ip addr
osmc@osmc:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 90:0e:b3:2d:8e:a9 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.80/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 08:e9:f6:55:f4:2e brd ff:ff:ff:ff:ff:ff

ip ro
osmc@osmc:~$ ip ro
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.80
192.168.1.1 dev eth0 scope link

I’d see suggestions to set DNS to 8.8.8.8, which I did - see
osmc@osmc:~$ cat /etc/resolv.conf

Generated by Connection Manager

nameserver 8.8.8.8

but the failure persisted.

arp -an shows
osmc@osmc:~$ arp -an
? (192.168.1.194) at 44:a8:42:e7:4c:11 [ether] on eth0
? (192.168.1.1) at 20:b0:01:bd:f3:18 [ether] on eth0
? (192.168.1.90) at b8:27:eb:c6:23:7a [ether] on eth0

Any suggestions?

2

Hi,

Can you get the output of ping?

It seems you’re familiar with the command line, so we should be able to work this out fairly easily.

Is the date/time set correctly? This is a good indicator of network connectivity.

3

I see you’ve updated the post. I’ll take another look.

4

What happens with ping google.co.uk?

Looks like an odd DNS issue.

5

and date gave me at 15:41
osmc@osmc:~$ date
Thu Mar 10 15:41:14 UTC 2022

6

osmc@osmc:~$ ping google.co.uk
PING google.co.uk (142.250.180.3): 56 data bytes
64 bytes from 142.250.180.3: seq=0 ttl=119 time=22.798 ms
64 bytes from 142.250.180.3: seq=1 ttl=119 time=23.351 ms
64 bytes from 142.250.180.3: seq=2 ttl=119 time=23.034 ms
64 bytes from 142.250.180.3: seq=3 ttl=119 time=22.918 ms
64 bytes from 142.250.180.3: seq=4 ttl=119 time=22.973 ms
64 bytes from 142.250.180.3: seq=5 ttl=119 time=23.071 ms
64 bytes from 142.250.180.3: seq=6 ttl=119 time=23.156 ms
64 bytes from 142.250.180.3: seq=7 ttl=119 time=23.004 ms
64 bytes from 142.250.180.3: seq=8 ttl=119 time=23.158 ms
64 bytes from 142.250.180.3: seq=9 ttl=119 time=23.228 ms
64 bytes from 142.250.180.3: seq=10 ttl=119 time=23.080 ms
64 bytes from 142.250.180.3: seq=11 ttl=119 time=23.238 ms
64 bytes from 142.250.180.3: seq=12 ttl=119 time=23.084 ms
64 bytes from 142.250.180.3: seq=13 ttl=119 time=23.190 ms
64 bytes from 142.250.180.3: seq=14 ttl=119 time=23.052 ms
64 bytes from 142.250.180.3: seq=15 ttl=119 time=23.169 ms
64 bytes from 142.250.180.3: seq=16 ttl=119 time=23.259 ms
64 bytes from 142.250.180.3: seq=17 ttl=119 time=23.116 ms
64 bytes from 142.250.180.3: seq=18 ttl=119 time=23.259 ms
^C
— google.co.uk ping statistics —
19 packets transmitted, 19 packets received, 0% packet loss
round-trip min/avg/max = 22.798/23.112/23.351 ms

7

Well that’s… weird.

Can you run grab-logs -A and send me the URL?
If that commands works, it proves that resolution to paste.osmc.tv worked via DNS as well.

Sam

8

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

9

Firstly – although not related, change GUI Resolution: 4096x2160 @ 24p
to 1080p and enable Adjust Refresh Rate. This will give a better experience and we will switch to 4K automatically when needed.

Are you on mobile broadband? Your IP suggests you are on a Vodafone connection. We’ve seen some issues with them using a transparent proxy in the past.

You could temporarily try change http:// to https:// for the Debian repositories in /etc/apt/sources.list and try update. Unfortunately the OSMC APT repository doesn’t support HTTPS natively yet, but it should give us an idea if something is messing around with traffic in the middle.

Sam

10

Yes to Vodafone, no to mobile

11

Thanks for clarifying – that’s interesting to know.

It does look like the connection succeeds via HTTPS (from your PM) but not via HTTP.

We’ve seen some strange behaviour with Vodafone in the past, and a search confirms this too: After Nearly a Year - Vodafone Broadband Trying to Fix Imgur Bug - ISPreview UK (albeit this report is quite old)