I have been analysing this problem, and googling for clues, and it appears to be related to the Nokia's "aggressive" power management.
According to link, when there is no traffic on the WLAN, the Nokia powers down the transmitter after as little as four seconds. As "mad philosopher" reports -- albeit for trying to connect inward from the outside to the 770 -- this may lead to erratic dropping of the connection.
I believe there is a little more to the story though. This bug isn't reported often enough to be a general Nokia 770 problem. What I believe is happening is, that for some WLAN base stations -- mine is a Zyxel Prestige 660H/HW-D1 ADSL modem -- when the remote host sends stuff down the line when the WLAN client transmitter is already powered down, then it concludes -- rather logically -- that the client has crashed or is no longer around, and just closes the connection.
I tested my suspicion by trying to use ssh while the audio player was connected to the classical WCPE station -- heureka, no more connection drops!
Realizing that this was what was probably happening prompted me to study the issue of "keepalive" in ssh connections. To make a long story short, I modified my vnc start-up script as follows:
---
killall ssh
ssh -f -N -o ServerAliveInterval=2 -o ServerAliveCountMax=15 -L 5901:localhost:5901 me@myhost.org
vncviewer --hostname=localhost:1 --password=[vncpasswd]
---
Explanation: Keep this ssh connection alive by sending a packet every two seconds. Do not timeout the connection until after 15 tries, i.e., 30 seconds. (This will bridge shortish WLAN traffic outings).
You have to put your own userid@hostname and vnc password in there. Connection over an encrypted tunnel will be automatic, asking only for your ssh password (haven't been able to automate that yet from the 770...). On your remote host, only the sshd port, 22, should be open and sshd running and reachable.
Since I did that, I haven't had a single connection drop using vnc (and, using the same two keepalive options, the same holds for raw ssh. Of course you could put them in /etc/ssh/ssh_config too, if you have root. Haven't tried that yet.) Before, these drops were almost predictable when doing, e.g., a large compilation over ssh, when output would stop for several seconds and then try to resume -- only to find the connection gone. With vnc, typically trying to open a new window, especially for a big program, would fail.
Is this a bug in the Nokia (flash image 1.2006.26-8)? In the base station firmware (v.3.40 AGL.3)? Or in the openssh Maemo port (1:3.8p1-3osso4)? I don't know. What does the WLAN standard say?
I suspect that Nokia's own applications, like the browser, are aware of the issue and handle it somehow. How? By not allowing the transmitter to power down before page load has completed? You tell me.
Also, I haven't seen this issue for Bluetooth.
Not even that is simple. It used to be a matter of connecting a server to the Internet and starting sshd as a service; not any more. If you have a standard ADSL modem, you typically have to 1) open its firewall for ssh, 2) enable NAT translation of the external ssh port to the internal IP number of your machine, and 3) if you want to log in to your machine by name, set up one of those 'dyndns' schemes where an external name service keeps continually track of your external IP number -- which will change without notice due to the modem using DHCP, as they all do nowadays.
Sigh. I did all this for my home PC. So now I am happily editing this file, logged from summer cottage to home over vnc, then to kirves/vipunen over ssh -XC, and through to one of the jewels (akaatti) in order to use bluefish.
I am still a little angry with Nokia for selling me a broken pocket workstation -- after all, remote X not working is broken, right? -- but with vnc working as well as it does, it's not so bad anymore. (In fact, in a way it is better, as you don't lose your session when the connection goes down.)
Perhaps I should just stop treating this gadget like an Ultrasparc or Silicon Graphics -- it isn't. But how easy it is to forget ;-/
When sending from a mobile device, you need to find an SMTP service that accepts outside users. Service providers, including TKK, don't allow their SMTP servers to be used from the outside. We all know why not. This would mean finding and using a different SMTP service for every new hotel/access point service provider, or for every new country/GPRS service provider.
The solution is to subscribe to Google Mail, and use authenticated access to their service at gmail.com. Setting up pine to do this is a bit tricky but possible. Here is my set-up (primitive, but works):
smtp-server = smtp.gmail.com/user=[my-gmail-username]/tls/submit/novalidate-cert
inbox-path = imap.hut.fi/imap/ssl/novalidate-cert/user=[my-tkk-username]
default-fcc = {imap.hut.fi/user=[my-tkk-username]}sent-mail
(... similarly for default-saved-msg-folder and postponed-folder ... you don't want them to be saved to your 770. Pine does this automatically right for you)
default-composer-hdrs = Reply-To:,To:,Cc:,Bcc:,Subject:
customized-hdrs: Reply-To [my-tkk-email-address]
(I haven't yet tried to place the relevant certificates on my device. That's also possible through the Certificate Manager, and a good idea if accessing your mail from untrusted places.)
Remember also to enable-mouse-in-xterm. Pine feels almost like a GUI application after that.