Dropbear 0.50 scp problem. Most probably related to uclibc

[Rob Landley]

On Friday 08 February 2008 08:44:36 Jacques Verryn wrote:
> On Feb 5, 2008 11:49 PM, Rob Landley <rob at landley.net> wrote:
> > On Tuesday 05 February 2008 10:13:13 Jacques Verryn wrote:
> > > The crux of the problem is if I scp a file from my desktop linux pc to
> > the
> > > gumstix, the resulting file on the gumstix has zero file length.
> > > The common denominator in the above posts and in my case, is uclibc.
> > > I upgraded from dropbear 0.48.1 to 0.50 due the the scp hang error that
...
> [pid  6696] ftruncate64(3, 51539607552) = 0
> [pid  6696] close(3)                    = 0
> [pid  6696] read(0, "\0", 1)            = 1
> [pid  6696] write(1, "\0", 1 <unfinished ...>
> </---trace snip ---->
>
> The size parameter of the ftruncate64 call is WAY wrong!

That's certainly a bug, but how would it produce a 0 length file?  (Especially 
since the truncate call isn't returning an error...)

> <code>
>         if (count != 0 && wrerr == NO &&
>             atomicio(vwrite, ofd, bp->buf, count) != count) {
>             wrerr = YES;
>             wrerrno = errno;
>         }
>
>         if (wrerr == NO && ftruncate(ofd, size) != 0) {
>              run_err("%s: truncate: %s", np, strerror(errno));
>              wrerr = DISPLAYED;
>         }
> </code>
> This code has not change in a while. I also verified the 'size' has the
> correct value just before the ftruncate.

Why is uClibc calling ftruncate64() for this on gumstix?  Is that a 64 bit 
processor, or does it have large file support?  This sounds like a uClibc 
issue.  What version of uClibc are you using?

In any case, uClibc should be casting size to uint64_t inside the call to 
ftruncate.  Sounds like a mismatch between the prototype and the actual 
syscall...

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.