Bug 109 - sftp hangs when a tcsh user types quit or exit
Summary: sftp hangs when a tcsh user types quit or exit
Status: CLOSED WORKSFORME
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sftp (show other bugs)
Version: -current
Hardware: Other Other
: P2 normal
Assignee: OpenSSH Bugzilla mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-02-12 08:11 AEDT by Andrew Bogecho
Modified: 2004-04-14 12:24 AEST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Bogecho 2002-02-12 08:11:25 AEDT
When using sftp I found that when quiting the application, it would hang. It
exits when one does a ^C. I checked my .cshrc to make sure that ignoreeof was
not set or anything else that could be preventing me from exiting. I did the
test recommended for sftp/scp in the FAQ, that works at it should. I then asked
a co-worker to try and he had no problems. The difference between our 2 accounts
was that I use tcsh and he uses bash. I then set my shell to bash, and quit
worked without any problems.

Below is the output from running sftp in verbose mode:

sftp> version
SFTP protocol version 3
sftp> quit
debug1: channel 0: read<=0 rfd 4 len 0
debug1: channel 0: read failed
debug1: channel 0: input open -> drain
debug1: channel 0: close_read
debug1: channel 0: input: no drain shortcut
debug1: channel 0: ibuf empty
debug1: channel 0: input drain -> closed
debug1: channel 0: send eof
debug1: channel 0: rcvd eof
debug1: channel 0: output open -> drain
debug1: channel 0: obuf empty
debug1: channel 0: output drain -> closed
debug1: channel 0: close_write
debug1: channel 0: send close
debug2: channel 0: no data after CLOSE
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: rcvd close
debug2: channel 0: no data after CLOSE
debug1: channel 0: is dead
debug1: channel_free: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i8/0 o128/0 fd -1/-1)

debug1: channel_free: channel 0: dettaching channel user


Killed by signal 2.
debug1: Calling cleanup 0x805a760(0x0)
debug1: Calling cleanup 0x8063370(0x0)

I also downloaded and tried the snapshot of : openssh-SNAP-20020211.tar.gz
That had the same problem.

If any of you need more information please let me know.

Andrew.
Comment 1 Andrew Bogecho 2002-02-12 08:16:49 AEDT
Silly me I forgot to mentiont the version of Solaris that we are
running.

SunOS 5.7 Generic_106541-14 sun4u sparc SUNW,Ultra-25

Sorry about that.

Andrew.
Comment 2 Kevin Steves 2002-03-31 05:06:23 AEST
i'm not sure.  can someone dup and debug this?

can you still dup with 3.1p1?
Comment 3 Brian Poole 2002-03-31 14:23:12 AEST
I've been unable to dup this problem, client quits immediately in all tests. 
Tested configurations below.

Client SSH versions
 - 2.9.9p2
 - 3.0.2p1
 - 3.1p1
Server SSH versions
 - 3.0.2p1
 - 3.1p1
tcsh versions
 - tcsh 6.10.00 (Astron) 2000-11-19 (sparc-sun-solaris) options 
8b,nls,dl,al,rh,color
 - tcsh 6.11.00 (Astron) 2001-09-02 (sparc-sun-solaris) options 
8b,nls,dl,al,rh,color
Solaris 7, latest kernel
 - SunOS basm 5.7 Generic_106541-19 sun4u sparc SUNW,Ultra-Enterprise
Comment 4 Andrew Bogecho 2002-04-01 00:03:29 AEST
It happened with:
Client @ : OpenSSH_2.9p2 (Shell tcsh on both sides)
Server @ : OpenSSH_3.0.2p1 (Solaris 7)

As soon as client was upgraded or downgraded this problem stopped.

Thank you all for your time. There are no problems connecting to a
OpenSSH_3.1p1 server.
Comment 5 Kevin Steves 2002-04-02 07:10:41 AEST
thanks; closing
Comment 6 Damien Miller 2004-04-14 12:24:17 AEST
Mass change of RESOLVED bugs to CLOSED