Linux Debian support - telnet sessions lock up

Author

telnet sessions lock up

Gary Dale

2007-05-10, 7:13 pm

I've got a problem that has just recently started (a few months ago). I
was running a Debian/Sarge server with a patched kernel to allow a pptp
connection to it. I recently upgraded the server to Debian/Etch (without
any patches, etc.) and the same problem is happening.

I'm connecting remotely from a Windows XP/Pro box using their pptp
connection and ewan (which is slightly better than the M$ telnet
client). For the last while, the session seems to lock up in a
reproducible way. Until I upgraded to Etch, I could do an apt-get update
but not an apt-get dist-upgrade! Nor could I do a ls -l /var/log. The
dist-upgrade would start then the session would lock. The ls -l would
lock immediately.

Since the upgrade, I can get further into the dist-upgrade but it is
still freezing when trying to replace /lib/modules/2.6.8-4-686 in the
kernel upgrade (I removed the old directory and it did finally complete).

I can now do an ls -l /var/log, but I can't get into some folders in a
user's roaming profile. Basically, connecting remotely is a bit of a
challenge because I never know when the session is going to freeze.
However, once I find a behaviour that triggers the freeze, that is
consistent.

To be clear, this is not related to ewan. It happens with the Windows
telnet client as well. The application is not freezing. I can still work
with ewan. I just can't do anything with the machine it is connected to.
The session on the server however does seem to have stopped. Whatever I
was doing on it hasn't completed when I reconnect - no matter how quick
the task was or how I long I leave it.

ewan and the M$ telnet client seem to think they are still connected but
it really looks like the session is gone.

Any ideas?

BTW: the reason I use Windows to connect is that this was set up so the
users could connect remotely and they all use Windows. Therefore I use
Windows also to connect so that I can ensure that everything is working.

AJackson

2007-05-11, 1:13 pm

I don't know what pptp is, so I can't help you.
But...
You really should ditch telnet. It sends passwords in clear text (and
every thing else) for any one on some net between your customer and
your server can listen in to.
You should use a ssh-client for MS Windows and install ssh-server on
you server. It's secure, which telnet is not. There are lots of ssh
clients for MS Windows to choose from.

What does you logs say? Anything relevant there?
How about your set up? Backup on user data I suppose, but what about
reinstalling to get out of this interupted installation?

Have you read the information how to upgrade to Etch from Sarge?
There is some issues about kernels and udev/hotswap that needs to be
solved in right order.

Good luck

Gary Dale

2007-05-11, 7:14 pm

AJackson wrote:
> I don't know what pptp is, so I can't help you.
> But...
> You really should ditch telnet. It sends passwords in clear text (and
> every thing else) for any one on some net between your customer and
> your server can listen in to.
> You should use a ssh-client for MS Windows and install ssh-server on
> you server. It's secure, which telnet is not. There are lots of ssh
> clients for MS Windows to choose from.

Yes, but pptp also creates an encrypted tunnel. Being an M$ protocol, it
probably could use some work, but I'm not the only, or even the major, user.

>
> What does you logs say? Anything relevant there?

Good point. Earlier on I couldn't get to the logs. Now it looks like I
can. I didn't check that until I started posting the message after I
discovered that the upgrade didn't cure the problem.

> How about your set up? Backup on user data I suppose, but what about
> reinstalling to get out of this interupted installation?

Yes, I have to do a dpkg command to fix things to get the next upgrade
or install to work. So far the dist-upgrade problem looks to be less
severe than in the pre-upgrade case.

>
> Have you read the information how to upgrade to Etch from Sarge?
> There is some issues about kernels and udev/hotswap that needs to be
> solved in right order.

The upgrade went quite smoothly. Last year there were some big issues
but the developers seem to have worked them out.

Gary Dale

2007-05-12, 1:13 am

OK, some further digging:

I can't ls -l /var/log but I can ls /var/log. I can tail syslog but not
give it anything other than the default lines. Neither messages nor
syslog shows anything unusual.

man tail worked with M$ telnet client but not with ewan.

Mumia W.

2007-05-12, 1:13 am

On 05/10/2007 02:16 PM, Gary Dale wrote:
> I've got a problem that has just recently started (a few months ago). I
> was running a Debian/Sarge server with a patched kernel to allow a pptp
> connection to it. I recently upgraded the server to Debian/Etch (without
> any patches, etc.) and the same problem is happening.
>
> I'm connecting remotely from a Windows XP/Pro box using their pptp
> connection and ewan (which is slightly better than the M$ telnet
> client). For the last while, the session seems to lock up in a
> reproducible way. Until I upgraded to Etch, I could do an apt-get update
> but not an apt-get dist-upgrade! Nor could I do a ls -l /var/log. The
> dist-upgrade would start then the session would lock. The ls -l would
> lock immediately.
>
> Since the upgrade, I can get further into the dist-upgrade but it is
> still freezing when trying to replace /lib/modules/2.6.8-4-686 in the
> kernel upgrade (I removed the old directory and it did finally complete).
>
> I can now do an ls -l /var/log, but I can't get into some folders in a
> user's roaming profile. Basically, connecting remotely is a bit of a
> challenge because I never know when the session is going to freeze.
> However, once I find a behaviour that triggers the freeze, that is
> consistent.
>
> To be clear, this is not related to ewan. It happens with the Windows
> telnet client as well. The application is not freezing. I can still work
> with ewan. I just can't do anything with the machine it is connected to.
> The session on the server however does seem to have stopped. Whatever I
> was doing on it hasn't completed when I reconnect - no matter how quick
> the task was or how I long I leave it.
>
> ewan and the M$ telnet client seem to think they are still connected but
> it really looks like the session is gone.
>
> Any ideas?
>
> BTW: the reason I use Windows to connect is that this was set up so the
> users could connect remotely and they all use Windows. Therefore I use
> Windows also to connect so that I can ensure that everything is working.

The Linux version of telnet has an option (-8) to specify eight-bit
cleanness. Perhaps the Windows telnet utilities have something similar.

I'm thinking that some data flowing over the connection gets interpreted
as Control-S or something similar, and that suspends activity. The
Windows equivalent of the -8 option might fix it.

How much flexibility do you have to troubleshoot this (rhetorical)? When
you troubleshoot, you change as many things as you can in order to find
out where the problem is. So you might use a different computer, change
every connection configuration option you are able to modify, exchange
the cables, raise and lower bandwidth-capping limits, connect to
different servers, and experiment with different protocols (just to see
if the problem exists with them also).

Gary Dale

2007-05-12, 7:13 pm

> The Linux version of telnet has an option (-8) to specify eight-bit
> cleanness. Perhaps the Windows telnet utilities have something similar.
>
> I'm thinking that some data flowing over the connection gets interpreted
> as Control-S or something similar, and that suspends activity. The
> Windows equivalent of the -8 option might fix it.
>
> How much flexibility do you have to troubleshoot this (rhetorical)? When
> you troubleshoot, you change as many things as you can in order to find
> out where the problem is. So you might use a different computer, change
> every connection configuration option you are able to modify, exchange
> the cables, raise and lower bandwidth-capping limits, connect to
> different servers, and experiment with different protocols (just to see
> if the problem exists with them also).
>

All that I can see with both ewan and M$ telnet is an option to strip
the 8th bit. That doesn't help. Different terminal emulations also don't
help.

re. Ctrl-S: it does look like that. In fact, if I hit ^S, I get the same
symptom except that ^Q releases the output. When I do ls -l /var/log,
^Q, ^S or anything else I throw at it has no impact.

re. flexibility: I just have the one server I can connect to remotely.
The office is too far for me to easily try a different machine down
there. Because the problems are reproducible, it doesn't sound like
hardware or bandwidth - even if pptp gave you options to set.

Gary Dale

2007-05-24, 1:14 am

> The Linux version of telnet has an option (-8) to specify eight-bit
> cleanness. Perhaps the Windows telnet utilities have something similar.
>
> I'm thinking that some data flowing over the connection gets interpreted
> as Control-S or something similar, and that suspends activity. The
> Windows equivalent of the -8 option might fix it.
>
> How much flexibility do you have to troubleshoot this (rhetorical)? When
> you troubleshoot, you change as many things as you can in order to find
> out where the problem is. So you might use a different computer, change
> every connection configuration option you are able to modify, exchange
> the cables, raise and lower bandwidth-capping limits, connect to
> different servers, and experiment with different protocols (just to see
> if the problem exists with them also).
>

I did manage to work with a local telnet connection (from a Windows
computer through a network switch to the server) and things worked OK.
However, when I try to connect through a PPTP connection, I get the
problems.

I'm pretty sure that the sessions are actually stopping because whatever
work I was doing at the time doesn't complete.

Mumia W.

2007-05-24, 1:14 am

On 05/23/2007 09:31 PM, Gary Dale wrote:
> Mumia W. wrote:
>
> I did manage to work with a local telnet connection (from a Windows
> computer through a network switch to the server) and things worked OK.
> However, when I try to connect through a PPTP connection, I get the
> problems.
>
> I'm pretty sure that the sessions are actually stopping because whatever
> work I was doing at the time doesn't complete.

I'm out of ideas except for these:

Check that both sides of connection support the same PPTP version.

If you're using pppd to accept PPTP connections, investigate the
asyncmap option (asyncmap FFFFFFFF); read "man pppd" before you use this.

Search online for bugs relating to pppd and the Linux kernel's PPTP module.

Good luck.