[dvdnet]

Folks, I've had this issue from day one with my powerbook and have just lived with it but it's time I tracked the source of the problem.

2 scenarios:

1) From my powerbook, I ssh to my work machine, or some of my international servers. All is fine, connections are fine, no problems can do all I need to do. Leave the session idle for a few minutes, haven't really timed how long, and the session becomes frozen.

2) From my work machine, I ssh to my powerbook that is at home on my network. All is fine, connections are fine, no problems can do all I need to do. Leave the session idle for a few minutes, haven't really timed how long, and the session becomes frozen.


Why does it freeze up? How can I keep the connection active? Is it ssh related or TCP related?

I've had a 1Ghz PB17 and have upgraded to a 1.5Ghz PB17. Both do exactly the same thing.

It gets annoying when you've got 3 terminal windows open to do work and because you've spent so much time in one of them, the other 2 become frozen and you have to reconnect again.

Any help appreciated.

Steve.

[utidjian]

Are you doing ssh over a WiFi/Airport network?
Try using screen (see man screen for more details) for now. screen handles disconnects gracefully.
Is the PB "sleeping"?

[dvdnet]

utidjian,
yes, I am networking over a wifi network (Airport Extreme Base Station). Something tells me we're onto something here.

Could this explain it? If so, how do I get around it?

Cheers,
Steve

[utidjian]

Originally posted by dvdnet:
utidjian,
yes, I am networking over a wifi network (Airport Extreme Base Station). Something tells me we're onto something here.

Could this explain it? If so, how do I get around it?

I have no experience myself with an AP-X base station. I always have used Linksys WAPs. I use plenty of AP-X cards in my iMacs (lab of 13 iMacs) and various laptops with no problems. I also use a Linksys WAP at home.

I have heard of lots of problems with all kinds of WiFi systems (Windows, Mac OS X, AP, AP-X, base stations and clients) with connection reliability. So many, in fact, that it is difficult to keep up with the issues. Personally, I haven't yet had a problem with my setup(s) so I haven't really looked in to any of the possible solutions. My feeling is that the solutions will be as varied as the problems and combinations of equipment.

Using screen may help for a while as a "bandaid" but will not fix the issue. WiFi, in general, is not 100.000% reliable, and neither is a wired network, so it is a good idea to use screen all the time for remote connections if you are doing important stuff. I mainly use ssh to my Mac clients for running 'sudo softwareupdate -a -i' and I don't want that to be interrupted by any kind of disconnect... screen handles a disconnect well.

I don't know if you have ever used screen before but it is a damn handy tool. When you ssh to wherever just type 'screen' at the prompt and you will have a screen shell which is identical to the normal bash shell (or whatever). If the session becomes disconnected or wedged for whatever reason just ssh to the same machine again and type:

screen -r

to resume the session. If it says that it is currently connected just:

screen -d

to disconnect the session and then:

screen -r

to attach again.

You can have multiple screen sessions running concurrently and nested screen sessions.

When an ssh session hangs on you next time try the 'netstat' command to see if it shows that there is a connection. It might tell you something useful.

[dvdnet]

utidjian,
I tried screen, have used it many years ago and never realised it was included with OS X. At first I thought it was working a charm BUT it's just frozen up on me again. Did the ol screen -d -r and it retrieved the session in another terminal window but still no response.

Any other suggestions? Anyone? Bueller? Fry?

Steve.

[utidjian]

Originally posted by dvdnet:
utidjian,
I tried screen, have used it many years ago and never realised it was included with OS X. At first I thought it was working a charm BUT it's just frozen up on me again. Did the ol screen -d -r and it retrieved the session in another terminal window but still no response.

Any other suggestions? Anyone? Bueller? Fry?

Very strange. Have you looked at your power settings on the laptop? Do you have another Mac? Does it do the same thing? Have you tried eliminating AP (just connect via wire)? What did netstat tell you?

As an example:

Code:
core:~ utidjian$ netstat | less

Active Internet connections
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp4       0      0  core.butternut.o.ssh   cobalt.butternut.32819 ESTABLISHED

That is an ssh session from cobalt (an IBM Intellistation Z Pro running Fedora Core 2 Linux) to core (an Apple Cube running Mac OS X 10.3.5). As you can see the Recv-Q and Send-Q are "empty" (nothing waiting) and the connection is "ESTABLISHED". What do you see when one of your connections freezes?

[Zim]

No answers here, just a "you are not alone" post.

I got a PB a few months ago and added wireless to my house. I would
often ssh from my PB up to my desktop.

Sometimes, but not often, the ssh session does get hung and freezes.
I cannot ctrl-C, ctrl-Z, etc out of it. Not sure if I tried a 2nd Terminal window and killed the PID or not.

I certainly didn't try screen, but I will next go-around. Also will check with netstat.

Most of the time, the ssh connection just times out and disconnects once the PB goes to sleep. Any way to maintain during this point, or is there a keep-alive for the session that causes it to disconnect while the PB is sleeping?

Cheers,
Mike

[GeeYouEye]

The problem is with ssh. KeepAlive is currently broken in every current version ssh implementation except, of all things, PuTTY on Windows.

[dvdnet]

Originally posted by GeeYouEye:
The problem is with ssh. KeepAlive is currently broken in every current version ssh implementation except, of all things, PuTTY on Windows.

Hmm, the issue I have is that my friends who all have 17" powerbooks are not experiencing this problem at all.

Thanks again,
Steve

[utidjian]

Originally posted by GeeYouEye:
The problem is with ssh. KeepAlive is currently broken in every current version ssh implementation except, of all things, PuTTY on Windows.

That can't be accurate. I have ssh sessions to/from Linux and to/from Mac OS X and between Linux and Mac OS X stay up for days... even weeks. This is with stock up-to-date versions of ssh.

[doxx]

The Airport extreme has a sessions table for NAT, this table has a very short timeout value. When your SSH session stays stale for a while the NAT entry goes away and kills your SSH session.

Screen is just a crutch because you have to continously log back in, you should be able to let the session sit for days without any keepalive or any special config.

Apple needs to allow people to adjust the timeout value for TCP sessions in the Airport extreme.

I'm usually very happy with Apple's products, but the Airport extreme's lack of configuration options is really upsetting me and for someone that lives on lots of SSH sessions, this is a show stopping "feature" that may cause me to swtich back to a Linksys WAP.

Does anyone know how to adjust the NAT timeout's on the Extreme?

-Barrett

[WJMoore]

I had this same problem when SSHing to my server that runs off my ADSL connection. I added ClientAliveInterval 60 to the sshd_config file (in /etc/ssh in Debian) and this fixed the problem. Not sure if that is of any help to you or not though.