Recurring freezes in ssh sessions
 

This is the follow-up to my previous post on the netmask issue.

Once *incoming* sessions (ping, ssh) to the 770 started working, I could now ssh to the dropbear server. But there is still a problem, although I don't know if it's related or not.

Connecting from the command-line ssh on the Gentoo box or the Zaurus works, and it's good to finally have MC on the Nokia with a real keyboard :-)
When it works normally, reaction and display times are surprisingly fast, even more so than when I similarly ssh to the Zaurus. The problem is, the connection "freezes" regularly and frequently for long periods of time (like 10 seconds or more), appearing to be completely dead, then resumes zippy operation like nothing had happened. This makes it hardly usable from Linux ssh, and impossible from Windows, as PuTTY either doesn't connect at all or timesout at the first such freeze. I do ssh with PuTTY all the time, to the Gentoo box and to the Zaurus, sometimes to other machines through the net, and have never seen such a thing.

Anybody got an idea ?

It was too late last night, but maybe this evening I'll try the next dumb thing and change the netmask on the 770 to regular Class A (255.0.0.0), and maybe even on the other machines too. At this level of strangeness, black magic and voodoo are no worse than reasoning :-)

Your experience is very interesting. I have also noticed the pauses when I connected with putty from my win2k3 machine at home. Although obviously not as severe since I was able to connect just fine.

I'm pretty sure that there is some black magic going on as to the power management of the 770. It's just simply amazing to me that Nokia has been able to squeeze so much runtime out of this battery. Are you aware that the processor stops every few milliseconds when the backlight goes off as a power conservation method? Maybe the radio does something similar.

Anyway, it seems to me that your question may be better suited to the maemo-dev mailing list for a more accurate answer.

Well, it seems that's a very insightful piece of intuition you had here ! There does appear to be some radical power management going on in the radio subsystem. Apparently it's even done while on mains power, although maybe less aggressively than when on battery : with the AC adapter I managed to connect from XP with Putty on first try, and only had the first freeze later on when in MC. I also verified that (re)loading a web page in Opera unlocked the ssh session immediately.

So my experience verifies your guess :

- absence of WLAN traffic for a very short period of time (seconds ?) will put the 770's network subsystem in "sleep mode"
- outgoing activity from the 770 wakes it up immediately and transparently
- incoming activity has a harder time waking it up (maybe a poll at fixed intervals ?)

Fortunately, it also seems that incoming activity on a live interface prevents it from going asleep (which sort of makes sense :-). So there is a very simple workaround to ensure comfortable ssh sessions without annoying pauses, under Windows or Unix :

- launch a console windows and type : ping -t xx.xx.xx.xx (IP of 770)
- "activate" the Nokia's WLAN if necessary by loading a web page or such
- verify that the ping commands are successful and stay that way
- launch ssh session. Mine has been running idle for more than an hour now, with no freezes :)

Thanks for providing the solution ! Now I must verify that my wild goose chase with IP subnet masks yesterday was total crap and coincidence, as it must surely be :-)

Correction : "ping -t" is under Windows and takes no parameter other than the IP address (continuous pinging).

Under Linux it's "ping -i" and you can (must) specify the interval between pings, in seconds. The following tests show that the "sleep-mode timeout" on the 770 is between 4 and 5 seconds :

$ ping -i 4 10.10.10.12
PING 10.10.10.12 (10.10.10.12) 56(84) bytes of data.
64 bytes from 10.10.10.12: icmp_seq=1 ttl=64 time=11.8 ms
64 bytes from 10.10.10.12: icmp_seq=2 ttl=64 time=3.11 ms
64 bytes from 10.10.10.12: icmp_seq=3 ttl=64 time=3.10 ms
64 bytes from 10.10.10.12: icmp_seq=4 ttl=64 time=3.61 ms
64 bytes from 10.10.10.12: icmp_seq=5 ttl=64 time=2.91 ms
64 bytes from 10.10.10.12: icmp_seq=6 ttl=64 time=2.81 ms
64 bytes from 10.10.10.12: icmp_seq=7 ttl=64 time=3.00 ms
64 bytes from 10.10.10.12: icmp_seq=8 ttl=64 time=2.95 ms
64 bytes from 10.10.10.12: icmp_seq=9 ttl=64 time=3.18 ms
64 bytes from 10.10.10.12: icmp_seq=10 ttl=64 time=3.55 ms
64 bytes from 10.10.10.12: icmp_seq=11 ttl=64 time=2.88 ms
64 bytes from 10.10.10.12: icmp_seq=12 ttl=64 time=2.97 ms
^C
--- 10.10.10.12 ping statistics ---
16 packets transmitted, 16 received, 0% packet loss, time 60005ms
rtt min/avg/max/mdev = 2.810/3.683/11.878/2.131 ms

$ ping -i 5 10.10.10.12
PING 10.10.10.12 (10.10.10.12) 56(84) bytes of data.
64 bytes from 10.10.10.12: icmp_seq=6 ttl=64 time=1892 ms
64 bytes from 10.10.10.12: icmp_seq=7 ttl=64 time=3.28 ms
64 bytes from 10.10.10.12: icmp_seq=8 ttl=64 time=2.88 ms
64 bytes from 10.10.10.12: icmp_seq=15 ttl=64 time=415 ms
64 bytes from 10.10.10.12: icmp_seq=22 ttl=64 time=1286 ms
64 bytes from 10.10.10.12: icmp_seq=23 ttl=64 time=2.98 ms
64 bytes from 10.10.10.12: icmp_seq=24 ttl=64 time=3.29 ms
64 bytes from 10.10.10.12: icmp_seq=31 ttl=64 time=2370 ms
64 bytes from 10.10.10.12: icmp_seq=32 ttl=64 time=3.53 ms
64 bytes from 10.10.10.12: icmp_seq=33 ttl=64 time=3.40 ms
64 bytes from 10.10.10.12: icmp_seq=37 ttl=64 time=2.99 ms
64 bytes from 10.10.10.12: icmp_seq=39 ttl=64 time=3.25 ms
^C
--- 10.10.10.12 ping statistics ---
39 packets transmitted, 12 received, 69% packet loss, time 189990ms
rtt min/avg/max/mdev = 2.889/499.257/2370.771/818.451 ms

Aggressive, indeed :-)

I may be insightful, but usually it's just that I remember hearing a fact somewhere and can't be arsed to look it up again. "I'm pretty sure" is just my disclaimer. :rolleyes:

A word of warning :

If I haven't been hallucinating again at 01:00am last night, there is a serious pitfall when using the 770 the way I described above (ie keeping the WLAN interface up at all times, with a cyclic ping or otherwise, while you work in the ssh session). It seems this eats the battery faster than the AC adapter is able to charge it !

I say this because when I started my test yesterday the battery was full or nearly so (3 or 4 bars). I then plugged it in (battery icon changing to animated charge) and left it so the entire evening with the ping and ssh session active. When I unplugged it again after this (admittedly very lengthy but mostly inactive) session, there was only one (red) bar left ! Instead of recharging the battery had actually emptyied...

Either that or my 770 has a hardware problem :-)

Instead of running ping you might just want to set the parameters in your ssh client to keep the connection alive.

Putty:

Under Connection
Seconds between Keepalives = 4
Enable TCP keepalives = checked

WinSCP:
Under Connection
Sending of Null SSH packets = checked
Seconds between keepalives = 4

OpenSSh Client:
check this link http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config


Other ssh clients should have similar settings. So far these have worked great for me.

Pete B

Thanks a lot for those hints ! I have been using Putty and WinSCP for years and had never thought to look there (probably never would have either :-).
Works like a champ too. Kudos !

For me with ssh under linux (Mandrake with openssh 4.2p1):

Ok I posted the above notes for putty and for some reason today they are not working for me. I can lose the connection while I am typing something even with the above settings. This is getting very annoying. Guess it is time to dig into the low level wlan settings and see how they are doing this power management.

Pete