I have a problem with the network connection of 2 Rpi’s with OSMC. ONe is a recent fresh OSMC install(November 2016). The other is a very old install, maybe 18 months old.
Both get their initial network connection OK and all is well. But now I discovered that I can’t reach any internet server from OSMC after a while. No DNS is specified anymore . IP based connections/pings work fine. After a fresh reboot it works fine again for a while The duration might be the DHCP lease time of my router (12 hours), but I haven’t verified this.
On my router the PI with OSMC shows up with an active lease and all looks well.
When the problem occures, /etc/resolve.conf only has the line # Generated by Connection Manager, but no nameserver is configured. After a reboot, I see a nameserver again in this file.
I have no idea how long this has been going on on the old install. Connecting to it from outside works correctly and the NAS is reached by IP address, so I never had much reason to discover this problem till now.
Additionally on the new PI, from the beginning it claimed it can’t configure the wired network. It stays at the status “Configuring…”.
As mentioned, I didn’t pay much attention at first because the network connectivity looked all-right. I could log in and connect to my NAS without problem.
As an complicating factor, the Pi is running over nfs root. So it picks up some network parameters at boot time as well. (No idea if that can be related, so I mention it to be sure)
Oops, Missed the 2nd part of your reply:-(
What is the issue, and can I verify somehow that I am facing this as well?
The OSMC configuration manager doesn’t seem happy with setting up wired network.
Is there some log I can check for this?
If you use NFS, then ConnMan can’t handle the Wired Network. So you won’t be able to configure it via My OSMC. Instead you have to configure it via /boot/cmdline.txt. This is expected (but perhaps not very documented) behaviour.
I can’t suggest much for lookups, but check /proc/net/pnp. When you boot via NFS, the kernel is handling the network. It will expose the nameservers via /proc/net/pnp. This wasn’t being updated in the past, only at boot, but in an internal network I wouldn’t expect nameservers to ever really change, so it was a non-issue.
If you are on the latest update, you should read the comments here:
After reading throught the discussion connected to the git commit, I have to assume that connman doesn’t pick up on my nfsroot as well.
The connmand process is indeed following the commit. So i can cofirm I am on the latest version.
root 255 0.0 0.5 6496 4152 ? Ss Jan03 0:00 /usr/sbin/connmand -n --nodnsproxy
I checked if I could have the problem indicated by FST777 where he thought the root=/dev/nfs option should be specified before nfsroot. But that is already the case here:
cmdline.txt:
root=/dev/nfs nfsroot=192.168.71.2:/home/rpi/kodiliving ip=::::kodiliving::dhcp rootwait quiet osmcdev=rbp2
I checked /proc/net/pnp and it has all the right information:
root@kodiliving:/boot# cat /proc/net/pnp #PROTO: DHCP
domain oatfield.nl
nameserver 192.168.71.1
bootserver 192.168.71.1
However, resolv.conf is overwritten by connman:
root@kodiliving:/boot# cat /etc/resolv.conf
Generated by Connection Manager
I also checked the timing. It is not conclusive, but resolve.conf has been overwritten at least 15 minutes ago…
root@kodiliving:/boot# ls -al /etc/resolv.conf
-r–r--r-- 1 root root 34 Jan 4 19:15 /etc/resolv.conf
root@kodiliving:/boot# uptime
19:30:59 up 1 day, 13 min, 1 user, load average: 0.51, 0.30, 0.25
I don’t think I am using a “borderline case”. Also since no dns lookup is working, I should have noticed it earlier as at least my youtube and subtitle add-onns are also reliant on internet connections. So the december update seems to be the start of the problem
The number of OSMC users (outside of dev) using NFS is approx 1 in 120,000. This is based on cmdline posts to the pastebin. It’s very borderline. We want to improve it but need feedback.
Not from this post, but it seems that your resolv.conf is empty. Does adding a symlink to /proc/net/pnp work? Perhaps this is the best solution.
Also, can you confirm there are no other active network interfaces?
Resolve.conf is indeed empty, but only after a couple of hours. After reboot, it is filled correctly:
tail /etc/resolv.conf # Generated by Connection Manager nameserver 192.168.71.1
As far as I’m aware no other interfaces are active.
Attached is the content of connman.conf and ifconfig
more /etc/connman.conf [General] PreferredTechnologies=ethernet,wifi SingleConnectedTechnology=false AllowHostnameUpdates=false TetheringTechnologies=ethernet,wifi PersistentTetheringMode=true NetworkInterfaceBlacklist=vmnet,vboxnet,virbr,ifb,docker,veth
I have now added eth0 to the blacklist in connman.conf Lets see if it helps.
And I seem to be indeed a borderline case with 1 in 120.000! How much is that in absolute numbers? What I meant was that FST777 mentions he used even his own method of installing nfsroot, whil I used the OSMC installer to do this.
Still I am surprised by the low number. I’m a big fan of nfsroot. all my files are safely stored on the NAS, and backed up from there. Putting an extra file on the or movie is just a copy statement on my nas. And I used to have regular problems with corrupted SD cards on my Raspberry. that is all gone.
Ah and for experimenting, changing distribution is also just copying and moving directories on my NAS!
Great news. I was just making advertisement for OSMC to run Kodi over nfs and usb on the dutch kodi forum:-) So it is good to know that if they try it, they wont get aquanted with this problem.
For now the symlink to /proc/net/pnp seems to hold as a workaround.
