RPi 2 Wireless Disconnects/RuneAudio Crashes

johnbanks

I’m running an RPi 2 with iQaudio DAC and Amp streaming wirelessly from my NAS and it sounds great.
However I have an annoying problem. My setup should run 24/7 but 2 out of 3 mornings I discover that RuneAudio is ‘dead’ - most times the WiFi dongle LED is out but occasionally it’s permanently on (not flashing). The solution is to pull and then re-plug the power and so reboot.

I’ve tried several WiFi dongles with different chips Realtek 8188 & 8192 and Ralink RT5370 and get the same problem. The Realtek chips are well known for their power management problems but I’ve taken the special measures recommended by MrEngman – a guy on various forums who seems to be the expert.

I do not have a LAN cable connected and my wireless signal is good – iwconfig shows ... Link Quality=100/100 Signal level=95/100 Noise level=0/100.
wlan0 has the static IP address 192.168.0.160
My wireless network is password secured.
I am up to date with the nightly build.

However when I scan my home network (by running netscan on a Windows machine) I see 2 instances of runeaudio – at 192.168.0.160 as expected and another at 192.168.0.82 which is a mystery and they both have the same MAC address.

It would be good to set up a log file that persisted after a reboot to try and pinpoint the problem causing the overnight crash.
Can anyone help?
Thanks

hondagx35

Hi johnbanks,

as i told you here please disable dhcpcd first.
Get access to the console and enter:

systemctl disable dhcpcd

After a reboot your second IP should be disappear.

It would be good to set up a log file that persisted after a reboot to try and pinpoint the problem causing the overnight crash.

Yes would be great if you could help to find the reason for this issue.

First i would try to enable "journald" and make the log persistent.

systemctl unmask systemd-journald

Edit /etc/systemd/journald.conf

....
[Journal]
Storage=persistent
.....

The log should be written in /var/log/journal.
This folder is mounted as tmpfs and for that is in memory.
To change this you have to comment the line in /etc/fstab

# 
# /etc/fstab: static file system information
#
# <file system>	<dir>	<type>	<options>	<dump>	<pass>
/dev/mmcblk0p1  /boot   vfat    defaults        0       0
#logs /var/log tmpfs nodev,nosuid,noatime,mode=1777,size=5M 0 0
rune-logs /var/log/runeaudio tmpfs nodev,nosuid,noatime,mode=1777,size=5M 0 0

You can read the journal with

journalctl

Revert these changes as soon as possible, because it will fill and wear out your sd card if used for long times.

Frank

dror

Try this for 8188cus

create a new configuration file by opening:
sudo nano /etc/modprobe.d/8192cu.conf

then add the lines:
# Disable power saving
options 8192cu rtw_power_mgnt=0 rtw_enusbss=1 rtw_ips_mode=1

notice, both last parameters are '1'

Dror

hondagx35

Hi Dror,

thank you for your reply.
Is this working reliable for you?

If so, we can implement this in future images.

Frank

johnbanks

Frank ...

As usual, thanks for your very quick and clear reply.

Several months ago I did disable dhcpcd as you suggested but recently re-installed and updated with the nightly build. I assumed this had since been incorporated in the nightly – bad assumption on my part, sorry. Disabling dhcpcd has fixed the problem of 2 IP addresses.

Your instructions for setting up a journal were clear and worked. It was necessary to reboot to bring them into effect.

Rebooting a couple of times showed the journal was persistent.

I’ve discovered that PageUp and PageDn speed up scrolling and the Left & Right arrows enable horizontal scrolling. Pressing q exits the listing.
A power on cycle generates almost 800 journal entries. The first 600 approx are dated 1st Jan 1970 and the balance have the actual date & time.
Doing journalctl --disk-usage reports the size of the journal files.

I deleted the journal to give a clean start and at 13:00 GMT started a test run. No music is streaming & no puTTy session is open. When I notice the wifi dongle LED is no longer flashing, I’ll pull & replug the power and take a look at the journal.

Can you please advise how to save the journal as a text file?
Thanks

dror

hondagx35 wroteHi Dror,

thank you for your reply.
Is this working reliable for you?

If so, we can implement this in future images.

Frank

working and reliable. My access point configuration is UP for at least two weeks, and it ain't going to stop

johnbanks

Frank and Dror ...

From the many references I’ve seen on forums, wifi dongles with Realtek chips (eg: Edimax) are problematic and require special measures. MrEngman a prolific forum contributor often gives detailed advice on this subject.
You may find the following thread informative ...

https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=129021

What is a little mystifying though is that Dror’s recommendation differs from MrEngman's regarding the parameters in the file: /etc/modprobe.d/8192cu.conf

The proof of the pudding seems to be here – I copy & paste ...

you should use the two commands
cat /sys/module/8192cu/parameters/rtw_power_mgnt
cat /sys/module/8192cu/parameters/rtw_enusbss
instead to check the power management commands are active. Both should return a value of 0 (zero). If they do not then you need to reboot the Pi and then check again.

Notwithstanding the above relating to Realtek chips, the problem I’ve described in this thread occurs whether I use a Realtek or a Ralink chipped dongle and I have tried 4 different dongles. So it is possibly related to wireless in general and not Realtek dongles in particular.

It is worth following the link within the above which relates to ifplugd. Maybe the body is buried there.

I am of course making the assumption that Debian problems/solutions may be relevent to ArchLinux.

In the meanwhile my test with a persistent journal is continuing.

Hope all this helps

dror

johnbanks wrote What is a little mystifying though is that Dror’s recommendation differs from MrEngman's regarding the parameters in the file: /etc/modprobe.d/8192cu.conf

indeed, that is why I mentioned it. Just that was the only way to make that chip work. And you can find references for that if you will look for.

johnbanks wrote Notwithstanding the above relating to Realtek chips, the problem I’ve described in this thread occurs whether I use a Realtek or a Ralink chipped dongle and I have tried 4 different dongles. So it is possibly related to wireless in general and not Realtek dongles in particular.

That's a point. Forgot you have used that Ralink one too.
But why don't you try with 8188CUS and see if that helps you?

johnbanks

Dror ...
Thanks for your suggestion

As a matter of interest what results are returned when you give the following commands?

cat /sys/module/8192cu/parameters/rtw_power_mgnt

cat /sys/module/8192cu/parameters/rtw_enusbss

In the meanwhile my unit ran overnight but just a few minutes ago failed with the dongle LED solid on. I can neither puTTY nor browse to it by wireless.

dror

'0 ' for rtw_power_mgnt
'1' for rtw_enusbss

silvrr

hondagx35 wroteHi Dror,

thank you for your reply.
Is this working reliable for you?

If so, we can implement this in future images.

Frank

Please do. This has saved me a bunch of headaches. I wrote it into my guide on head-fi and have seen a number of people say it fixed the wireless sleep issue.

Not hard to implement on the user end but would be nice if it was already included.

johnbanks

Frank ...

A few posts back you suggested that I run journald in an attempt to find out why my RPi2 was periodically losing wireless and RuneAudio was crashing.

It’s been a learning experience and I found these links very helpful ...

https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-view-and-manipulate-systemd-logs

https://www.loggly.com/ultimate-guide/linux-logging-with-systemd/

Starting on 14th March, my RuneAudio ran with journal logging for more than 2 days and had 5 failures. The zip file contains a summary of the failure modes and the log files for the 5 sessions.

Failure Logs.zip: (72.04 KiB) Downloaded 522 times

With my inexperienced eye I cannot detect any single problem cause. I was just amazed at the many and different warnings & notices. I’ve concluded that my OS is corrupt (I boot from the micro SDHC but run from a USB 3.0 stick).

I can see that you are busy helping the RPi3 guys but if you have time to take a quick look at the log files, I’d welcome any comments.

(I saved the log files in /etc and used netscan to copy them to my Windows PC and then used Notepad++ to read them)

Many thanks

hondagx35

Hi johnbanks,

With my inexperienced eye I cannot detect any single problem cause.

I also could not find any hint regarding your problems.
Will do a deeper search tomorrow.
Many thanks for your help in debugging this issue.

I can see that you are busy helping the RPi3 guys

Yes i have finished a new image for the RP3.
This image is also usable with your RP2, so please test this one.

Frank

johnbanks

Frank ...
Where do I get this latest Rpi2/3 image?
Thanks

hondagx35

Hi johnbanks,

it is available here.

Frank

johnbanks

Frank ...
I'd like to add my thanks (to the many others) for your efforts and great responsiveness.
I'm running the rpi2/3 0.4 beta image on an RPi2 rig.
It has run for more than 3 days without wireless disconnecting or RuneAudio crashing.
I'm now convinced that my previous problems were caused by a corrupt file system.

When will this new version be included in the 'official' DOWNLOADS section on the website rather than your personal OneDrive? The website is where people would normally go, surely?

Thanks again

hondagx35

Hi johnbanks, hi all,

When will this new version be included in the 'official' DOWNLOADS section on the website rather than your personal OneDrive?

It's already downloadable from source forge (with actual 237 downloads).
It will be announced soon on the download page.

Frank