Matt Johnston ucc.asn.au> writes:
> Could you try with
>
https://github.com/mkj/dropbear/commit/0e7409c7ff6fc760018fce3d5e8b72247bf782b5
I answered in the wrong thread earlier, so, here it is again: yep, that
fixes it for me too, thanks ;).
And the latest one fixed the scp hangs, thanks!
On Mon, Jul 28, 2014 at 03:06:14AM +, NiLuJe wrote:
> Yup, building master w/ ca86726 reverted does the trick on the machine where
> I'm experiencing this issue...
Could you try with
https://github.com/mkj/dropbear/commit/0e7409c7ff6fc760018fce3d5e8b72247bf782b5
(the same as https://secure.u
I managed to misread the syscall manpage, so disregard the errno comment,
oops :).
Anyway, good news, the latest commits seem to have done the trick, thanks! :).
Process 7459 attached
[pid 7459] 17:28:27 [40133110] clock_gettime(0x6 /* CLOCK_??? */,
0xbed3f890) = -1 EINVAL (Invalid argumen
On Mon, Jul 28, 2014 at 01:56:43PM +, NiLuJe wrote:
> Sure ;). Basically, if CLOCK_MONOTONIC_COARSE isn't supported, it never
> falls back to CLOCK_MONOTONIC (AFAICT, that's because the only way to check
> the status of syscall() is through errno, not its return value?).
Oh, that's a bit embar
Matt Johnston ucc.asn.au> writes:
>
> Hi,
> Thanks for tracking that down, I'll see what's going on with channel closing.
> Would you be able to send a strace of the clock_gettime issue? I avoided
clock_gettime() from glibc since that pulls in librt. I'm curious how it's
failing. Dropbear should
Hi,
Thanks for tracking that down, I'll see what's going on with channel closing.
Would you be able to send a strace of the clock_gettime issue? I avoided
clock_gettime() from glibc since that pulls in librt. I'm curious how it's
failing. Dropbear should probably just check the second clock_get
