Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #30214 > unrolled thread

ftp problem

Back to article view | Back to comp.os.linux.misc

Contents

  ftp problem Dieter Britz <dieterhansbritz@gmail.com> - 2020-06-29 14:15 +0000
    Re: ftp problem Pascal Hambourg <pascal@plouf.fr.eu.org> - 2020-06-29 19:45 +0200
      Re: ftp problem The Natural Philosopher <tnp@invalid.invalid> - 2020-06-30 09:16 +0100
        Re: ftp problem The Natural Philosopher <tnp@invalid.invalid> - 2020-06-30 09:19 +0100
        Re: ftp problem Pascal Hambourg <pascal@plouf.fr.eu.org> - 2020-06-30 16:51 +0200
          Re: ftp problem The Natural Philosopher <tnp@invalid.invalid> - 2020-06-30 17:05 +0100
            Re: ftp problem Grant Taylor <gtaylor@tnetconsulting.net> - 2020-06-30 12:03 -0600
            Re: ftp problem "Carlos E.R." <robin_listas@es.invalid> - 2020-06-30 20:33 +0200
              Re: ftp problem Pascal Hambourg <pascal@plouf.fr.eu.org> - 2020-06-30 23:05 +0200
                Re: ftp problem Eli the Bearded <*@eli.users.panix.com> - 2020-06-30 21:14 +0000
                  Re: ftp problem "Carlos E.R." <robin_listas@es.invalid> - 2020-07-01 03:39 +0200
                    Re: ftp problem Eric Pozharski <whynot@pozharski.name> - 2020-07-02 10:46 +0300
                      Re: ftp problem "Carlos E.R." <robin_listas@es.invalid> - 2020-07-02 11:47 +0200
                        Re: ftp problem "Anonymous Remailer (austria)" <mixmaster@remailer.privacy.at> - 2020-07-02 17:03 +0200
                          Re: ftp problem "Carlos E.R." <robin_listas@es.invalid> - 2020-07-02 22:04 +0200
                            Re: ftp problem Richard Kettlewell <invalid@invalid.invalid> - 2020-07-03 09:44 +0100
                              Re: ftp problem "Carlos E.R." <robin_listas@es.invalid> - 2020-07-03 11:03 +0200
                                Re: ftp problem Pascal Hambourg <pascal@plouf.fr.eu.org> - 2020-07-03 17:08 +0200
                                  Re: ftp problem "Carlos E.R." <robin_listas@es.invalid> - 2020-07-03 20:55 +0200
                Re: ftp problem The Natural Philosopher <tnp@invalid.invalid> - 2020-07-01 07:10 +0100
                  Re: ftp problem felix@palmen-it.de (Felix Palmen) - 2020-07-01 08:19 +0200
                    Re: ftp problem The Natural Philosopher <tnp@invalid.invalid> - 2020-07-01 07:23 +0100
                      Re: ftp problem felix@palmen-it.de (Felix Palmen) - 2020-07-01 08:46 +0200
                        Re: ftp problem The Natural Philosopher <tnp@invalid.invalid> - 2020-07-01 08:14 +0100
                          Re: ftp problem felix@palmen-it.de (Felix Palmen) - 2020-07-01 09:45 +0200
                            Re: ftp problem The Natural Philosopher <tnp@invalid.invalid> - 2020-07-01 10:53 +0100
                              Re: ftp problem "Carlos E.R." <robin_listas@es.invalid> - 2020-07-01 15:00 +0200
                                Re: ftp problem The Natural Philosopher <tnp@invalid.invalid> - 2020-07-01 15:06 +0100
                                  Re: ftp problem "Carlos E.R." <robin_listas@es.invalid> - 2020-07-01 21:59 +0200
                                    Re: ftp problem Pascal Hambourg <pascal@plouf.fr.eu.org> - 2020-07-02 00:08 +0200
                                    Re: ftp problem The Natural Philosopher <tnp@invalid.invalid> - 2020-07-02 03:18 +0100
                    Re: ftp problem Eli the Bearded <*@qaz.wtf> - 2020-07-01 17:51 +0000
                      Would it? (Was: ftp problem) gazelle@shell.xmission.com (Kenny McCormack) - 2020-07-02 00:45 +0000
                        Re: Would it? (Was: ftp problem) Eli the Bearded <*@qaz.wtf> - 2020-07-02 00:49 +0000
                      Re: ftp problem The Natural Philosopher <tnp@invalid.invalid> - 2020-07-02 03:20 +0100
                        Re: ftp problem Eli the Bearded <*@qaz.wtf> - 2020-07-02 02:52 +0000
                          Re: ftp problem Grant Taylor <gtaylor@tnetconsulting.net> - 2020-07-01 21:56 -0600
                            Free cloud virtual servers (Re: ftp problem) Eli the Bearded <*@eli.users.panix.com> - 2020-07-03 19:41 +0000
                              Re: Free cloud virtual servers (Re: ftp problem) Grant Taylor <gtaylor@tnetconsulting.net> - 2020-07-06 19:36 -0600
    Re: ftp problem The Natural Philosopher <tnp@invalid.invalid> - 2020-06-30 09:15 +0100

Page 1 of 2  [1] 2  Next page →

#30214 — ftp problem

A few days ago, I started having problems with ftp. I always
prefer to type in my ftp commands, rather than use Filzilla.
Here is what happens when I log in and ask for a directory listing:

~> ftp ftp.dieterbritz.dk
Connected to accessproxy.webpod10-cph3.one.com.
220 Welcome to One.com FTP.
Name (ftp.dieterbritz.dk:db): dieterbritz.dk
331 User dieterbritz.dk OK. Password required
Password:
230 OK. Current restricted directory is /
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
501 PORT address does not match originator.
ftp: bind: Address already in use
ftp> 

I used to just get that listing but not now. What are
those last lines telling me?
I run Kubuntu.

-- 
Dieter Britz

[toc] | [next] | [standalone]

#30215

Le 29/06/2020 à 16:15, Dieter Britz a écrit :
> 
> ~> ftp ftp.dieterbritz.dk
> Connected to accessproxy.webpod10-cph3.one.com.
> 220 Welcome to One.com FTP.
> Name (ftp.dieterbritz.dk:db): dieterbritz.dk
> 331 User dieterbritz.dk OK. Password required
> Password:
> 230 OK. Current restricted directory is /
> Remote system type is UNIX.
> Using binary mode to transfer files.
> ftp> ls
> 501 PORT address does not match originator.
> ftp: bind: Address already in use

IIUC, the server is complaining because the client IP address received 
in the PORT command (active mode) does not match the source IP address 
of the FTP commmand connection.

If you are behind a NAT device, try FTP passive mode instead.

Is this plain (unencrypted) FTP or FTP with TLS/SSL ? Encrypted FTP 
won't work in active mode behind a NAT device. Even plain FTP will work 
in active mode only behind a NAT which handles the FTP protocol.

[toc] | [prev] | [next] | [standalone]

#30217

On 29/06/2020 18:45, Pascal Hambourg wrote:
> Le 29/06/2020 à 16:15, Dieter Britz a écrit :
>>
>> ~> ftp ftp.dieterbritz.dk
>> Connected to accessproxy.webpod10-cph3.one.com.
>> 220 Welcome to One.com FTP.
>> Name (ftp.dieterbritz.dk:db): dieterbritz.dk
>> 331 User dieterbritz.dk OK. Password required
>> Password:
>> 230 OK. Current restricted directory is /
>> Remote system type is UNIX.
>> Using binary mode to transfer files.
>> ftp> ls
>> 501 PORT address does not match originator.
>> ftp: bind: Address already in use
> 
> IIUC, the server is complaining because the client IP address received 
> in the PORT command (active mode) does not match the source IP address 
> of the FTP commmand connection.
> 
> If you are behind a NAT device, try FTP passive mode instead.
> 
> Is this plain (unencrypted) FTP or FTP with TLS/SSL ? Encrypted FTP 
> won't work in active mode behind a NAT device. Even plain FTP will work 
> in active mode only behind a NAT which handles the FTP protocol.
> 
> 
correct in every sense.
if you want secure ftp use sftp.
One port only.



-- 
"Corbyn talks about equality, justice, opportunity, health care, peace, 
community, compassion, investment, security, housing...."
"What kind of person is not interested in those things?"

"Jeremy Corbyn?"

[toc] | [prev] | [next] | [standalone]

#30218

On 30/06/2020 09:16, The Natural Philosopher wrote:
> On 29/06/2020 18:45, Pascal Hambourg wrote:
>> Le 29/06/2020 à 16:15, Dieter Britz a écrit :
>>>
>>> ~> ftp ftp.dieterbritz.dk
>>> Connected to accessproxy.webpod10-cph3.one.com.
>>> 220 Welcome to One.com FTP.
>>> Name (ftp.dieterbritz.dk:db): dieterbritz.dk
>>> 331 User dieterbritz.dk OK. Password required
>>> Password:
>>> 230 OK. Current restricted directory is /
>>> Remote system type is UNIX.
>>> Using binary mode to transfer files.
>>> ftp> ls
>>> 501 PORT address does not match originator.
>>> ftp: bind: Address already in use
>>
>> IIUC, the server is complaining because the client IP address received 
>> in the PORT command (active mode) does not match the source IP address 
>> of the FTP commmand connection.
>>
>> If you are behind a NAT device, try FTP passive mode instead.
>>
>> Is this plain (unencrypted) FTP or FTP with TLS/SSL ? Encrypted FTP 
>> won't work in active mode behind a NAT device. Even plain FTP will 
>> work in active mode only behind a NAT which handles the FTP protocol.
>>
>>
> correct in every sense.
> if you want secure ftp use sftp.
> One port only.
> 

See 
https://www.tecmint.com/sshfs-mount-remote-linux-filesystem-directory-using-ssh/

> 
> 


-- 
"Corbyn talks about equality, justice, opportunity, health care, peace, 
community, compassion, investment, security, housing...."
"What kind of person is not interested in those things?"

"Jeremy Corbyn?"

[toc] | [prev] | [next] | [standalone]

#30219

Le 30/06/2020 à 10:16, The Natural Philosopher a écrit :
>
> if you want secure ftp use sftp.

If SFTP is available on the server.

[toc] | [prev] | [next] | [standalone]

#30220

On 30/06/2020 15:51, Pascal Hambourg wrote:
> Le 30/06/2020 à 10:16, The Natural Philosopher a écrit :
>>
>> if you want secure ftp use sftp.
> 
> If SFTP is available on the server.
its done over ssh. I haven't met a single distro that doesn't include 
that. By default.


-- 
Those who want slavery should have the grace to name it by its proper 
name. They must face the full meaning of that which they are advocating 
or condoning; the full, exact, specific meaning of collectivism, of its 
logical implications, of the principles upon which it is based, and of 
the ultimate consequences to which these principles will lead. They must 
face it, then decide whether this is what they want or not.

Ayn Rand.

[toc] | [prev] | [next] | [standalone]

#30221

On 6/30/20 10:05 AM, The Natural Philosopher wrote:
> I haven't met a single distro that doesn't include that. By default.

CentOS 6.x minimal install
Debian / Ubuntu debootstrap
Gentoo

Didn't / still don't include SSH client or server by default in the 
minimal installs.  You have to add it.



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#30222

On 30/06/2020 18.05, The Natural Philosopher wrote:
> On 30/06/2020 15:51, Pascal Hambourg wrote:
>> Le 30/06/2020 à 10:16, The Natural Philosopher a écrit :
>>>
>>> if you want secure ftp use sftp.
>>
>> If SFTP is available on the server.
> its done over ssh. I haven't met a single distro that doesn't include 
> that. By default.

Still needs the people handling the server to set it up.
I have machines that don't have ssh nor sftp, and I can not add it.


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#30223

Le 30/06/2020 à 20:33, Carlos E.R. a écrit :
> On 30/06/2020 18.05, The Natural Philosopher wrote:
>> On 30/06/2020 15:51, Pascal Hambourg wrote:
>>> Le 30/06/2020 à 10:16, The Natural Philosopher a écrit :
>>>>
>>>> if you want secure ftp use sftp.
>>>
>>> If SFTP is available on the server.
>> its done over ssh. I haven't met a single distro that doesn't include 
>> that. By default.

You missed my point.

> Still needs the people handling the server to set it up.

Right. Sounds like this server is part of a shared hosting service not 
owned by the OP.

[toc] | [prev] | [next] | [standalone]

#30224

In comp.os.linux.misc, Pascal Hambourg  <pascal@plouf.fr.eu.org> wrote:
> Le 30/06/2020 à 20:33, Carlos E.R. a écrit :
>> Still needs the people handling the server to set it up.
> Right. Sounds like this server is part of a shared hosting service not 
> owned by the OP.

I don't have a login, so I can't see if it works, but the host OP was
trying to ftp into, responds when I try to sftp into it.

$ ftp ftp.dieterbritz.dk
Connected to accessproxy.webpod10-cph3.one.com.
220 Welcome to One.com FTP.
Name (ftp.dieterbritz.dk:eli): ^C
$ 
$ ssh ftp.dieterbritz.dk
The authenticity of host 'ftp.dieterbritz.dk (46.30.211.80)' can't be established.
ECDSA key fingerprint is SHA256:8sBBlU4Q4RqUzZO1J0RpAucj6/DicaJI1TjPDcRO22U.
Are you sure you want to continue connecting (yes/no/[fingerprint])? :^C
$
 
I suspect sftp would work.

In *rare* cases, you find ftp servers that have special commands you can
run on the server, or less rarely special pipelines set up so you can
download generated-on-the-fly tar files. I don't think sftp does that,
so sftp might not always be a good substitute, but it mostly is.

Elijah
------
recalls configuring programs in ~ftp/bin/ decades ago

[toc] | [prev] | [next] | [standalone]

#30225

On 30/06/2020 23.14, Eli the Bearded wrote:
> In comp.os.linux.misc, Pascal Hambourg  <pascal@plouf.fr.eu.org> wrote:
>> Le 30/06/2020 à 20:33, Carlos E.R. a écrit :
>>> Still needs the people handling the server to set it up.
>> Right. Sounds like this server is part of a shared hosting service not
>> owned by the OP.
> 
> I don't have a login, so I can't see if it works, but the host OP was
> trying to ftp into, responds when I try to sftp into it.

I'll mention that sftp causes more CPU load on both server and client. 
On a LAN, it can be slower than plain FTP.


> 
> $ ftp ftp.dieterbritz.dk
> Connected to accessproxy.webpod10-cph3.one.com.
> 220 Welcome to One.com FTP.
> Name (ftp.dieterbritz.dk:eli): ^C
> $
> $ ssh ftp.dieterbritz.dk
> The authenticity of host 'ftp.dieterbritz.dk (46.30.211.80)' can't be established.
> ECDSA key fingerprint is SHA256:8sBBlU4Q4RqUzZO1J0RpAucj6/DicaJI1TjPDcRO22U.
> Are you sure you want to continue connecting (yes/no/[fingerprint])? :^C
> $
>   
> I suspect sftp would work.
> 
> In *rare* cases, you find ftp servers that have special commands you can
> run on the server, or less rarely special pipelines set up so you can
> download generated-on-the-fly tar files. I don't think sftp does that,
> so sftp might not always be a good substitute, but it mostly is.

I've never had a chance to try those...

> 
> Elijah
> ------
> recalls configuring programs in ~ftp/bin/ decades ago
> 


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#30245

with <c36tsg-hqq.ln1@Telcontar.valinor> Carlos E.R. wrote:
> On 30/06/2020 23.14, Eli the Bearded wrote:
>> In comp.os.linux.misc, Pascal Hambourg  <pascal@plouf.fr.eu.org> wrote:
>>> Le 30/06/2020 à 20:33, Carlos E.R. a écrit :

*SKIP*
> I'll mention that sftp causes more CPU load on both server and client.
> On a LAN, it can be slower than plain FTP.

Anecdotal evidence to the contrary.  On my previous phone I developed my
own backup scripts (busybox-nc plus custom busybox-sh on remote, perl on
local;  networking was/is over wifi;  failed to bring up functional
busybox-ftpd (for obvious reasons)).  Now, files transfered (to and fro)
were compressed archives, oggs, jpgs, mp4 and such, still sftpd (with
org.primftpd) yields stable 1M/s while busybox-nc never reached above
300K/s.  Anecdotal evidence it is.

*CUT*

-- 
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

[toc] | [prev] | [next] | [standalone]

#30246

On 02/07/2020 09.46, Eric Pozharski wrote:
> with <c36tsg-hqq.ln1@Telcontar.valinor> Carlos E.R. wrote:
>> On 30/06/2020 23.14, Eli the Bearded wrote:
>>> In comp.os.linux.misc, Pascal Hambourg  <pascal@plouf.fr.eu.org> wrote:
>>>> Le 30/06/2020 à 20:33, Carlos E.R. a écrit :
> 
> *SKIP*
>> I'll mention that sftp causes more CPU load on both server and client.
>> On a LAN, it can be slower than plain FTP.
> 
> Anecdotal evidence to the contrary.  On my previous phone I developed my
> own backup scripts (busybox-nc plus custom busybox-sh on remote, perl on
> local;  networking was/is over wifi;  failed to bring up functional
> busybox-ftpd (for obvious reasons)).  Now, files transfered (to and fro)
> were compressed archives, oggs, jpgs, mp4 and such, still sftpd (with
> org.primftpd) yields stable 1M/s while busybox-nc never reached above
> 300K/s.  Anecdotal evidence it is.
> 
> *CUT*

:-D

My anecdotal evidence is that when I used sftp (ie, ssh file transfer) 
on my Android phones or tablets, it went slow as molasses (quite less 
that 1M/s). Other people do not see this, so I wonder why. Maybe my 
devices are "cheap" and their processors lack power at encryption, or 
the particular encryption protocol selected was heavy. Dunno.


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#30247

Carlos E.R. <robin_lis...@es.invalid> [CE]:
CE> Maybe my devices are "cheap" and their processors lack power
CE> at encryption, or the particular encryption protocol selected was
CE> heavy

Avoid large key RSA (it's known to be slow), use ECxxx algorithms
instead.

[toc] | [prev] | [next] | [standalone]

#30248

On 02/07/2020 17.03, Anonymous Remailer (austria) wrote:
> 
> Carlos E.R. <robin_lis...@es.invalid> [CE]:
> CE> Maybe my devices are "cheap" and their processors lack power
> CE> at encryption, or the particular encryption protocol selected was
> CE> heavy
> 
> Avoid large key RSA (it's known to be slow), use ECxxx algorithms
> instead.

Thanks. I'll try to remember next time I create a key.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#30249

"Carlos E.R." <robin_listas@es.invalid> writes:
> On 02/07/2020 17.03, Anonymous Remailer (austria) wrote:
>> Carlos E.R. <robin_lis...@es.invalid> [CE]:
>>> Maybe my devices are "cheap" and their processors lack power
>>> at encryption, or the particular encryption protocol selected was
>>> heavy
>>
>> Avoid large key RSA (it's known to be slow), use ECxxx algorithms
>> instead.
>
> Thanks. I'll try to remember next time I create a key.

The asymmetric keys (RSA, ECDSA &c) are only used when establishing the
SSH session. They have zero impact on bulk transfer rates.

Bulk encryption _could_ reduce performance compared to unsecured FTP,
but only if you have a very slow CPU. Most CPUs are fast enough to keep
up with disk or network even when doing a bit of encryption.

SFTP client behavior can influence SFTP performance a lot however:

* In FTP, the server reads the file from disk (or wherever) and pushes
  it straight down a TCP connection; the limiting factors are disk IO
  and TCP flow control.

* In contrast with SFTP, the server awaits requests for chunks of the
  file from the client. A poorly written client which requested a chunk
  and waited for it to arrive before requesting the next one would have
  very poor performance compared to either FTP or a well-written client.

Network characteristics can also affect both protocols, and not
necessarily in the same way given their differing strategies. If your
Android devices do not have the same connectivity as your comparators
then that might contribute to explaining the behavioral differences you
see.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#30250

On 03/07/2020 10.44, Richard Kettlewell wrote:
> "Carlos E.R." <robin_listas@es.invalid> writes:
>> On 02/07/2020 17.03, Anonymous Remailer (austria) wrote:
>>> Carlos E.R. <robin_lis...@es.invalid> [CE]:
>>>> Maybe my devices are "cheap" and their processors lack power
>>>> at encryption, or the particular encryption protocol selected was
>>>> heavy
>>>
>>> Avoid large key RSA (it's known to be slow), use ECxxx algorithms
>>> instead.
>>
>> Thanks. I'll try to remember next time I create a key.
> 
> The asymmetric keys (RSA, ECDSA &c) are only used when establishing the
> SSH session. They have zero impact on bulk transfer rates.
> 
> Bulk encryption _could_ reduce performance compared to unsecured FTP,
> but only if you have a very slow CPU. Most CPUs are fast enough to keep
> up with disk or network even when doing a bit of encryption.
> 
> SFTP client behavior can influence SFTP performance a lot however:
> 
> * In FTP, the server reads the file from disk (or wherever) and pushes
>    it straight down a TCP connection; the limiting factors are disk IO
>    and TCP flow control.
> 
> * In contrast with SFTP, the server awaits requests for chunks of the
>    file from the client. A poorly written client which requested a chunk
>    and waited for it to arrive before requesting the next one would have
>    very poor performance compared to either FTP or a well-written client.
> 
> Network characteristics can also affect both protocols, and not
> necessarily in the same way given their differing strategies. If your
> Android devices do not have the same connectivity as your comparators
> then that might contribute to explaining the behavioral differences you
> see.

I have not investigated the cause. My home network is gigabit, and I 
simply noticed that with sftp (typically using sshfs) the disk read does 
not max, but it does with nfs.

But where I really notice the issue is transferring a movie to my 
tablet, it is horrifying slow. Like 300 K/s or so (from memory). 
Obviously the fault is in the tablet or its software. But even 
downloading from Apache is slow (much faster than ssh, but still slow), 
but in that case the limiting factor is the WiFi. So I use the USB cable 
instead.


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#30253

Le 03/07/2020 à 11:03, Carlos E.R. a écrit :
> 
> I have not investigated the cause. My home network is gigabit, and I 
> simply noticed that with sftp (typically using sshfs) the disk read does 
> not max, but it does with nfs.

SSHFS uses FUSE. Isn't it yet another bottleneck ?

[toc] | [prev] | [next] | [standalone]

#30254

On 03/07/2020 17.08, Pascal Hambourg wrote:
> Le 03/07/2020 à 11:03, Carlos E.R. a écrit :
>>
>> I have not investigated the cause. My home network is gigabit, and I 
>> simply noticed that with sftp (typically using sshfs) the disk read 
>> does not max, but it does with nfs.
> 
> SSHFS uses FUSE. Isn't it yet another bottleneck ?

Maybe.

In the past I used 'mc' own "virtual" remote filesystem view, but it broke.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#30226

On 30/06/2020 22:05, Pascal Hambourg wrote:
> Le 30/06/2020 à 20:33, Carlos E.R. a écrit :
>> On 30/06/2020 18.05, The Natural Philosopher wrote:
>>> On 30/06/2020 15:51, Pascal Hambourg wrote:
>>>> Le 30/06/2020 à 10:16, The Natural Philosopher a écrit :
>>>>>
>>>>> if you want secure ftp use sftp.
>>>>
>>>> If SFTP is available on the server.
>>> its done over ssh. I haven't met a single distro that doesn't include 
>>> that. By default.
> 
> You missed my point.
> 
>> Still needs the people handling the server to set it up.
> 
> Right. Sounds like this server is part of a shared hosting service not 
> owned by the OP.

they normally include ssh on those.

-- 
"The great thing about Glasgow is that if there's a nuclear attack it'll 
look exactly the same afterwards."

Billy Connolly

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web