thr3ads.net - openssh unix dev - Strange behaviour with ptmx file descriptors [Apr 2016]

If this information is useful, please help other people find it:
Share via:

Nacho del Rey

2016-Apr-15 09:28 UTC

Strange behaviour with ptmx file descriptors

Hi Angel and many thanks for your answer

The application still sending & receiving data
  .- strace over the application:

write(1, "\33[1;1H\237#SF                                 \234", 44) =
44
<--it was sent from the application to the terminal, but ssh didn't
received this string
read(0, "\10", 1024) = 1           <- the client remained sending
data and
it was received by the application
read(0, "\n", 1024) = 1
write(1, "\33[6;6H", 6) = 6         <-- the answered '\n'
but it wasn't
received by the ssh

finally, several minutes later, the operator realized the screen is frozen
and he closed the ssh client

The strange thing is all file descriptors of all processes are in place but
it seems for any strange reason, something happen to fd#13 ( C Program fd
#1 --> ssd read fd #13) because it disappears from the select call (it
won't be available in the read fd set ever)

ssh client is made by Honeywell company.

This behaviour is similar as when you send a Ctrl+S from the ssh client but
in this case, fd#13 is not lost.

Kind regards

Nacho.





2016-04-15 2:06 GMT+02:00 ?ngel Gonz?lez <keisial at gmail.com>:
> Hello Nacho
>
> El 04/04/16 15:38, Nacho del Rey escribi?:
>
>> Hi list
>>
> (?)
>
>> Transmission KO
>>
>> read(13, "\7\33[1;16H \33[6;6H_______\33[7;1H -INFORME CANT.
>> RECOGIDA-\33[7;26H", 16384) = 67
>>
>> write(3,
>>
>>
"P\247\244}\277\322\260\21\3314\7\227\223~\317\360\35\334\232\372\237\250\320\312\1;\25\37\23\363\363O&0\355i{zUbr\365,\362yyl\222",
>> 48) = 48
>>
>> It seems the file descriptor disappears while the system call (read) is
>> reading from it?
>>
> No, the file descriptor will still be there.
>
> sshd is taking the program output from the terminal (13) and sending out
> through the socket
> (3). What's the corresponding strace of the client ssh?
>
>
> I ran out of ideas. Can anybody drive me to the right direction?
>>
>> Regards, Nacho.
>>
> What's the terminal emulator used in the client side? Does resetting it
> (from a menu option) make it receive the server output again?
>
>
> Cheers
>
>

Ángel González

2016-Apr-15 21:53 UTC

head link

Strange behaviour with ptmx file descriptors

El 15/04/16 11:28, Nacho del Rey escribi?:> Hi Angel and many thanks for your answer
>
> The application still sending & receiving data
>   .- strace over the application:I asked for the corresponding strace of the client ssh, where the data 
should have been received and printed to the console.
> The strange thing is all file descriptors of all processes are in 
> place but it seems for any strange reason, something happen to fd#13 ( 
> C Program fd #1 --> ssd read fd #13) because it disappears from the 
> select call (it won't be available in the read fd set ever)Interesting. I wonder if that's expected and sshd waits for 
acknowledgment from the remote ssh before reading again.


Also, seems you missed this suggestion:>
>     What's the terminal emulator used in the client side? Does
>     resetting it (from a menu option) make it receive the server
>     output again?
>
>     Cheers
>
Best regards

Nacho del Rey

2016-Apr-16 09:11 UTC

head link

Strange behaviour with ptmx file descriptors

Hi again

I think I didn't explain the problem properly

I'll try to explain it using an example of what it happened last time in
Feb, the 23th

This is the point of view of the C application, running in the linux box,
when answering to the client:

4911  1456244042.324336 write(1, "\7", 1) = 1
4911  1456244042.324610 write(1, "\33[1;16H        \33[6;6H_______\33[7;1H
-INFORME CANT. RECOGIDA-\33[7;26H", 66) = 66

This is the point of view of the ssh process in the linux box:

6647  1456244042.323463 select(14, [3 9 13], [], NULL, {900, 0}) = 1 (in
[13], left {899, 998569})
6647  1456244042.324971 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8)  = 0
6647  1456244042.325010 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
6647  1456244042.325033 read(13, "\7\33[1;16H
\33[6;6H_______\33[7;1H -INFORME CANT. RECOGIDA-\33[7;26H", 16384) = 67
6647  1456244042.325126 select(14, [3 9], [3], NULL, {900, 0}) = 1 (out
[3], left {899, 999998})
6647  1456244042.325203 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8)  = 0
6647  1456244042.325240 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
6647  1456244042.325264 write(3,
"P\247\244}\277\322\260\21\3314\7\227\223~\317\360\35\334\232\372\237\250\320\312\1;\25\37\23\363\363O&0\355i{zUbr\365,\362yyl\222",
48) = 48
6647  1456244042.325310 select(14, [3 9], [], NULL, {900, 0}) = 1 (in [3],
left {892, 12016})       <<-- where id fd#13 ?


This is the point of view of the ssh client:

  74539.285          0BE6003A            I-ITE       38:VT220_IO:
tohost:0x31='1'

  74539.300          0BE6003A            I-ITE       52:ANSITERM:
charin:<ASCII(27)>

  74539.300          0BE6003A            I-ITE       53:ANSITERM:
charin:<[>

  74539.300          0BE6003A            I-ITE       54:ANSITERM:
charin:<1>

  74539.300          0BE6003A            I-ITE       55:ANSITERM:
charin:<;>

  74539.300          0BE6003A            I-ITE       56:ANSITERM:
charin:<2>

  74539.300          0BE6003A            I-ITE       57:ANSITERM:
charin:<3>

  74539.300          0BE6003A            I-ITE       58:ANSITERM:
charin:<H>

  74539.301          0BE6003A            I-ITE       59:ANSITERM:
charin:<1>

  74539.301          0BE6003A            I-ITE       63:ANSITERM:
charin:<ASCII(27)>

  74539.301          0BE6003A            I-ITE       64:ANSITERM:
charin:<[>

  74539.301          0BE6003A            I-ITE       65:ANSITERM:
charin:<1>

  74539.301          0BE6003A            I-ITE       66:ANSITERM:
charin:<;>

  74539.302          0BE6003A            I-ITE       67:ANSITERM:
charin:<2>

  74539.302          0BE6003A            I-ITE       68:ANSITERM:
charin:<4>

  74539.302          0BE6003A            I-ITE       69:ANSITERM:
charin:<H>

  74539.302          0BE6003A            I-ITE       70:ANSITERM:
charin:<ASCII(7)>

  74539.346          0BE6003A            I-ITE       71:ANSITERM:
        charin:<ASCII(27)>

  74539.347          0BE6003A            I-ITE       72:ANSITERM:
charin:<[>

  74539.347          0BE6003A            I-ITE       73:ANSITERM:
charin:<1>

  74539.347          0BE6003A            I-ITE       74:ANSITERM:
charin:<;>

  74539.347          0BE6003A            I-ITE       75:ANSITERM:
charin:<1>

  74539.347          0BE6003A            I-ITE       76:ANSITERM:
charin:<6>

  74539.347          0BE6003A            I-ITE       77:ANSITERM:
charin:<H>

  74539.347          0BE6003A            I-ITE       78:ANSITERM:
charin:< >

  74539.348          0BE6003A            I-ITE       82:ANSITERM:
charin:< >

  74539.348          0BE6003A            I-ITE       86:ANSITERM:
charin:< >

  74547.277          0BE6003A            I-ITE       97:VT220_IO:
tohost:0x08='.'            <-- here the client stops receiving data

  74547.779          0BE6003A            I-ITE       08:VT220_IO:
tohost:0x08='.'

  74547.821          0BE6003A            I-ITE       19:VT220_IO:
tohost:0x08='.'

  74547.864          0BE6003A            I-ITE       30:VT220_IO:
tohost:0x08='.'

  74547.907          0BE6003A            I-ITE       41:VT220_IO:
tohost:0x08='.'

  74547.950          0BE6003A            I-ITE       52:VT220_IO:
tohost:0x08='.'

  74547.993          0BE6003A            I-ITE       63:VT220_IO:
tohost:0x08='.'

  74548.036          0BE6003A            I-ITE       74:VT220_IO:
tohost:0x08='.'

And when it happens, the ssh client still working properly, it continues
sending keystrokes to the the application, the application receives these
keystrokes, it answers to the client, but the answer is not yet received by
the sshd process (so it seems the application is frozen... when it is not
?true?)

One time, the operator tried to reset the connection from the ssh client,
but no way

The C program works properly thru telnet.. no incident has been reported
ever

I hope this information helps

Many thanks

Regards

Nacho.



2016-04-15 23:53 GMT+02:00 ?ngel Gonz?lez <keisial at gmail.com>:
> El 15/04/16 11:28, Nacho del Rey escribi?:
>
> Hi Angel and many thanks for your answer
>
> The application still sending & receiving data
>   .- strace over the application:
>
> I asked for the corresponding strace of the client ssh, where the data
> should have been received and printed to the console.
>
> The strange thing is all file descriptors of all processes are in place
> but it seems for any strange reason, something happen to fd#13 ( C Program
> fd #1 --> ssd read fd #13) because it disappears from the select call
(it
> won't be available in the read fd set ever)
>
> Interesting. I wonder if that's expected and sshd waits for
acknowledgment
> from the remote ssh before reading again.
>
>
> Also, seems you missed this suggestion:
>
> What's the terminal emulator used in the client side? Does resetting it
>> (from a menu option) make it receive the server output again?
>>
>> Cheers
>>
>
> Best regards
>
>

openssh unix dev - Apr 2016 - Strange behaviour with ptmx file descriptors

Strange behaviour with ptmx file descriptors

Strange behaviour with ptmx file descriptors

Strange behaviour with ptmx file descriptors