OSMC on Vero V DHCP attributes?

Help and Support Vero V
1

This may be an obscure question and I have resolved the issue but the behavior has me asking the questions. I noticed on one of my Vero Vs since upgrading from the Vero 4K+ that my weekly backups were failing. After some troubleshooting I found out that shortname resolution to my backup server (server2) was failing. If I added my local domain (since I run my own DNS servers) it worked (i.e. ping server2.mydomain.com). I am pretty sure this worked previously on the Vero 4K+.

I ended up adding “search mydomain.com” to the resolv.conf file which resolved the issue but it made me wonder why OSMC isn’t taking this from my DHCP server, which hands out the domain name ? I am not a Debian expert but I just built an Ubuntu 22.0.4.3 VM today and it worked perfectly and automatically updated the resolv.conf file from the DHCP data.

Should OSMC on a Vero V honor the domain name data from DHCP ? The manual search addition worked on all 3 of my Vero Vs.

Thanks,

Jeff

2

This is unchanged from Vero 4K+ however I did recently (ish) re-enable DNS proving so maybe that’s not picking things up.

Check /etc/osmc/connman.prefs for differences on the working vs problematic systems.

3

I’ll have to reconnect a Vero 4K+ to see if they actually exhibit this behavior. I can do that tomorrow. Thee is no file named connman.prefs in the /etc/osmc/ folder.

osmc@Kodi-Florida:/etc/osmc$ ls -la
total 16
drwxr-xr-x 4 root root 4096 Aug 7 11:24 .
drwxr-xr-x 74 root root 4096 Dec 24 14:07 …
drwxr-xr-x 2 root root 4096 Aug 7 11:24 apps.d
drwxr-xr-x 2 root root 4096 Aug 7 11:22 prefs.d

Jeff

4

Check under prefs.d— it’s probably called ConnMan. I’m not near a computer until tomorrow evening.

5

Not there either. This is not urgent at all so don’t worry about it. I have it working with the search addition to resolv.conf. I just found the behavior odd and wanted to raise it for awareness.

osmc@Kodi-Florida:~/.kodi/temp$ cd /etc/osmc/prefs.d
osmc@Kodi-Florida:/etc/osmc/prefs.d$ ls -la
total 20
drwxr-xr-x 2 root root 4096 Aug 7 11:22 .
drwxr-xr-x 4 root root 4096 Aug 7 11:24 …
-rwxr-xr-x 1 root root 96 Jul 28 20:41 devel_update_preferences
-rwxr-xr-x 1 root root 98 Jul 28 20:41 stats_preferences
-rwxr-xr-x 1 root root 87 Jul 28 20:41 update_preferences

I did a global find for connman and ConnMan and only found this:

osmc@Kodi-Florida:~$ sudo find / -name connman > output.txt
find: ‘/proc/14731/task/14731/net’: Invalid argument
find: ‘/proc/14731/net’: Invalid argument
osmc@Kodi-Florida:~$ more output.txt
/var/lib/connman
/usr/lib/connman
/usr/include/connman

Thanks,

Jeff

6

Are you sure you are up to date?
On both Vero4k and VeroV this looks like below (obviously last file only on the VeroV)

osmc@osmc-verov:~$ ls -lah /etc/osmc/prefs.d/
total 32K
drwxr-xr-x 2 root root 4.0K Dec 19 22:20 .
drwxr-xr-x 4 root root 4.0K Jan  1  2020 ..
-rw-r--r-- 1 root root  256 Nov 16 09:43 connman
-rwxr-xr-x 1 root root   96 Aug 30 22:50 devel_update_preferences
-rwxr-xr-x 1 root root   98 Aug 30 22:50 stats_preferences
-rwxr-xr-x 1 root root   87 Aug 30 22:50 update_preferences
-rwxr-xr-x 1 root root  126 Nov 14 05:23 verov_remote_preferences
7

So all 3 of my Vero Vs are on different releases:

August release

osmc@Kodi-BR:~/.kodi/temp$ ls -la /etc/osmc/prefs.d/
total 20
drwxr-xr-x 2 root root 4096 Oct  9 19:04 .
drwxr-xr-x 4 root root 4096 Aug  7 11:24 ..
-rwxr-xr-x 1 root root   96 Jul 28 20:41 devel_update_preferences
-rwxr-xr-x 1 root root   98 Jul 28 20:41 stats_preferences
-rwxr-xr-x 1 root root   87 Jul 28 20:41 update_preferences

July release

osmc@Kodi-Florida:~/.kodi/temp$ ls -la /etc/osmc/prefs.d/
total 20
drwxr-xr-x 2 root root 4096 Aug  7 11:22 .
drwxr-xr-x 4 root root 4096 Aug  7 11:24 ..
-rwxr-xr-x 1 root root   96 Jul 28 20:41 devel_update_preferences
-rwxr-xr-x 1 root root   98 Jul 28 20:41 stats_preferences
-rwxr-xr-x 1 root root   87 Jul 28 20:41 update_preferences

December release

osmc@Kodi-Test:~/.kodi/temp$ ls -la /etc/osmc/prefs.d/
total 28
drwxr-xr-x 2 root root 4096 Dec 23 11:14 .
drwxr-xr-x 4 root root 4096 Aug  7 11:24 ..
-rw-r--r-- 1 root root  256 Nov 15 20:43 connman
-rwxr-xr-x 1 root root   96 Jul 28 20:41 devel_update_preferences
-rwxr-xr-x 1 root root   98 Jul 28 20:41 stats_preferences
-rwxr-xr-x 1 root root   87 Jul 28 20:41 update_preferences
-rwxr-xr-x 1 root root  126 Nov 13 16:23 verov_remote_preferences

So I do see the extra 2 files with the December release. I looked in connman on the December release and dnsproxy was set to yes. I changed to no and rebooted. resolv.conf got updated properly with the DHCP supplied DNS servers and the suffix search order added. Short name resolution works as expected.

So as I upgrade the other 2 Vero V devices I’ll make the same connman change. I keep on different versions to help me with my Kodi addon development testing and similar troubleshooting.

Thanks for the help,

Jeff

8

So after my recent Vero V software upgrades the dnsproxy value got reset back to yes and I lost shortname resolution again. Is there a way to keep the upgrades from resetting the value back to yes ?

Thanks,

Jeff

9

The setting is persistent across updates. The setting path changed a couple of updates ago however.

10

Sam,

I am not quite following here. The 2 Vero Vs that I checked were running the December release and recently upgraded to February release and shortname resolution stopped working. I can tell because I have a weekly backup job and can see when they stopped. The OSMC backup job saves the backup to an SMB share which relies on shortnames, which is how I see it stop working.

So I have the connman file set for dnsproxy=no . is there anything else I need to do to keep this from reverting to yes ? I could write a cron job to check it regularly but would prefer not to.

Thanks,

Jeff

11

Anything in /etc is not modified when updating OSMC, as these are user configured files.

We mark them as conffiles in our Debian packaging.

As explained, the file location changed once, which means any changes would need to be re-applied once if made. Any changes now will be preserved.

As mentioned in the December update release notes:

  • Unify ConnMan preferences file with /etc/osmc/prefs.d directory convention.

This commit should make it clear what’s changed:

12

Ok. That is clear now. I’ll continue to keep an eye on it.

Thanks,

Jeff

13

It won’t occur going forward. The preferences file was just in a place that wasn’t consistent with where we store OSMC specific settings.

Cheers
Sam