Re: Hangs on password queries once SSH session is up

[Pierre Lewis <leware@xxxxxxxxxxxxxxxx>]

> Could you try the latest version? Checkout the git repository or use

The latest version fails much earlier, during the setup, I'll need
to first make sure it isn't some form of finger trouble.

It hangs at the following point (bt order):

(two more stack frames in Windows DLLs)
0041d134 t _ssh_socket_unbuffered_read
0041d2be T _ssh_socket_completeread
0041d734 T _ssh_socket_wait_for_data
0041edd8 t _packet_read2
0041fcb8 t _packet_wait2
0041fff7 T _packet_wait
0040e42b t _channel_request
0040e7bf T _channel_request_pty_size
004013bb T _setupSsh               (in my client

> > > -call the ssh_options_set() function with the verbosity level set to the
> > > highest level (which dumps a call trace) and attach the output in your
> > > mail

With the above problem under 0.4.4.90, I see nothing in the
trace. When my program starts, I have no stderr (it's a Windows
program). So I set up a stderr to file, but it contains nothing.
I'll try opening /dev/tty, maybe I'll see more. Or maybe I should
disable line buffering.

> > > -compiling your application with full debugging symbols, running your
> > > program in gdb, then ^C it when the problem happens, then dump a C/P of
> > > the result of the following command:
> > > bt
>
> Normally it helps if we have code snippets showing how you do it.

I don't have gdb from some odd reason (will have to fix that!).

Here's the code snippet, ie. how I read from the SSH session.
The socket is in blocking mode.

In the main event loop:

    case WM_TIMER:
         ...
         if (ssh & isSshReady)
            readSsh();

The readSsh() function (trimmed a bit):

   void readSsh()
   {
      int h;
      int rc;
      static char buffer[1500];
      unsigned long avail = 0;

   more:
      // does socket have anything
      rc = ioctlsocket(sockltc, FIONREAD, &avail);
      if (rc != 0)
      {
         ...
      }
      if (avail <= 0)
         return;

      // trigger reading of socket
      ssh_set_fd_toread(session);
      ssh_handle_packets(session);

          // would block here (or in next section for stderr) with 0.4.2
          while(channel && channel_is_open(channel) && channel_poll(channel,0))
          {
              h = channel_read_nonblocking(channel,buffer,sizeof(buffer),0);
              if(h==(-1))
              {
                  vt220msg("Error reading channel (ssh)");
   error:
                  vt220msg(ssh_get_error(session));

                  ...
              }
              if(h==0)
              {
                  if (channel_is_eof(channel))
                  {
                     vt220msg("Disconnect received (ssh)");
                     disconnect2host();
                     return;
                  }
                  break;
              }
              else
              {
                  // process received data (thru vt220 emulation)
                  vt220(buffer, h);
              }
          }

          while(channel && channel_is_open(channel) && channel_poll(channel,1))
          {
              h = channel_read_nonblocking(channel,buffer,sizeof(buffer),1);
              if(h==(-1))
              {
                  vt220msg("Error reading channel (ssh - stderr)");
                  goto error;
              }
              if(h==0)
              {
                  if (channel_is_eof(channel))
                  {
                     vt220msg("Disconnect received (ssh)");
                     disconnect2host();
                     return;
                  }
                  break;
              }
              else
              {
                  // process received data (thru vt220 emulation)
                  vt220(buffer, h);
              }
          }
      goto more;
   }

The above reminds me of something else which surprised me with SSH:
the fact that stdout and stderr seem to be kept separate over the
protocol. So one of the first thing I tried was a small program that
sent bytes alternating between the two. This worked. But perhaps this
has something to do with my problem nonetheless.

Thanks,
Pierre