FTP client

There are several things in modinit that do not (and should not) depend on a disk being present (let alone an EXT2/3 disk)
e.g. Skyplayer cleanup which I did manually yesterday (and wondered at the time why it hadn't been done - now it becomes clear).

Perhaps there ought to be a "modinit -boot" mode kicked off by a script in /etc/init.d which does all this non-disk related stuff.

I've still been meaning to find time to look at the 2GB bug with ftp, but it's not very nice of it to crash on this missing file.
 
prpr said:
Perhaps there ought to be a "modinit -boot" mode kicked off by a script in /etc/init.d which does all this non-disk related stuff.
Click to expand...
That would make sense, although a disk is required to use the custom firmware as intended and nobody would be able to install the FTP client without one unless they did it by hand like you.
 
Last edited:
I've updated the tnftp package while I was on but it looks like the crash bug is in the C library itself so I can't work around it in the tnftp code. What 2GB problem? The new package may improve things..
 
af123 said:
That would make sense, although a disk is required to use the custom firmware as intended and nobody would be able to install the FTP client without one unless they did it by hand like you.
Click to expand...
True, but I was pushing the envelope and something I expected to work didn't. FWIW, I also managed to set up the /mod environment on tmpfs and got opkg going, just to see how easy it was. Not too difficult, but you soon run out of memory installing anything, as almost everything wants to drag in Webif. Things without dependencies work fine though.
I've updated the tnftp package while I was on but it looks like the crash bug is in the C library itself so I can't work around it in the tnftp code.
Click to expand...
Eew, nasty.
What 2GB problem? The new package may improve things..
Click to expand...
This one: https://hummy.tv/forum/threads/ftp-client-bug.5726
I haven't tested the latest client yet...
 
Looks fixed.

Code: 
ftp> send The\ Hunger\ Games_\ Catching\ Fire_20160109_2102.ts
local: The Hunger Games_ Catching Fire_20160109_2102.ts remote: The Hunger Games_ Catching Fire_20160109_2102.ts
229 Entering Extended Passive Mode (|||61375|)
150 Opening BINARY mode data connection for 'The Hunger Games_ Catching Fire_20160109_2102.ts'.
47% |****************                   |  2480 MiB    4.33 MiB/s    10:37 ETA

(unlike pasting on this forum!)

(new version has tab completion and SSL support too)
 
af123 said:
(new version has tab completion and SSL support too)
Click to expand...
That's nice, but it doesn't work because it's moaning about libncurses not being present.
You need to add it (ncurses) as a dependency!
Black Hole said:
Does this mean documentation should now be referring to tnftp instead of betaftp?
Click to expand...
No. The former is the client, the latter is the server (well betaftpd anyway).
 
af123 said:
Looks fixed.
Code: 
ftp> send The\ Hunger\ Games_\ Catching\ Fire_20160109_2102.ts
local: The Hunger Games_ Catching Fire_20160109_2102.ts remote: The Hunger Games_ Catching Fire_20160109_2102.ts
229 Entering Extended Passive Mode (|||61375|)
150 Opening BINARY mode data connection for 'The Hunger Games_ Catching Fire_20160109_2102.ts'.
47% |****************                   |  2480 MiB    4.33 MiB/s    10:37 ETA
Click to expand...
Sadly not...
Code: 
150 Opening BINARY mode data connection for 'Top Gear_20160619_1959.ts' (3104296960 bytes)
100% |*********************************************|  2118 MiB  8.26 MiB/s  --:-- ETA
Code: 
-rwxr-xr-x  1 root  root  390844 May 25 12:51 /mod/bin/tnftp
Is that the expected datestamp?

But I was using 'mget' rather than 'send'...
Yes, put/send works properly and get/recv doesn't.
I say properly, but then I noticed this at the end of the transfer (a different file to the above!) in both directions:
Code: 
-1480757248 bytes received in 04:28 (9.97 MiB/s)
 
Last edited:
With tnftp_20151004-3

Code: 
ftp> get test
local: test remote: test
229 Entering Extended Passive Mode (|||63855|)
150 Opening BINARY mode data connection for 'test' (3221225472 bytes).
100% |***********************************|  3072 MiB    7.10 MiB/s    00:00 ETA
226 Transfer complete.
3221225472 bytes received in 07:12 (7.10 MiB/s)
 
prpr said:
Yes, that works for me too. Thanks.
Was it a cross-platform problem or something Humax specific?
Click to expand...
The configure script was deciding that the platform didn't support %lld in printf() and because of that also deciding not to use strtoll() when parsing the file size sent by the server. The specific configure test doesn't work properly when cross compiling.
 
You must log in or register to reply here.
Back
Top