Model A crashes (web server/SSH access becomes unavailable)


14 posts
by jrmedd » Thu Feb 14, 2013 11:35 pm
Hi all,

I received my Model A earlier on this week, hoping to have it setup as a permanent web server. I’ve been using my Model B for quite some time now, running an Apache server, and it had been running without issue for over 30 days when the A arrived and I shut it down.

I wanted to liberate my B from this task, so bought an A, and gave it the same wifi adapter, SD card, and power adapter, hoping for a quick switch around.

The problem: after a short while (less than a hour max) it seems to stop working.

I first noticed the problem when I couldn’t access the web server, and then found that I couldn’t even SSH in (the only way I interface with the Pi). It seems the blue ‘connected’ LED on my wifi adapter remains lit - which used to go off during a 'proper' crash on my B - but the Pi remains completely inaccessible.

I don’t know where I can find any logs to help diagnose this problem, but do the symptoms speak for themselves? I was quite surprised to be honest, after having absolutely no problems with the Model B!

(As I was writing this post, I was trying to update Raspbian, just in case. My terminal window made it look as though I was hanging during the install, and my router no longer showed it as connected, but the lights were still blinking on the Pi.

Further to that, I had to guess when the update was finished – waiting ages for all of the LEDs to stop blinking, and then manually power off. Bad move: corrupted my SD card. Good thing I backed up first!)

Any help greatly appreciated, thanks!
Posts: 20
Joined: Mon Oct 29, 2012 3:48 pm
by tonyhughes » Fri Feb 15, 2013 12:04 am
/var/log/syslog
/var/log/apache2/apache.log

Check for funky stuff, but not likely to be Apaches fault, so syslog is the better bet.
User avatar
Posts: 950
Joined: Wed Dec 26, 2012 3:46 am
by jrmedd » Fri Feb 15, 2013 5:20 pm
Right, I've just tested booting the same SD in the A, then the B. They seem to follow exactly the same process up to a certain point.

At that point, the Model A gives these errors:
Code: Select all
Feb 15 16:57:56 testpi kernel: [  719.704663] phy0 -> rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x1208 with error -110.
Feb 15 16:58:46 testpi kernel: [  769.700337] phy0 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x1208 with error -110.
Feb 15 16:59:36 testpi kernel: [  819.696002] phy0 -> rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x1208 with error -110.
Feb 15 17:00:26 testpi kernel: [  869.691666] phy0 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x7010 with error -110.
Feb 15 17:01:16 testpi kernel: [  919.687338] phy0 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x7010 with error -110.

At exactly the same point on the Model B, everything is still accessible (hence I can still access via SSH) and I have these lines:
Code: Select all
Feb 15 17:03:15 testpi dbus[2006]: [system] Activating service name='org.freedesktop.ConsoleKit' (using servicehelper)
Feb 15 17:03:15 testpi dbus[2006]: [system] Activating service name='org.freedesktop.PolicyKit1' (using servicehelper)
Feb 15 17:03:15 testpi polkitd[2342]: started daemon version 0.105 using authority implementation `local' version `0.105'
Feb 15 17:03:15 testpi dbus[2006]: [system] Successfully activated service 'org.freedesktop.PolicyKit1'
Feb 15 17:03:15 testpi dbus[2006]: [system] Successfully activated service 'org.freedesktop.ConsoleKit'
Feb 15 17:12:14 testpi wpa_supplicant[1578]: wlan0: WPA: Group rekeying completed with 00:fe:f4:4a:b1:68 [GTK=TKIP]
Feb 15 17:17:01 testpi /USR/SBIN/CRON[2387]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Posts: 20
Joined: Mon Oct 29, 2012 3:48 pm
by M33P » Fri Feb 15, 2013 11:35 pm
Hi.

Issue the command iwconfig wlan0 power off and see if that fixes things. This disables the link state power management (i.e. radio power control).

There's a bug in certain Ralink chipset firmwares that makes them unresponsive after a time of the USB connection being idle. No idea why this affects the model A and not the B, but it's probably due to the way the driver issues SOFs if only one device is connected.
Posts: 199
Joined: Sun Sep 02, 2012 1:14 pm
by jrmedd » Sat Feb 16, 2013 10:30 am
Thanks for that, it seemed to last the night after that.

Two things:

1) Could you give a brief explanation of what that did exactly? It's the only way I'll learn!

2) A quick googling of the command revealed that I may need to do it every time I boot. What's the best way of doing that? Create a script in /etc/init.d?
Posts: 20
Joined: Mon Oct 29, 2012 3:48 pm
by M33P » Sat Feb 16, 2013 10:46 am
Most wifi chipsets are capable of programmability - they are not hardwired radios. The manufacturer releases firmware (usually bundled inside a windows driver) that does various things.

In the traditional OSI model (network layers - http://en.wikipedia.org/wiki/OSI_model) the firmware will typically help dealing with the bottom two. Wifi standards and link negotiations are rather convoluted and complex and will be tied rather closely to the hardware, so the best fit is to have a software-upgradable package on the chip itself.

In this instance the wifi firmware supports power management - it can be set to low-power sleep mode whereby it's not expected to be able to send packets immediately. For some reason if the device is left sleeping for a while it starts to fail to respond. I did measure the change for my dongle and it's not a massive difference - 30% of total power :lol:
Posts: 199
Joined: Sun Sep 02, 2012 1:14 pm
by jrmedd » Sat Feb 16, 2013 2:34 pm
Thanks for filling me in! Still seems odd that the B had no problem, could it be something to do with the A's lower power requirements?

Additionally, it seems that I do need to execute that command every time I reboot. I did some rooting around found something saying that if I saved this script as 'wireless' in /etc/pm/power.d, it would work at startup:
Code: Select all
#!/bin/sh

/sbin/iwconfig wlan0 power off

Problem is, it doesn't. A quick check of iwconfig shows that it still doesn't turn off automatically on boot. Any ideas for making sure it does?
Posts: 20
Joined: Mon Oct 29, 2012 3:48 pm
by obcd » Sat Feb 16, 2013 5:16 pm
Add a line to the /etc/network/interfaces file in the section of your wlanx adapter:
wireless-power off
To my knowledge, it does the same.
I had to add it to model B as well or my wifi disconnected.
Posts: 908
Joined: Sun Jul 29, 2012 9:06 pm
by jrmedd » Sat Feb 16, 2013 5:42 pm
Thanks obcd, that turns it off permanently.

Unfortunately, this approach still doesn't seem like a complete fix. After rebooting today, it still only lasted a few hours, and this time the previous error messages weren't in the syslog either.

Is this a widely acknowledge issue with the Pi? I was really pleased with the performance of my Model B, hence why I wanted to get an A in place as a permanent web server or for other 'running in the background' type projects. It hasn't proved reliable enough for any of these uses yet:
...to run projects from a battery or solar power: robots, sensor platforms in remote locations, Wi-Fi repeaters attached to the local bus stop and so forth.

(Quoted from the Model A release post: http://www.raspberrypi.org/archives/3215)
Posts: 20
Joined: Mon Oct 29, 2012 3:48 pm
by alibarber » Thu Mar 28, 2013 12:13 am
Hi guys, has anyone discovered any more information regarding this? I've just got my hands on a model A and wifi adapter from the pihut store (to move my clock - http://www.alastairbarber.com/index.php?post=harry-potter-weasley-clock) over to WiFi but so far I'm lucky if I get about half an hour continuous connection. I've tried the ideas mentioned in this thread but to not much avail and have 'apt-get upgrade'-ed and installed the latest 'firmware-ralink' packages but no luck. Currently I've put together a script that reboots the pi if the connection fails on more than 3 consecutive (1 minute spaced) intervals, but that's not ideal....

Anyway, I was just wondering if any software updates or hardware mods that you may have come across recently have solved this?

Cheers
Alastair
Posts: 1
Joined: Thu Mar 28, 2013 12:04 am
by hennep » Fri Nov 14, 2014 7:14 pm
I received my RPi A+ this week and was quite disappointed that this new model has the same problem as “the old A”.

I noticed that when I left an ssh session unused for several minutes the wlan0 interface became irresponsive. I started a console on a PC and started to ping the RPi. Within one minute I could start another ssh session, wlan0 was available again.

Also pinging the “outside world” from the Pi works.

Is there a way to automatically start a ping session at boot? I’m not that familiar with the Linux system.
We could ping raspberrypi.org until they have sorted the problem 
Posts: 3
Joined: Fri Nov 14, 2014 7:02 pm
by pluggy » Fri Nov 14, 2014 8:09 pm
I've been having problems with the A/A+ and wifi adaptors misbehaving :

viewtopic.php?f=63&t=91542

In my case the pi isn't crashing, its just not responding through the wifi adaptor. I find I can unplug the adaptor, substitute a keyboard and connect a monitor and gain control again. I can then do a clean shutdown.
Don't judge Linux by the Pi.......
I must not tread on too many sacred cows......
User avatar
Posts: 3636
Joined: Thu May 31, 2012 3:52 pm
Location: Barnoldswick, Lancashire,UK
by hennep » Fri Nov 14, 2014 8:42 pm
In my case only the ssh session crashes and I cannot start another ssh session.
When I start to ping the pi, wlan becomes responsive again after approx. 30 seconds.
Posts: 3
Joined: Fri Nov 14, 2014 7:02 pm
by hennep » Mon Dec 01, 2014 4:28 pm
This post (from MrEngman) solved my problem: viewtopic.php?f=28&t=61665
Posts: 3
Joined: Fri Nov 14, 2014 7:02 pm