ftp client can't see files served by ftpd

[Kev]

On hrev46164:

/> ftpd
/> ftp localhost
Trying ::1...
ftp: connect to address ::1: Connection refused
Trying 127.0.0.1...
ftp: connect: Connection refused
ftp> 

Doesn't stay running. ftpd --help doesn't say anything.

Sorry, I'm not sure which component this belongs in.

[augiedoggie]

If you want to run ftpd as a daemon then you need to use 'ftpd -D' otherwise it'll act more like an inetd server. See the /boot/system/settings/network/services file

[Kev]

Oh...maybe that could be output if you try ftpd --help or ftpd -? ? I tried -D and it does work, thanks!

[Kev]

Although, once running, I can ftp in and upload a file, and then Tracker's "Find" cannot find it, even if I e.g. "cd /boot/home" first. Where did it go? And why doesn't it fail?

[augiedoggie]

it works fine for me, i can upload a file and see it in my homedir and via a Find

[anevilyak]

Works here as well. For reference by the way, the R1/Package Management version was mainly intended to track tickets specific to PM while that was still a separate branch. As that's no longer the case, R1/Development should be used for new tickets at this point.

[Kev]

Thanks anevilyak for the note, I wasn't aware & will do.

However I don't think all is well with ftpd. After launching ftpd -D, I can "put" a file and then "ls" doesn't see it. Isn't this a bug? (Or fixed since hrev46164?) C.f.:

Welcome to the Haiku shell.

/> ftp localhost
Trying ::1...
Connected to localhost.
220 shredder FTP server (Version 6.00LS) ready.
Name (localhost:user): 
331 Password required for user.
Password:
230 User user logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> lcd
Local directory now: /boot/home
ftp> put listdev.txt testing.txt
local: listdev.txt remote: testing.txt
ftp> ls
ftp> quit
221 Goodbye.
/> 

[anevilyak]

The way you're using it isn't really supported, since your ftp client and server are both pointing to the same folder on the same disk, and as such you're trying to overwrite the same file that you're reading from.

[Kev]

That's not exactly true (although I've also tried cd'ing to other folders; and why doesn't ls show anything else?): my put command tells it to write a different file name remotely.

[Kev]

See below.

Welcome to the Haiku shell.

/> ftpd -D
/> ftp localhost
Trying ::1...
Connected to localhost.
220 shredder FTP server (Version 6.00LS) ready.
Name (localhost:user): 
331 Password required for user.
Password:
230 User user logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd Desktop
250 CWD command successful.
ftp> put listdev.txt test.txt
local: listdev.txt remote: test.txt
ftp: local: listdev.txt: No such file or directory
ftp> lcd
Local directory now: /boot/home
ftp> put listdev.txt test.txt
local: listdev.txt remote: test.txt
ftp> ls
ftp> quit
221 Goodbye.
/>

(and it didn't show up on the Desktop)

[anevilyak]

Replying to Kev:

That's not exactly true (although I've also tried cd'ing to other folders; and why doesn't ls show anything else?): my put command tells it to write a different file name remotely.

Sorry, misread last night. The ftp client I typically use treats put as equivalent to mput so I'd interpreted it the same. In any case though, a normal put with a single parameter definitely worked correctly here. Can you verify that this behavior is only observed when trying to put to an alternate name?

[Kev]

That's OK.

It does seem to switch dirs remotely correctly, because if I cd to one that doesn't exist, it complains. However, it still will not put the file there:

Welcome to the Haiku shell.

/> ftpd -D
/> ftp
ftp> quit
/> ftp localhost
Trying ::1...
Connected to localhost.
220 shredder FTP server (Version 6.00LS) ready.
Name (localhost:user): 
331 Password required for user.
Password:
230 User user logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> lcd
Local directory now: /boot/home
ftp> cd /boot/home/Desktop
250 CWD command successful.
ftp> cd /boot/home/Desktop2
550 /boot/home/Desktop2: No such file or directory.
ftp> cd /boot/home/Desktop
250 CWD command successful.
ftp> put listdev.txt
local: listdev.txt remote: listdev.txt
ftp> ls
ftp> quit
221 Goodbye.
/> 

[axeld]

Could you do an 'ls' before the put? It's quite strange that it never shows anything -- those directories just aren't empty.

[korli]

It would also be a good idea to test the ftp server with another OS FTP client et vice versa, to better identify where the problem is, client vs server.

[Kev]

axeld, I've yet to see ls or dir output anything whenever I've tried.

Ah, thanks anevilyak, that's the category I was looking for.

If I login from a Windows 7 ftp.exe, ls output looks normal. So I guess it's the ftp client, not the server--good call, korli.

[Kev]

Same behaviour on hrev46198.

[anevilyak]

I tried to reproduce this and I simply can't, even with Haiku's built-in ftp client. The file shows up as expected with its alternate name, its md5 matches the original file, and I can't replicate the empty directory listing behavior at all no matter what I try. Without further information as to what the difference between our two systems might be that'd cause this behavior, I'm afraid I'm completely at a loss and have pretty much no way to attempt to debug this.

[Kev]

Huh.

First are we on the same gcc? I used ​http://www.haiku-files.org/haiku/development/haiku-nightly-hrev46198-x86gcc2hybrid-raw.tar.xz to install.

[anevilyak]

I've tried both compilers, it makes no difference over here.

[Kev]

On hrev46295, I do

ftpd -D
ftp localhost
cd setup
ls

...and I see no files, even though there are files in ~/setup.

[dsuden]

I don't know if this is directly related, but if I attempt to use an FTP client such as FTP Positive or FireFTP to connect to my other Haiku computer, it connects without errors, but no files are listed.

Note:

If I use either of those clients to instead connect to an Internet FTP server, they do fine. If I use Filezilla on my Mac to connect to the Haiku computer, that works fine (files are listed, etc.)

So it seems to be something specifically odd about attempts to connect via FTP from Haiku-to-Haiku.

[Kev]

On hrev46362, I launch ftpd -D, then go to a Win7 machine and connect to Haiku. If I use Explorer or Internet Explorer, both show all the folders with a prefix like '22:15 '. Whether I click them to go into them with the prefix, or manually take out the prefix, the ftp client complains it can't connect.

Interestingly, Explorer connects me to /home, whereas Internet Explorer connects me to /, for the same address (​ftp://user@myipaddress/).

BTW these and the command-line FTP client on Win7 have Haiku (out of the box, without having run passwd) accept 'user' as the user and apparently any password (tried blank and 'hello'). Maybe I should make a separate ticket for that?

[anevilyak]

(In #10235) Duplicate of #10074.

[kp3ft]

Not sure if the following will help or not in tracking down the problem...

So far, I connecting two Haiku machines (hrev46033 as host, hrev45164 as remote), and tried FTP Positive, Get-It, NetPenguin, and command-line from Terminal. They all connect but have the same peculiarity of either not displaying the remote files at all, displaying only a partial listing, and/or displaying odd characters for file names. Connecting to a remote BeOS Pro 5.03 machine from the hrrev46033 machine works perfectly... all three GUI clients displayed the BeOS files correctly, and file transfers worked. Reversing it with BeOS 5.03 Pro as local and Haiku as remote, the same problem with no remote files displayed occurs. The Haiku remote files list properly when the host ftp client is running on Linux or Windows.

For NetPenguin, replacing the EXRTranslator asmentioned above only kept it from crashing (also had to replace liblayout.so with an older version), but it still doesn't display remote files. It does display some when manually typing a new path, but it's always a small partial list and only for some folders.

[pulkomandy]

Ok, from a quick test:

ftpd -D
ftp 127.0.0.1
ls
quit
ftp localhost
ls
quit

First try works fine. Second try connects to ::1 using ipv6 and fails listing anything.

I guess the problem is you are connected to these websites using ipv6. Could you confirm that using an ipv4 IP instead of a domain name get it working?

[Kev]

Brilliant, that's it!

~> ftpd -D
~> ftp localhost
Trying ::1...
Connected to localhost.
220 shredder FTP server (Version 6.00LS) ready.
Name (localhost:user): user
331 Password required for user.
Password:
230 User user logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
ftp> quit
221 Goodbye.
~> ftp 127.0.0.1
Connected to 127.0.0.1.
220 shredder FTP server (Version 6.00LS) ready.
Name (127.0.0.1:user): user
331 Password required for user.
Password:
230 User user logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
227 Entering Passive Mode (127,0,0,1,171,60)
150 Opening ASCII mode data connection for '/bin/ls'.
total 7886
-rw------- 1 root      16 2013-12-14 07:53 .bash_history
(...the rest of my files...)
226 Transfer complete.
ftp> exit
221 Goodbye.

hrev46531.

[waddlesplash]

Does IPv6 work at all in Haiku? IIRC MUSCLE only worked if you disabled MUSCLE_AVOID_IPV6 at compile time...

[pulkomandy]

Not reproductible I guess since the switch to tnftp as the FTP client.