ribbons
Failed to allocate pty
The connection via ssh [email protected] failed, but the connection via ssh [email protected] "/bin/sh -i" was successful.
Failure output:
TRACE4 (3036) 16.969951: enter chansessionrequest
TRACE4 (3036) 16.970021: type is pty-req
TRACE4 (3036) 16.970114: enter sessionpty
[3036] Jan 07 15:20:37 Failed to open any /dev/pty?? devices
TRACE4 (3036) 17.002048: leave sessionpty: failed to allocate pty
TRACE4 (3036) 17.002107: enter send_msg_channel_failure
TRACE4 (3036) 17.002289: leave send_msg_channel_failure
TRACE4 (3036) 17.002338: leave chansessionrequest
TRACE4 (3036) 17.002362: leave recv_msg_channel_request
TRACE4 (3036) 17.002777: empty queue dequeing
TRACE4 (3036) 17.002991: process_packet: packet type = 98, len 20
TRACE4 (3036) 17.003042: enter recv_msg_channel_request 0xb40000729a9bbc70
TRACE4 (3036) 17.003105: enter chansessionrequest
TRACE4 (3036) 17.003172: type is shell
TRACE4 (3036) 17.003212: enter sessioncommand 0
TRACE4 (3036) 17.003304: enter ptycommand
[3036] Jan 07 15:20:37 No pty was allocated, couldn't execute
TRACE4 (3036) 17.003427: leave sessioncommand, ret -1
Success output:
TRACE4 (3039) 10.602331: enter chansessionrequest
TRACE4 (3039) 10.602404: type is exec
TRACE4 (3039) 10.602454: enter sessioncommand 0
TRACE4 (3039) 10.602581: enter noptycommand
TRACE4 (3039) 10.604777: setnonblocking: 8
TRACE4 (3041) 10.604837: TRACE4 (3039) 10.605061: back to normal sigchldleave setnonblocking
TRACE4 (3039) 10.605204: setnonblocking: 7
TRACE4 (3039) 10.605292: leave setnonblocking
TRACE4 (3039) 10.605378: setnonblocking: 10
TRACE4 (3039) 10.605459: leave setnonblocking
TRACE4 (3039) 10.605541: addchildpid 0 pid 3041 for chansess 0xb4000070462d0d90
TRACE4 (3039) 10.605611: leave noptycommand
TRACE4 (3039) 10.605649: update_channel_prio
TRACE4 (3039) 10.605739: Dropbear priority transitioning 1 -> 0
TRACE4 (3039) 10.605792: Couldn't set IPV6_TCLASS (Protocol not available)
TRACE4 (3039) 10.605906: leave sessioncommand, ret 0
Additional information:
rk3566_r:/dev # ls -l /dev/pty*
ls: /dev/pty*: No such file or directory
1|rk3566_r:/dev # ls -l /dev/pts*
total 0
crw------- 1 root root 136, 0 2025-01-07 15:19 0
c--------- 1 root root 5, 2 2025-01-07 09:34 ptmx
rk3566_r:/dev # ls -l /dev/tty*
crw-rw-rw- 1 root root 5, 0 2025-01-07 09:34 /dev/tty
crw------- 1 root root 253, 0 2025-01-07 09:34 /dev/ttyFIQ0
crw-rw-rw- 1 system system 4, 64 2025-01-07 09:34 /dev/ttyS0
crw-rw---- 1 bluetooth net_bt 4, 65 2025-01-07 09:34 /dev/ttyS1
crw-rw-rw- 1 root root 4, 67 2025-01-07 09:34 /dev/ttyS3
crw------- 1 root root 4, 69 2025-01-07 09:34 /dev/ttyS5
Is this the expected behavior in Android? （Still in Android 10）
Is this the expected behavior in Android? （Still in Android 10）
This is a bit of of an educated guess rather than definitive but with these particular builds I think that the answer is currently yes.
pty_allocate() in Dropbear's sshpty.c has a number of different implementations depending on what the platform makes available. When configure runs during these builds, the test for openpty() shows as: checking for library containing openpty... no and as the other options look like they are for supporting legacy UNIXes the fallback implementation chosen searches through existing /dev/pty?? devices to find one that is free.
As there aren't any /dev/pty devices created by default under Android, this fails with the error you're seeing.
What's good (though slightly aggravating) is getpty() is implemented in bionic for Android API level 23 and above but as these builds are targeting API level 21 it can't be used (as it's not implemented on all levels being targeted).
If I bump PLATFORM in the build script from API level 21 to 23, the configure output changes to checking for library containing openpty... none required, HAVE_OPENPTY is defined and the compile succeeds, so I strongly suspect it will magically start working when the oldest NDK version available on the Actions runners no-longer supports API level 21 and 22...
As you have found a workaround, the problem looks like it will fix itself eventually and it doesn't seem like an upstream bug I'm minded to leave this as-is, but will leave this issue open for others.
Thanks for clarifying the confusion
This should be more like a speculative discussion (sorry that it is not reflected in the title and content)
As you have found a workaround, the problem looks like it will fix itself eventually and it doesn't seem like an upstream bug I'm minded to leave this as-is, but will leave this issue open for others.
I also agree with your opinion