On Fri, Aug 01, 2014 at 06:10:46AM -0400, Mike Frysinger wrote:
fwiw, glibc-2.19 has moved clock_gettime to libc
Ah, good to know. At some point I'll add a test for
clock_gettime() in configure, though want a bit more testing
first.
Cheers,
Matt
On Mon 28 Jul 2014 19:32:04 Matt Johnston wrote:
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.
I plan to release 2013.65 early next week to fix those regressions. If anyone
has seen other problems please let me know.
Cheers,
Matt
On 27 July 2014 11:41:56 pm AWST, Matt Johnston m...@ucc.asn.au wrote:
Hi all,
Dropbear 2014.64 is released with changes as follows.
As usual get it from
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
Matt Johnston matt at 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
And the latest one fixed the scp hangs, thanks!
Hello, I was having a bit of a problem with the new monotonic_call() stuff
on some old systems (again, a Kindle 2 w/ a fairly old glibc kernel duo),
so, inspired from what's done in OpenSSH, I tweaked it to do runtime checks
w/ clock_gettime (and not the syscall, which really didn't play nice for
And a minor buildsystem tweak that I completely forgot to submit when
2014.63 came out, which broke building against external libtom* with recent
binutils versions (again ;)).
diff -Nuarp dropbear-2014.63-ori/configure.ac dropbear-2014.63/configure.ac
--- dropbear-2014.63-ori/configure.ac
Might have spoken too soon...
Not sure if it's related, but scp transfers hang @ 100% without closing the
connection if there's no other traffic to the remote box.
If I have another shell open, it works properly.
:?
NiLuJe ninuje at gmail.com writes:
Might have spoken too soon...
Not sure if it's related, but scp transfers hang at 100% without
closing the
connection if there's no other traffic to the remote box.
If I have another shell open, it works properly.
:?
Hmm, make that a decent
NiLuJe ninuje at gmail.com writes:
Might have spoken too soon...
Not sure if it's related, but scp transfers hang at 100% without
closing the
connection if there's no other traffic to the remote box.
If I have another shell open, it works properly.
:?
And, of course, I can't
Oops, I mangled my copy/paste. Sigh.
Here it is again.
TRACE (6695) 1406502069.738124: empty queue dequeing
TRACE (6695) 1406502069.739377: process_packet: packet type = 96, len 5
TRACE (6695) 1406502069.739452: enter recv_msg_channel_eof
TRACE (6695) 1406502069.739491:
NiLuJe ninuje at gmail.com writes:
NiLuJe ninuje at gmail.com writes:
Might have spoken too soon...
Not sure if it's related, but scp transfers hang at 100% without
closing the
connection if there's no other traffic to the remote box.
If I have another shell open, it works
Yup, building master w/ ca86726 reverted does the trick on the machine where
I'm experiencing this issue...
14 matches
Mail list logo
