Does wifi have sleep mode?

I reinstalled osmc 2 days ago and noticed something today. When the pi is on dim mode (sometimes) i can’t access it from my PC. Neither vnc,ssh,or kodi web interface works…but if I press a button on the remote and wake it everything works again.
So is there a sleep function for the wifi? Btw it doesn’t show on my router’s dhcp page as well.

This is highly dependent on your chipset

With that said, by ‘sleep mode’ I understand power management which doesn’t inhibit connectivity but performance.


yeah, i understand that, i mean the linux distro of osmc…has it been tweaked or has an option to do that ? (deactivate wifi to save power when the device is idle).
Does it have a keep alive option ? some way that checks every X minutes if there is no wifi to try and reconnect ?

Nope. Some logs may help here.

my local static ip is if it helps

same thing happened today, twice…
I’ll try this for now (the wicd-curses solution) and report back tomorrow:

Try adding this to /etc/rc.local before exit 0

iwconfig wlan0 power off

If this helps, then the situation is caused by RT2800 power saving. I can fix it if that is the case.


Thanks, will try it now…its easy to reproduce the problem, so i’ll post back the result

So far so good, not a single hiccup. Before i could see that its losing connection cause my putty would get disconnected.
I think that fixes the power save mode on the chip.
Isnt it safer to add a small sleep above that, to make sure the pi is connected to the wifi router?

The power management is independent of connection status. I will fix it properly, in the kernel shortly.


1 Like

unfortunately it did it again today :confused: I turned the tv on and went to the pi screen and saw that it wasnt connected to the router anymore…actually it couldnt find any networks to connect to. And nothing useful in the logs either:

Whats the equivalent of ifdown in osmc ? I wanna try something like this:


# Which Interface do you want to check
# Which address do you want to ping to see if you can connect

# Perform the network check and reset if necessary
/bin/ping -c 2 -I $wlan $pingip > /dev/null 2> /dev/null
if [ $? -ge 1 ] ; then
    echo "Network is DOWN.  Perform a reset."
    /sbin/ifdown $wlan
    sleep 5
    /sbin/ifup --force $wlan
    echo "Network is UP. Just exit the program."   

Yes, because rc.local will typically actually run before connman even loads, let alone before wlan0 exists. So it’s very likely that without a 10 second sleep the effect of that command is placebo…

1 Like

In June update, i was getting lots of crashes…with august update i got no wifi…
I can see the usb stick powering off…no lights are flashing, but when i press any button on the remote and move around a bit…it turns back to life after 3-4 seconds…
Latest logs: still no obvious reason for this

This very much sounds like a power supply issue to me


An issue that occurs with osmc only ? Is that possible ? xbian and openelec didnt do that…neither did the june version.
I did a fresh install now with the August update and this happens.

We clock higher than XBian and OE, so it’s definitely possible. There aren’t many other reports to suggest a widespread problem. I’d definitely try and rule out the power supply as the issue, as all of your issues (with exception of the distorted splash screen) sound like symptoms of an underspecced PSU


I bought my pi with a 5v2A power supply in Feb…just checked it with the multimeter and the volts are fine. I only got the wifi stick and the wifi keyboard on it…I highly doubt it that 2A isnt enough for only these 2.
This has to be a software issue…it didnt exist in June’s update :confused:

Are you on a Pi 2?

Where did you measure the voltage at?


Did you measure the voltage while the Pi was running and under full load ? (EG high CPU usage and/or high network usage ?)

If you only measured the voltage with the Pi not connected the measurement is meaningless.

A Pi 2 has no TP1/TP2 so you would have to measure the 5v rail on the GPIO header.

BTW in a previous kernel update we changed a kernel setting which causes the CPU to go into turbo mode on disk access - this means the CPU will be in turbo mode much more often than before, if there is a power issue it is much more likely to occur when the system is in turbo mode a much higher percentage of time.

This was added here:


echo 0 | sudo tee /sys/devices/system/cpu*/cpufreq/ondemand/io_is_busy

to /etc/rc.local. If things improve, then it is a power issue