I have the same problem. Here's what is the same as, and different from, other customers.
Same:
A long-running SSH session will eventually become unresponsive. Sometimes the session will come back after a delay, sometimes the session will time out.
While the SSH session is unresponsive, I can't ping the Chumby One or make any incoming connections to it, unless...
If I add an entry in my PC's ARP table (via 'arp -s ...'), I can ping the Chumby One. Almost always, adding the entry and pinging it will wake up and restore my unresponsive SSH session.
There is nothing new in 'dmesg' when my session comes back.
At all times, Chumby widgets can access the web.
According to my Wireshark captures, the Chumby One sometimes stops responding to ARP requests. To me this is clearly the problem.
Different:
The Chumby One won't resume responding to ARP requests at exactly 30 minutes after the hour. (Something happened at 30 minutes past, but it didn't fix my problem.) My Chumby One just came back at 53 minutes past, for example.
The Chumby One will become unresponsive in night mode.
I've connected my Chumby One to two different access points with the same results: a LinkSys WRT54G and an Apple Time Capsule.
I tried to dig deeper. I connected to the Chumby One's serial port, and I built tcpdump and ran it from the console. Once the Chumby One's SSH session becomes unresponsive, ARP requests stop showing up in tcpdump. Other traffic continues. The Chumby makes successful outgoing HTTP and NTP connections. It also makes ARP requests to my access point and receives responses.
I built a version of compat-wireless with these variables set in config.mk:
CONFIG_RT2X00_LIB_DEBUGFS=y
CONFIG_RT2X00_DEBUG=y
My plan was to load my debug copy of the drivers and try to capture something useful when the Chumby One stopped responding to ARP requests. I replaced all five .ko files in
/lib/modules/2.6.28-chumby/updates/drivers/net/wireless/rt2x00/
plus
/lib/modules/2.6.28-chumby/updates/drivers/net/wireless/mac80211_hwsim.ko
/lib/modules/2.6.28-chumby/updates/net/wireless/cfg80211.ko
with my debug copies and rebooted. But something unexpected happened: So far, everything has worked with these drivers, and I can't reproduce the problem with them. No more SSH sessions choking.
So now I'm stuck, and I need help please. First, I built the debug drivers with compat-wireless-20090728, which is the latest version available here at http://files.chumby.com/source/, and they only work with 1.0.3. I had to downgrade to load them. Any driver I build (including the latest code from http://wireless.kernel.org/download/com … eless-2.6/) won't load on 1.0.4. This is the error during boot:
[ 15.160000] cfg80211: disagrees about version of symbol skb_put
[ 15.170000] cfg80211: Unknown symbol skb_put
[ 15.180000] cfg80211: disagrees about version of symbol genl_register_ops
[ 15.190000] cfg80211: Unknown symbol genl_register_ops
[ 15.200000] cfg80211: disagrees about version of symbol pskb_expand_head
[ 15.200000] cfg80211: Unknown symbol pskb_expand_head
[ 15.210000] cfg80211: disagrees about version of symbol kfree_skb
[ 15.220000] cfg80211: Unknown symbol kfree_skb
[ 15.230000] cfg80211: disagrees about version of symbol netlink_broadcast
[ 15.230000] cfg80211: Unknown symbol netlink_broadcast
[ 15.240000] cfg80211: disagrees about version of symbol __alloc_skb
[ 15.250000] cfg80211: Unknown symbol __alloc_skb
[ 15.260000] cfg80211: disagrees about version of symbol __dev_get_by_index
[ 15.270000] cfg80211: Unknown symbol __dev_get_by_index
[ 15.270000] cfg80211: disagrees about version of symbol skb_pull
[ 15.280000] cfg80211: Unknown symbol skb_pull
[ 15.320000] cfg80211: disagrees about version of symbol dev_close
[ 15.320000] cfg80211: Unknown symbol dev_close
[ 15.330000] cfg80211: disagrees about version of symbol skb_push
[ 15.330000] cfg80211: Unknown symbol skb_push
and on and on. I'll look into it further if I have to, but posting updated Chumby sources for 1.0.4 would be an easy way to help. Second, I could use more advice on what to run from the Chumby One's console serial port when I experience the problem. There's nothing in dmesg, and there are no ARP packets in tcpdump, but it seems like there is potential to probe further. I'm motivated to solve this problem, and given that its easy for me to reproduce it, I'll run whatever you want from the serial console to gather more info.