I have OSMC running on a Pi 3B. I have been using an older USB WiFi dongle, but just remembered that the Pi 3B has an onboard WiFi chip. OSMC apparently is not seeing it? What is the issue?
I installed OSMC last year. I do not recall trying to disable the onboard WiFi, but assuming I did, how can I find out and correct this?
Thanks…RDK
This would be indicated by an entry in /boot/config.txt
You also can upload logs via grab-logs -A and post the URL here for us to help.
Or to exclude a configuration or software issue the easiest is install raspbian on a second SD card and see if WiFi works
OK. Thanks. I already looked in the /boot/config.txt and there was no “dtoverlay=disable-wifi” entry.
Here is a link to my log file: https://paste.osmc.tv/sicuyuhepi
I booted up this Pi 3B from a NOBS installer SD and it found the onboard WiFi chip and got a DHCP address from WiFi router, so the hardware is good.
Looking forward to some more ideas. Thanks again….RDK
Remove dtoverlay=sdhost from config.txt. This disables WiFi.
OK, thanks. I can’t get to it until tomorrow, but I’ll give it a try.
So, what is that line doing in the /boot/config.txt? Will there be any side effects from removing it?..RDK
There won’t be any side effects. You probably have this from a long time ago when the sdhost driver was still in testing.
Thanks, it worked, but I put the “dtoverlay=sdhost” commend back when I discovered that the on-board WiFi could not get and hold an address. The WiFi USB dongle is not perfect, but seems to make better connection.
This OSMC setup rests across two networks: Network A is via an ethernet cable and Network B is using WiFi. When I boot up it always connects via the ethernet, but the WiFi is spotty and usually requires that I manually connect. It this normal? Can I do anything to correct this and have both consistently come you automatically. Thanks…RDK
It sounds like a low signal issue.
You might need to change the PreferredTechnologies setting in /etc/connman.conf to prefer wifi over ethernet.
Make a strong cup of coffee and have a look at the Preferred Technologies section in Open Ecosystem
Thanks. The problem with reading the documentation, regardless of the application, is that it often generates more questions than answers. In this case “Tethering”. I’m not sure I want tethering? My two connections are on different networks, ie different Internet connections, different addresses, etc.
They are set up that way to allow content to be transferred to the Pi and to provide a source for streaming content, independently to each network.
I have never modified /etc/connman.conf , although I’m sure that some things were added when I initially installed OSMC? Here is that file:
[General]
PreferredTechnologies=ethernet,wifi
SingleConnectedTechnology=false
AllowHostnameUpdates=false
TetheringTechnologies=ethernet,wifi
PersistentTetheringMode=true
NetworkInterfaceBlacklist=vmnet,vboxnet,virbr,ifb,docker,veth
Tried this connmanctl services but the OS threw an error:
~$ connmanctl services
Error: Rejected send message, 3 matched rules; type=“method_call”, sender=“:1.31” (uid=1001 pid=6053 comm=“connmanctl services “) interface=“net.connman.Manager” member=“GetServices” error name=”(unset)” requested_reply=“0” destination=“net.connman” (uid=0 pid=345 comm=“/usr/sbin/connmand -n --nodnsproxy --config=/etc/c”)
And finally, is there a way, from the command line, to preconfigure WiFi network info (ie password, etc)?
I’m sure I will now have more questions. Thanks…RDK
/etc/connman.conf is showing a preference for ethernet over wifi. You need to reverse that preference.dillthedog…Thanks. I give this information a try and see what other questions they generate 
…RDK
OK, here is the /etc/connman.conf:
[General]
PreferredTechnologies=ethernet,wifi
SingleConnectedTechnology=false
AllowHostnameUpdates=false
TetheringTechnologies=ethernet,wifi
PersistentTetheringMode=true
NetworkInterfaceBlacklist=vmnet,vboxnet,virbr,ifb,docker,veth
I assume I should change it like this? Please confirm I don’t want to create a brick with incorrect commands:
[General]
PreferredTechnologies=wifi,ethernet
SingleConnectedTechnology=false
AllowHostnameUpdates=false
#TetheringTechnologies=ethernet,wifi
PersistentTetheringMode=false
NetworkInterfaceBlacklist=vmnet,vboxnet,virbr,ifb,docker,veth
Should I add anything else?
I ran the “connmanctl services” using the OSMC id and it worked.
Thanks…RDK
Only change the above line.
Hmmm, In your previous reply you said that I do NOT want Tethering? Shouldn’t I be making those Tethering changes also?..RDK
Please follow my instructions. Tethering is controlled via connmanctl.
OK, I have done it but don’t see any differences?..RDK
Please reboot the Pi and provide logs again.
Ok. Here are the logs. Actually I’m not clear what difference changing that line was supposed to make? It seems to find the WiFi most of the time now, but it was like that before …RDK
The difference should be one of predictability: that the WiFi interface will always start and get an IP address. If it’s still only finding WiFi “most of the time”, then I assume you’re saying that it’s failing some of the time. That said, the log shows a successful sequence of events:
Oct 31 07:52:41 RDKMediaServer avahi-daemon[305]: Registering new address record for 10.0.1.95 on eth0.IPv4.
Oct 31 07:52:42 RDKMediaServer avahi-daemon[305]: Registering new address record for 192.168.62.122 on wlan0.IPv4.
Oct 31 07:52:42 RDKMediaServer connmand[331]: wlan0 {add} route 212.227.81.55 gw 192.168.62.1 scope 0 <UNIVERSE>
Oct 31 07:52:43 RDKMediaServer avahi-daemon[305]: Withdrawing address record for 10.0.1.95 on eth0.
Oct 31 07:52:43 RDKMediaServer avahi-daemon[305]: Registering new address record for 10.0.1.95 on eth0.IPv4.
Oct 31 07:52:45 RDKMediaServer connmand[331]: wlan0 {del} route 212.227.81.55 gw 192.168.62.1 scope 0 <UNIVERSE>
While I’m not sure of the reason for step 4, this is broadly in line with the description in the link I provided above:
once a new services become available, the technology type of the already connected service is compared with the technology type of the new service, if the new service has a type listed earlier than the one of the connected service, the new service will be autoconnected