Topic: SSH Login not possible after several minute

Hello,

I am new to the chumby, basicly bought because of the ssh possibilities to adapt my settings.
Unfortunately my ssh chumby connection seems to freeze after a certain period of time everytime, and I have to reactivate sshd. Is this a wanted "feature" or a bug?

Re: SSH Login not possible after several minute

Interesting - is anyone else having this problem?

I use ssh all the time, sometimes for days at a time, and have never seen this behavior.

Re: SSH Login not possible after several minute

Well I have noticed a weird thing but I found a way around it.  I think it might be my wireless settings at my house.  But when I first got my C1 I turned on ssh and got onto it but it would freeze and stop responding.  Sometimes after 1-2 minutes or sometimes 5 minutes.  Same for the web server, sometime I am unable to browse the website by ip.

My way around it was I have a Centos/Linux server at my house that does dhcp, web filtering, light automation, etc, and so I would ssh into my server, and then on my server I ssh into the chumby. 

Same problem with scp.  I can't pscp from windows to chumby, but I can scp from linux to chumby. smile  I hope this helps

Re: SSH Login not possible after several minute

I've seen this happen sometimes, but not often.  In at lease one case, I was able to open a new SSH session without restarting the daemon.  What I've had happen much more often is getting into a situation where my connection seems to pause for a few seconds -- I don't get any echo back from the terminal, but then it resumes.  I'd always thought these could be wireless network problems, so I hadn't paid too much attention.

Oh, and yes, I'm using PUTTY on Windows to connect to my Chumby.

Re: SSH Login not possible after several minute

I agree my issues might be more wireless than being the chumby.

Re: SSH Login not possible after several minute

I've not seen this and I am SSHed to my chumbies quite often.

Linux Guy - Occasional Chumby Hacker

Re: SSH Login not possible after several minute

I've seen this as well.  If the wifi connection sits idle for some amount of time roughly on the order of 10 minutes, it seems to drop off the network.  Opening the network settings screen usually fixes it, but once I had to actually disconnect and reconnect for it to become reachable.

Re: SSH Login not possible after several minute

Actually, I tried to play a radio stream during ssh´ing, the same happened, sometimes after 2m sometimes after 5-6 minutes. The raidostream continues.
The same without streaming, so I assume it´is not an WiFi idle problem.

Re: SSH Login not possible after several minute

I've had this happen several times to me. I'll SSH into my C1 and the connection just dies sometimes just after a few minutes.  Other occasions, SSH would work okay for as long as I'm using it. The C1 is only about 20 feet from the router in the next room. I'm using Putty also on Win7.

10 (edited by Fabur 2010-01-30 12:37:05)

Re: SSH Login not possible after several minute

Hey,

I am also having problems with SSH.

My connection will drop after some minutes (seems to be a bit random) and will freeze the ssh daemon.

Music is still playing, but I can't ssh into the chumby, timeout, and I can't ping the chumby.


After some time the daemon seems to come back and I am able to log in again until it freezes again.
Or I have to restart my chumby to get it back faster.


I am using Cygwin for Windows.
Chumby and pc on wifi.

[edit] It's also a Chumby One [/edit]

Re: SSH Login not possible after several minute

When you reconnect, try running dmesg.  You may see that it's disassociated with the access point and has gone and reassociated itself.

Re: SSH Login not possible after several minute

Would it still stream music if that is the case?

Because the music playback from shoutcast was fine, no hickups.

Re: SSH Login not possible after several minute

Here is my dmesg output after ssh was avaiable again.

00] chumbyfbfw.c - chumbyfwfb_probe():1341 - allocated at ffbe0000:0x43c00000
[    0.560000] chumbyfbfw.c - chumbyfwfb_probe():1331 - memory to allocate for p
lane 2: 307200
[    0.560000] chumbyfbfw.c - chumbyfwfb_probe():1341 - allocated at ffc2b000:0x
43c80000
[    0.570000] chumbyfbfw.c - chumbyfwfb_probe():1331 - memory to allocate for p
lane 3: 307200
[    0.570000] chumbyfbfw.c - chumbyfwfb_probe():1341 - allocated at ffc76000:0x
43d00000
[    0.580000] Going to copy splash image from c0356969 (153600 bytes) to ffa000
00 (not 43a00000)
[    0.590000] Panel init finished.
[    0.590000] unsupported display_on call
[    0.600000] chumbyfbfw.c - pxp_setup():1145 - Pointing S0 at 43980000
[    0.600000] stmp37xx-dbguart.0: ttyAM0 at MMIO 0xf0070000 (irq = 0) is a Debu
g UART
[    0.650000] NET: Registered protocol family 2
[    0.660000] Switched to high resolution mode on CPU 0
[    0.760000] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.760000] TCP established hash table entries: 2048 (order: 2, 16384 bytes)
[    0.770000] TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
[    0.780000] TCP: Hash tables configured (established 2048 bind 2048)
[    0.790000] TCP reno registered
[    0.820000] NET: Registered protocol family 1
[    0.830000] ashmem: initialized
[    0.890000] Registering unionfs 2.5.2 (for 2.6.28.10)
[    0.910000] NTFS driver 2.1.29 [Flags: R/O].
[    0.920000] fuse init (API version 7.10)
[    0.930000] msgmni has been set to 116
[    0.940000] alg: No test for stdrng (krng)
[    0.950000] cryptodev: driver loaded.
[    0.950000] io scheduler noop registered (default)
[    0.960000] init_bl
[    0.960000] init_bl finished
[    0.960000] set_bl_intensity with 100
[    0.960000] intensity after modifiers: 100
[    0.970000] setting with parameters 600
[    0.970000] done.
[    1.040000] logger: created 64K log 'log_main'
[    1.040000] logger: created 256K log 'log_events'
[    1.050000] logger: created 64K log 'log_radio'
[    1.060000] STMP3xxx RTC driver v1.0 hardware v2.0.0
[    1.060000] stmp3xxx-rtc stmp3xxx-rtc: rtc core: registered stmp3xxx-rtc as r
tc0
[    1.070000] power_supply battery: uevent
[    1.070000] power_supply battery: No power supply yet
[    1.070000] power_supply battery: power_supply_changed
[    1.070000] power_supply ac: uevent
[    1.070000] power_supply ac: No power supply yet
[    1.070000] power_supply battery: power_supply_changed_work
[    1.070000] power_supply battery: power_supply_update_bat_leds 3
[    1.070000] power_supply battery: uevent
[    1.070000] power_supply battery: POWER_SUPPLY_NAME=battery
[    1.070000] power_supply battery: Static prop TYPE=Battery
[    1.070000] power_supply battery: 9 dynamic props
[    1.070000] power_supply battery: prop STATUS=Not charging
[    1.070000] power_supply battery: prop PRESENT=0
[    1.070000] power_supply battery: prop HEALTH=Unknown
[    1.070000] power_supply battery: prop TECHNOLOGY=Li-ion
[    1.070000] power_supply battery: prop VOLTAGE_NOW=3576000
[    1.070000] power_supply battery: prop VOLTAGE_AVG=3576000
[    1.070000] power_supply battery: prop CURRENT_NOW=0
[    1.070000] power_supply battery: prop TEMP=4039
[    1.070000] power_supply battery: prop CAPACITY=82
[    1.070000] power_supply ac: power_supply_changed
[    1.070000] power_supply usb: uevent
[    1.070000] power_supply usb: No power supply yet
[    1.070000] power_supply ac: power_supply_changed_work
[    1.070000] power_supply ac: power_supply_update_gen_leds 1
[    1.070000] power_supply ac: uevent
[    1.070000] power_supply ac: POWER_SUPPLY_NAME=ac
[    1.070000] power_supply ac: Static prop TYPE=Mains
[    1.070000] power_supply ac: 2 dynamic props
[    1.070000] power_supply ac: prop ONLINE=1
[    1.070000] power_supply ac: prop TEMP=64
[    1.070000] power_supply usb: power_supply_changed
[    1.080000] ddi_bc_Init: success
[    1.080000] stmp3xxx-battery stmp3xxx-battery.0: bc_sm_restart: no battery pr
esent
[    1.090000] power/linux.c - bc_sm_restart():974 - Returning from sm_restart()
[    1.090000] power_supply usb: power_supply_changed_work
[    1.090000] power_supply usb: power_supply_update_gen_leds 0
[    1.090000] power_supply usb: uevent
[    1.090000] power_supply usb: POWER_SUPPLY_NAME=usb
[    1.090000] power_supply usb: Static prop TYPE=USB
[    1.090000] power_supply usb: 2 dynamic props
[    1.090000] power_supply usb: prop ONLINE=0
[    1.090000] power_supply usb: prop TEMP=64
[    1.410000] oprofile: using timer interrupt.
[    1.410000] nf_conntrack version 0.5.0 (1024 buckets, 4096 max)
[    1.420000] CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please 
use
[    1.430000] nf_conntrack.acct=1 kernel paramater, acct=1 nf_conntrack module 
option or
[    1.440000] sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
[    1.450000] ip_tables: (C) 2000-2006 Netfilter Core Team
[    1.460000] arp_tables: (C) 2002 David S. Miller
[    1.460000] TCP cubic registered
[    1.470000] NET: Registered protocol family 10
[    1.490000] IPv6 over IPv4 tunneling driver
[    1.510000] NET: Registered protocol family 17
[    1.520000] RPC: Registered udp transport module.
[    1.520000] RPC: Registered tcp transport module.
[    1.530000] stmp3xxx-rtc stmp3xxx-rtc: setting system clock to 2010-01-30 14:
00:03 UTC (1264860003)
[    1.540000] Waiting for root device /dev/mmcblk0p3...
[    1.550000] mmc0: new SD card at address 1234
[    1.560000] mmcblk0: mmc0:1234 SA02G 1.83 GiB 
[    1.560000]  mmcblk0: p1 p2 p3 p4 < p5 p6 >
[    1.660000] EXT3-fs: mounted filesystem with ordered data mode.
[    1.670000] VFS: Mounted root (ext3 filesystem) readonly.
[    1.670000] Freeing init memory: 124K
[    1.680000] kjournald starting.  Commit interval 5 seconds
[    2.950000] kjournald starting.  Commit interval 5 seconds
[    2.960000] EXT3 FS on mmcblk0p5, internal journal
[    2.970000] EXT3-fs: mounted filesystem with journal data mode.
[    3.130000] kjournald starting.  Commit interval 5 seconds
[    3.140000] EXT3 FS on mmcblk0p6, internal journal
[    3.150000] EXT3-fs: mounted filesystem with ordered data mode.
[    3.690000] power_supply ac: uevent
[    3.690000] power_supply ac: POWER_SUPPLY_NAME=ac
[    3.690000] power_supply ac: Static prop TYPE=Mains
[    3.690000] power_supply ac: 2 dynamic props
[    3.690000] power_supply ac: prop ONLINE=1
[    3.690000] power_supply ac: prop TEMP=64
[    3.700000] power_supply battery: uevent
[    3.700000] power_supply battery: POWER_SUPPLY_NAME=battery
[    3.700000] power_supply battery: Static prop TYPE=Battery
[    3.700000] power_supply battery: 9 dynamic props
[    3.700000] power_supply battery: prop STATUS=Not charging
[    3.700000] power_supply battery: prop PRESENT=0
[    3.700000] power_supply battery: prop HEALTH=Good
[    3.700000] power_supply battery: prop TECHNOLOGY=Li-ion
[    3.700000] power_supply battery: prop VOLTAGE_NOW=8000
[    3.700000] power_supply battery: prop VOLTAGE_AVG=3576000
[    3.700000] power_supply battery: prop CURRENT_NOW=0
[    3.700000] power_supply battery: prop TEMP=4033
[    3.700000] power_supply battery: prop CAPACITY=82
[    3.700000] power_supply usb: uevent
[    3.700000] power_supply usb: POWER_SUPPLY_NAME=usb
[    3.700000] power_supply usb: Static prop TYPE=USB
[    3.700000] power_supply usb: 2 dynamic props
[    3.700000] power_supply usb: prop ONLINE=0
[    3.700000] power_supply usb: prop TEMP=65
[    4.040000] Chumby bend sensor driver version 2.3-Falconwing initializing (sc
ross@chumby.com)...
[    4.050000] input: bend-sensor as /devices/platform/bend-sensor/input/input0
[    7.060000] input: STMP3XXX touchscreen as /devices/virtual/input/input1
[    8.100000] mice: PS/2 mouse device common for all mice
[   11.070000] usbcore: registered new interface driver usbfs
[   11.100000] usbcore: registered new interface driver hub
[   11.110000] usbcore: registered new device driver usb
[   11.190000] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[   11.200000] fsl-ehci fsl-ehci: Freescale On-Chip EHCI Host Controller
[   11.220000] fsl-ehci fsl-ehci: new USB bus registered, assigned bus number 1
[   12.350000] fsl-ehci fsl-ehci: irq 11, io mem 0xf0080000
[   12.370000] fsl-ehci fsl-ehci: USB 2.0 started, EHCI 1.00
[   12.390000] usb usb1: configuration #1 chosen from 1 choice
[   12.390000] hub 1-0:1.0: USB hub found
[   12.400000] hub 1-0:1.0: 1 port detected
[   12.720000] usb 1-1: new high speed USB device using fsl-ehci and address 2
[   12.890000] usb 1-1: configuration #1 chosen from 1 choice
[   12.910000] hub 1-1:1.0: USB hub found
[   12.910000] hub 1-1:1.0: 4 ports detected
[   13.200000] usb 1-1.1: new high speed USB device using fsl-ehci and address 3
[   13.320000] usb 1-1.1: configuration #1 chosen from 1 choice
[   13.510000] usb 1-1.2: new high speed USB device using fsl-ehci and address 4
[   13.790000] usb 1-1.2: configuration #1 chosen from 1 choice
[   14.260000] SCSI subsystem initialized
[   14.390000] Initializing USB Mass Storage driver...
[   14.390000] scsi0 : SCSI emulation for USB Mass Storage devices
[   14.420000] usb-storage: device found at 3
[   14.420000] usb-storage: waiting for device to settle before scanning
[   14.420000] usbcore: registered new interface driver usb-storage
[   14.430000] USB Mass Storage support registered.
[   14.870000] cfg80211: Using static regulatory domain info
[   14.870000] cfg80211: Regulatory domain: US
[   14.880000]  (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp
)
[   14.880000]  (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
[   14.890000]  (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[   14.910000]  (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[   14.910000]  (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[   14.930000]  (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[   14.930000]  (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
[   14.950000] cfg80211: Calling CRDA for country: US
[   15.650000] phy0 -> rt2500usb_init_eeprom: Error - Invalid RT chipset detecte
d.
[   15.650000] phy0 -> rt2x00lib_probe_dev: Error - Failed to allocate device.
[   15.670000] usbcore: registered new interface driver rt2500usb
[   16.150000] phy1: Selected rate control algorithm 'minstrel'
[   16.160000] Registered led device: rt73usb-phy1::radio
[   16.170000] Registered led device: rt73usb-phy1::assoc
[   16.180000] Registered led device: rt73usb-phy1::quality
[   16.200000] usbcore: registered new interface driver rt73usb
[   16.430000] rt73usb 1-1.2:1.0: firmware: requesting rt73.bin
[   16.670000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   19.420000] scsi 0:0:0:0: Direct-Access     Ut163    USB2FlashStorage 0.00 PQ
: 0 ANSI: 2
[   19.460000] usb-storage: device scan complete
[   19.670000] Driver 'sd' needs updating - please use bus_type methods
[   19.680000] sd 0:0:0:0: [sda] 128000 512-byte hardware sectors: (65.5 MB/62.5
 MiB)
[   19.690000] sd 0:0:0:0: [sda] Write Protect is off
[   19.700000] sd 0:0:0:0: [sda] Mode Sense: 00 00 00 00
[   19.700000] sd 0:0:0:0: [sda] Assuming drive cache: write through
[   19.710000] sd 0:0:0:0: [sda] 128000 512-byte hardware sectors: (65.5 MB/62.5
 MiB)
[   19.720000] sd 0:0:0:0: [sda] Write Protect is off
[   19.720000] sd 0:0:0:0: [sda] Mode Sense: 00 00 00 00
[   19.720000] sd 0:0:0:0: [sda] Assuming drive cache: write through
[   19.730000]  sda: sda1
[   19.790000] sd 0:0:0:0: [sda] Attached SCSI removable disk
[   19.900000] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   22.280000] i2c /dev entries driver
[   23.020000] ASoC version 0.13.2
[   23.200000] STMP378X ADC/DAC Audio Codec 0.1
[   23.200000] asoc: stmp378x adc/dac <-> stmp3xxx adc/dac mapping ok
[   23.760000] Chumby timerx[2] driver version 3.0-Falconwing initializing (bunn
ie@chumby.com)... show me your jiffies!!!
[   25.580000] input: stmp3xxx-rotdec as /devices/virtual/input/input2
[   27.780000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   30.740000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   34.130000] wlan0: deauthenticating from c280462c by local choice (reason=3)
[   34.140000] wlan0: direct probe to AP c280462c (try 1)
[   34.150000] wlan0: direct probe responded
[   34.150000] wlan0: authenticate with AP c280462c (try 1)
[   34.150000] wlan0: authenticated
[   34.150000] wlan0: associate with AP c280462c (try 1)
[   34.150000] wlan0: RX AssocResp from c380e03e (capab=0x411 status=0 aid=1)
[   34.150000] wlan0: associated
[   34.170000] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   44.550000] wlan0: no IPv6 routers present
[ 4653.120000] usb 1-1.1: USB disconnect, address 3
[ 5872.430000] usb 1-1.1: new high speed USB device using fsl-ehci and address 5
[ 5872.570000] usb 1-1.1: configuration #1 chosen from 1 choice
[ 5872.630000] scsi1 : SCSI emulation for USB Mass Storage devices
[ 5872.700000] usb-storage: device found at 5
[ 5872.700000] usb-storage: waiting for device to settle before scanning
[ 5877.700000] scsi 1:0:0:0: Direct-Access     Ut163    USB2FlashStorage 0.00 PQ
: 0 ANSI: 2
[ 5877.810000] sd 1:0:0:0: [sda] 128000 512-byte hardware sectors: (65.5 MB/62.5
 MiB)
[ 5877.820000] sd 1:0:0:0: [sda] Write Protect is off
[ 5877.830000] sd 1:0:0:0: [sda] Mode Sense: 00 00 00 00
[ 5877.830000] sd 1:0:0:0: [sda] Assuming drive cache: write through
[ 5877.880000] sd 1:0:0:0: [sda] 128000 512-byte hardware sectors: (65.5 MB/62.5
 MiB)
[ 5877.890000] sd 1:0:0:0: [sda] Write Protect is off
[ 5877.890000] sd 1:0:0:0: [sda] Mode Sense: 00 00 00 00
[ 5877.890000] sd 1:0:0:0: [sda] Assuming drive cache: write through
[ 5877.900000]  sda: sda1
[ 5877.960000] sd 1:0:0:0: [sda] Attached SCSI removable disk
[ 5878.000000] sd 1:0:0:0: Attached scsi generic sg0 type 0
[ 5878.010000] usb-storage: device scan complete
[ 7082.310000] usb 1-1.1: USB disconnect, address 5
[ 7091.770000] usb 1-1.1: new low speed USB device using fsl-ehci and address 6
[ 7091.920000] usb 1-1.1: configuration #1 chosen from 1 choice
[ 7092.740000] usbcore: registered new interface driver usbhid
[ 7092.740000] usbhid: v2.6:USB HID core driver
[ 7107.910000] usb 1-1.1: USB disconnect, address 6
[ 7110.980000] usb 1-1.1: new low speed USB device using fsl-ehci and address 7
[ 7111.140000] usb 1-1.1: configuration #1 chosen from 1 choice
[ 7118.150000] usb 1-1.1: USB disconnect, address 7
[ 7123.510000] usb 1-1.1: new high speed USB device using fsl-ehci and address 8
[ 7123.660000] usb 1-1.1: configuration #1 chosen from 1 choice
[ 7123.690000] scsi2 : SCSI emulation for USB Mass Storage devices
[ 7123.790000] usb-storage: device found at 8
[ 7123.790000] usb-storage: waiting for device to settle before scanning
[ 7128.790000] scsi 2:0:0:0: Direct-Access     Ut163    USB2FlashStorage 0.00 PQ
: 0 ANSI: 2
[ 7128.850000] sd 2:0:0:0: [sda] 128000 512-byte hardware sectors: (65.5 MB/62.5
 MiB)
[ 7128.860000] sd 2:0:0:0: [sda] Write Protect is off
[ 7128.880000] sd 2:0:0:0: [sda] Mode Sense: 00 00 00 00
[ 7128.880000] sd 2:0:0:0: [sda] Assuming drive cache: write through
[ 7128.890000] sd 2:0:0:0: [sda] 128000 512-byte hardware sectors: (65.5 MB/62.5
 MiB)
[ 7128.900000] sd 2:0:0:0: [sda] Write Protect is off
[ 7128.900000] sd 2:0:0:0: [sda] Mode Sense: 00 00 00 00
[ 7128.900000] sd 2:0:0:0: [sda] Assuming drive cache: write through
[ 7128.910000]  sda: sda1
[ 7129.030000] sd 2:0:0:0: [sda] Attached SCSI removable disk
[ 7129.040000] sd 2:0:0:0: Attached scsi generic sg0 type 0
[ 7129.060000] usb-storage: device scan complete

Re: SSH Login not possible after several minute

Here is a workaround for this problem:

My Chumby One had the same symptoms:  it sometimes was unresponsive to external ssh, http, or ping requests while internal widgets could access the network normally.  I tried a factory reset but the problem persisted, and dmesg revealed no issues.

I spent a few hours this evening troubleshooting and determined the problem occurs because Chumby sometimes stops responding to arp requests.  An (ugly) workaround until the problem is fixed is to add a static (permanent) arp entry to the computer trying to connect to Chumby, e.g.

Windows: arp -s chumby_ipaddr chumby_hwaddr windows_ipaddr
Example: arp -s 192.168.1.126 00-27-19-01-23-45 192.168.1.100

Linux: arp -s chumby_ipaddr chumby_hwaddr
Example: arp -s 192.168.1.126 00:27:19:01:23:45

When Chumby is in one of his unresponsive moods I can make the problem disappear or reappear at will by adding (arp -s) or deleting (arp -d) Chumby from the arp cache on my workstation.  Chumby reliably answers ssh, http, and ping requests with the above workaround in place.

15 (edited by Fabur 2010-02-01 11:09:29)

Re: SSH Login not possible after several minute

When I can't ssh into my chumby, it's disappeared from the arp -a list, but I am unable to add it manually.
I am running Vista.

Cygwin and Windows CMD (in admin mode) won't work.

I will try and see if I can't find a solution to that.


[edit]Can't find a working solution for me.
I am always getting an error 5 when I try to add something.
Looks like some missing rights, but even admin mode won't help.[/edit]


[edit2]Ok Cygwin in Admin Mode was able to do what CMD in Admin Mode wasn't.
It is working great since now. No ssh timeouts or whatsoever.[/edit2]

Re: SSH Login not possible after several minute

Some further troubleshooting data:

I wrote a little Unix workstation program to test once a minute for failure of Chumby to respond to an arp request.  It's been running now for about 36 hours, and this is what I've found:

1) The Chumby arp problem begins at random times, but Chumby arp responses always resume working again at the next occurrence of exactly 30 minutes after the hour.  For example, if Chumby stops responding to arp requests at 0648, Chumby will resume responding to arp requests at exactly 0730.
2) The arp problem never begins when Chumby is in night mode or has a simple pinned widget that doesn't access the network, e.g. Chumby Analog Clock.
3) The arp problem does occur with a channel that alternates between Chumby Analog Clock and Facebook, or between Chumby Analog Clock and Twitter.

Hope that helps someone reproduce and/or understand the problem.

Re: SSH Login not possible after several minute

Thanks all - please keep collecting this type of information!

18 (edited by Fabur 2010-02-02 12:37:49)

Re: SSH Login not possible after several minute

I am also using the Facebook widget with the Ping Pong Clock.

Didn't check the rest.


[edit] Ok, my Chumby was running the whole day and when I just tried to connect, it didn't work.
But I didn't think of waiting to check for the xx:30 thingy.
And sadly even my Cygwin in Admin Mode won't let me use arp -s anymore and I don't know why.
Damn Vista.

Re: SSH Login not possible after several minute

Fabur, you should have a non-Cygwin "arp" command on Windows.  Mine is in c:\windows\system32\arp.exe.

Re: SSH Login not possible after several minute

Fabur, a web search finds many people encountering the "access denied" problem with the Windows arp -s command.  The suggested workaround (as administrator) is to instead set the arp entry with netsh, e.g.

netsh interface ipv4 add neighbors "Local Area Connection" A.B.C.D XX-XX-XX-XX-XX-XX

21 (edited by Fabur 2010-02-02 14:25:46)

Re: SSH Login not possible after several minute

Hey unwiredben, the arp.exe is used by the Windows CMD and Cygwin.
I really don't know what both programs are doing, but just now Cygwin (in admin mode) was able to delete the dynamic entry of the chumby device and add a static one (until reboot).
On my last try, after the reboot of my chumby, it didn't work.

I don't really understand why, perhaps it can only add it when it had it as a dynamic entry or whatever.

[edit]
Ok I really don't get it anymore.
CMD arp is working at the moment.
I hate Vista.

I will try some stuff these days, perhaps I can find the problem my Vista is having with the arp command.

And I did some search on the web, but it did not work.[/edit]

22 (edited by Napalm 2010-02-09 14:56:42)

Re: SSH Login not possible after several minute

nu3e wrote:

1) The Chumby arp problem begins at random times, but Chumby arp responses always resume working again at the next occurrence of exactly 30 minutes after the hour.  For example, if Chumby stops responding to arp requests at 0648, Chumby will resume responding to arp requests at exactly 0730.

I can confirm that. Chumby was unreachable starting at 23:18 and was reachable again at 23:30

I can also confirm, that after chumby was unreachable again (23:50, yes it happens very often with my chumby) and a ping was not possible, i executed

netsh interface ipv4 add neighbors "LAN-Verbindung" "192.168.178.110" "00-27-19-b7-fb-5f"

on my win7 machine and a ping was possible again.

Re: SSH Login not possible after several minute

Wow - that's really odd.  We're attempting to reproduce this "30 minutes after the hour" thing - that should help narrow down which service might be causing this.

Re: SSH Login not possible after several minute

I have exactly this problem with my chumby 1 too. And interestingly (?) I have exactly the same issue with my wireless USB connected media center PC. I've not verified the 30-minutes-past-the-hour cure exactly, but I have noted that both the chumby and the media PC (running kubuntu 9.10) do fail/revive at the same time as far as answering arps are concerned. I opened a discussion on the ubuntu forums a while back at

http://ubuntuforums.org/showthread.php?t=1339233

I note that both the chumby and my PC are both using the RALINK rt73usb/rt2x00usb device drivers.

For the record, I have a NETGEAR DG834G wireless router running V3.01.38 firmware.

25 (edited by mikec 2010-04-07 15:23:56)

Re: SSH Login not possible after several minute

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.