The New 4-core Raspberry Pi

[johnbanks]

Tinitus ...

I don't think it's the RealTek 8192CU chip.
I have had the problem I described with various wireless adaptors ... with Atheros AR9271 and Reattek RT5370 chips.

If you are using an EdiMax with the 8192CU chip and have not taken special measures then it could be going into power saving mode and dropping the connection.

I do the following which I found on the RPi forum ... to stop the Edimax losing connection after periods of non-use/overnight.
(by MrEngman » Sun Nov 24, 2013 5:47 pm)

Make a file 8192cu.conf in directory /etc/modprobe.d/ with the command ...

sudo nano /etc/modprobe.d/8192cu.conf

and add the following lines ...

# Disable power management
options 8192cu rtw_power_mgnt=0 rtw_enusbss=0

I also do the same for 8188eu ... just in case I use that type of wi-fi adaptor

Hope this helps

[johnbanks]

Frank ...
Many thanks for your quick response.

I was surprised that my wlan0 had two IP addresses.
If I recall correctly the .30 address was assigned by dhcp when I was first setting up my rig and had a LAN cable connected.
The LAN cable is now disconnected but perhaps my router has remembered and assigned the .30 address by dhcp along with the .160 address that I have statically assigned to wlan0.

Two IP addresses for wlan0 must be a common problem? – given that the rig setup procedure for wireless requires first connecting by wire.

Or perhaps I inadvertently connected wirelessly via dhcp before establishing my static .160 address.

Of course, it would not have been a problem if I’d chosen the .30 dhcp assigned address also as my static address.

I have followed your suggestion to disable dhcpcd & rebooted. Doing ip addr now shows just my static .160 address for wlan0.
I will note what happens over the next few days and ‘report back’.

Given that my disconnection problem is not unique – is there any way that I can help by providing other log files? – or are these lost when I’m forced to do a pull the power cord reboot?
Under MPD Configuration my log level is set to disabled.

I would be prepared to set up any special logging that you may suggest - so please let me know.

Thanks again

[hondagx35]

[johnbanks]

Frank ...

Here’s an update ...

Late last evening I did as you suggested and disabled dhcpcd then rebooted and ip addr then only showed 1 IP address for wlan0.
I kept my rig on overnight and it was still connected this morning and so I connected to a web radio.

Later in the morning I noticed the radio stream was no longer playing. However it was possible (without reboot) to browse to the UI Playback and just restart the radio stream. This is new – in the past, it would have been necessary to reboot.

Mid this evening the radio stream paused momentarily and then continued. However, it was not possible browse to the UI nor puTTY in and the wireless adaptor light was off (not flashing as is normal).

I let the radio stream continue for more than an hour then rebooted.

My mods to runeaudio include regular cron pings to my router and an email alert to me if the ping fails. This did not happen.
I wondered whether it could be possible that my wireless adaptor is going into some kind of power saving mode that allows pings to my router and an established stream to continue but will not allow browsing to the UI or a puTTy connection?

This may sound fanciful but my wireless adapter chip (8192CU) does seem to need special measures to avoid power saving mode and I have implemented the web advised solution to turn off power management.

So is it a 8192CU problem or a RuneAudio/Arch Linux problem?

I’ve just powered off and fitted a different wireless adapter with an Atheros AR9271 chip and will leave my rig running.

I will let you know what happens.

Regards

[Tinitus]

Hi John,

I am very interested in the outcome of your experiment.

Best Regards

Uwe

[johnbanks]

Frank ...

Here’s my latest update ...

My RPi2 rig with a wireless adapter with Atheros AR9271 chip remained connected for 44 hours.
That gives the thumbs up to the Atheros AR9271 as far as I’m concerned but at that point a problem occurred ...

I tried to start web radio and the UI was unresponsive ...
There was an error message across the bottom of the UI ...
Warning: session_write_close(): Failed to write session data (redis). Please verify ~~~~etc

I made a Debug report herewith ...

Debug 18 June 2015 RPi2 AR9271 wireless chip.zip

(20.03 KiB) Downloaded 417 times

When it eventually restarted, the radio stream was very choppy.
My conclusion was – the AR9271 chip is OK but RuneAudio/Arch Linux has a problem?

So I decided to switch my testing to a wireless adapter with a Ralink RT5370 chip (very low cost item).
I was happily streaming from my NAS when after 2 hours approx, it suddenly halted.
Going to the UI showed the following message across the bottom of the screen ...

Warning: socket_write() expects parameter 1 to be resource, boolean given in /srv/http/app/libs/runeaudio.php on line 99 Warning: socket_last_error() expects parameter 1 to be resource, boolean given in /srv/http/app/libs/runeaudio.php on line 88 Warning: socket_close() expects parameter 1 to be resource, boolean given in /srv/http/app/libs/runeaudio.php on line 89

So I made another Debug report herewith ...

Debug 18 June 2015 RPi2 RT5370.zip

(19.93 KiB) Downloaded 418 times

I will continue my RT5370 test and report back in due course ...

Regards

PS – there have been many DEV gitpull updates in the past couple of days – anything relevant there? I assume that disabling dhcp was included in those updates?

[hondagx35]

[johnbanks]

Frank ...

Belated thx for yr sharp eyes & response.
I have no idea how that third rogue netctl profile got there and I've deleted it.

You did not specifically refer to the error messages I posted that I got on my UI - could these be a result of that rogue netctl profile?

In the last couple of days I've built a second RPi2 rig (will be my portable rig). Naturally I started with the 14 April 2015 image. But I had the same problems as previously with the gitpull and had to disable dhcpcd. I guess these changes have not yet made it into your gitpull updates?

Thinking about new users and the fact that 0.3 beta is getting pretty long in the tooth - would it be a good idea if the website carried a note that after using the 14 April image a gitpull update is almost mandatory? I'll pass that thought onto you who'll have much more influence than me.

I will continue with my tests. Being pragmatic - 48 hours continuous running without dropping the wireless signal in my rather poor wireless location, I will count as success. And will post my results/conclusions on the forum in due course.

Thx for yr support & guidance

[anfuca]

Warning: session_write_close(): Failed to write session data (redis). Please verify that the current setting of session.save_path is correct (tcp://localhost:6379?weight=1) in /srv/http/index.php on line 144

That message appears after 12 hours working. It appears on USB storage windows, and after reboot, it appears also on the main screen under the cover...

[treefiddy]