I'm seeing the same thing with my chumby one; it stopped responding to network requests. The existing open ssh connection kept running, but attempts to access the chumby from a different computer failed. Couldn't ssh, http or even ping the chumby. However if, from the chumby (using the existing open ssh connection), I ping'd the remote machine then access worked fine both ways.
This looks like the chumby one might have stopped responding to ARP requests. Which seems odd...
FWIW, I'm using a WRT54G with Tomato firmware as my router/AP, which is a broadcom based device. The wireless LAN is bridged to the ethernet LAN. This is an extremely common router and a biggie in the Linux hacking community; I'd be surprised if the router wasn't forwarding ARPs properly.
Hmm, when things are working good the ARP is definitely being forwarded; we can test...
$ sudo arp -d chumby1
$ arp -a | grep chumby1
chumby1.spuddy.org (10.0.0.147) at <incomplete> on br0
$ ping chumby1
PING chumby1.spuddy.org (10.0.0.147) 56(84) bytes of data.
64 bytes from chumby1.spuddy.org (10.0.0.147): icmp_seq=1 ttl=64 time=26.1 ms
64 bytes from chumby1.spuddy.org (10.0.0.147): icmp_seq=2 ttl=64 time=1.94 ms
--- chumby1.spuddy.org ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.946/14.042/26.139/12.097 ms
$ arp -a | grep chumby1
chumby1.spuddy.org (10.0.0.147) at D8:xxxxxxxx [ether] on br0
Is there a tcpdump built for the chumby one? If so we could test from that side during the "outage" period to determine if it sees the incoming arp request.
Hmm, I wonder if my earlier post about ip6 (missing default gateway) is related. After rebooting the c1 I noticed it _had_ picked up a default ip6 gateway... so could it be possible that the c1 is ignoring all _broadcast_ traffic, which would cause it to ignore the router advertisements as well, and so eventually drop the default ip6 route?