You are not logged in. Please login or register.
chumbysphere forum → Software → SSH Login not possible after several minute
Blue BuddyI have also had this problem running the command
netsh interface ipv4 add neighbors "Local Area connection" "192.168.0.10" "chumbymacaddress"
on my windows7 workstation allowed it me to connect to the chumby again.
Has anyone found a permanent fix ?
I'm having the same problem with my chumbies, hw 10.6, sw 1.0.7, fw 1.0.3454
they quit answering arps. fortunately, my big server seems to keep cache longer, so I can get into them from that, and then if I ping one of the other linux boxes they're refusing to talk to, everything is fine...
alternatively, putting their macs in /etc/ethers works...
but it's a pain of a workaround *Grin*
no hint of any fixes yet?
This is AP-related.
I used to have this same problem, but I recently switched to a different (for an unrelated issue) and found that the issue immediately disappeared.
This is AP-related.
I used to have this same problem, but I recently switched to a different (for an unrelated issue) and found that the issue immediately disappeared.
while I haven't tried running the chumby on a wired ethernet connection, I don't really see how the chumby stopping answering arps would be AP related. the chumby's still talking, if you know it's mac address, ie, if I try to talk to it via a machine that has the chumby's mac address in it's arp table, there's no problem pinging, or sshing into the chumby, if, however, I try to talk to the chumby from a machine that doesn't have the chumby's mac address in it's arp table, then it can't talk to the chumby, and the chumby ignores the arp requests. if I then add the mac address to the arp table manually, I can then talk to the chumby.
this situation prevails on three different chumbies, and a 8" infocast, on two different APs, one G ap from netgear, one n ap from dlink.
what kind of AP do you believe solved your problem?
This is AP-related.
I used to have this same problem, but I recently switched to a different (for an unrelated issue) and found that the issue immediately disappeared.
Yes, I've just changed from my Netgear AP to a TP-Link device, and the problem has completely gone away. It must be some incompatibility between Netgear and RA-Link, but it's unclear to me which of these 2 outfits has the problem.
latestrevision wrote:This is AP-related.
I used to have this same problem, but I recently switched to a different (for an unrelated issue) and found that the issue immediately disappeared.
Yes, I've just changed from my Netgear AP to a TP-Link device, and the problem has completely gone away. It must be some incompatibility between Netgear and RA-Link, but it's unclear to me which of these 2 outfits has the problem.
well, let us know if it quits working.
while I never say never when it comes to networking, having a bug in the networking stack that makes it stop responding to arps seems a bit farfetched to be caused by the AP it talks to....
bobgm wrote:latestrevision wrote:This is AP-related.
I used to have this same problem, but I recently switched to a different (for an unrelated issue) and found that the issue immediately disappeared.
Yes, I've just changed from my Netgear AP to a TP-Link device, and the problem has completely gone away. It must be some incompatibility between Netgear and RA-Link, but it's unclear to me which of these 2 outfits has the problem.
well, let us know if it quits working.
while I never say never when it comes to networking, having a bug in the networking stack that makes it stop responding to arps seems a bit farfetched to be caused by the AP it talks to....
Well, it's been a week now, and it's still working perfectly. Not a single instance of a missed arp, either from the chumby or my media pc. It does seem strange - there are some options that occur to me, and probably more that don't:
* The AP doesn't correctly pass on ARP broadcast packets (but why only RALINK stacks fail?)
*There's a bug in the RALINK stack/Netgear stack combo that means the arp packets are dropped.
* The chumby/media pc are actually replying with arp replies, but the AP for some reason is dropping these. Perhaps the RALINK stack is slightly malforming them, or is within spec and the Netgear stack can't handle them for some reason.
There is still the interesting issue of the fact that both systems appear to fail and recover at the same instant, which rather does suggest the AP as the common point of failure, unless the networking stacks in the RALINK drivers have some system-clock related bug which sounds bizarre to me. I suppose I could substitute the old AP back again, and desync the clock on one of the systems to see what result this produces. But I have other fish to fry.
Blue BuddyI'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?
Blue BuddyNow that's odd. I currently have the chumby1 permanently configured to display "red clock" (the widget is set to never switch). Out of the corner of my eye I saw the display flash. For around 30 seconds the screen was displaying the default clock, and then it switched back to the red clock. Hmm.
But that reminded me to check the network status.
Yup... it had fallen off the net. It wasn't pingable from any device until a few minutes later and it's dropped the default ipv6 route again. So it definitely looks like it's not liking broadcast traffic after some period of time.
chumbysphere forum → Software → SSH Login not possible after several minute
Powered by PunBB, supported by Informer Technologies, Inc.
