[Tutor] ftp socket.error

Discussion:

richard kappler

2015-09-11 16:00:12 UTC

I can connect via ftp, but when I try to send a file, I get a no route to
host error, I don't understand.

import ftplib
from ftplib import FTP
fBOT = FTP()
oldfile = '/home/test/DataFeed/input/images/BOT/1.jpg'
newfile = 'new.jpg'
oldfile = open('/home/test/DataFeed/input/images/BOT/1.jpg', 'rb')
fBOT.connect('192.168.2.23', 2021)

'220 Service ready for new user.'

fBOT.login('BOT', 'sick')

'230 User logged in, proceed.'

fBOT.storbinary('STOR newfile', oldfile)

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib64/python2.6/ftplib.py", line 452, in storbinary
conn = self.transfercmd(cmd)
File "/usr/lib64/python2.6/ftplib.py", line 360, in transfercmd
return self.ntransfercmd(cmd, rest)[0]
File "/usr/lib64/python2.6/ftplib.py", line 326, in ntransfercmd
conn = socket.create_connection((host, port), self.timeout)
File "/usr/lib64/python2.6/socket.py", line 567, in create_connection
raise error, msg
socket.error: [Errno 113] No route to host

Any ideas?

regards, Richard

--
All internal models of the world are approximate. ~ Sebastian Thrun
_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Reuben

2015-09-11 16:16:54 UTC

Permalink

Check if the ftp server ip is pinging

Sent from my iPhone

Post by richard kappler
I can connect via ftp, but when I try to send a file, I get a no route to
host error, I don't understand.

'220 Service ready for new user.'

fBOT.login('BOT', 'sick')

'230 User logged in, proceed.'

fBOT.storbinary('STOR newfile', oldfile)

File "<stdin>", line 1, in <module>
File "/usr/lib64/python2.6/ftplib.py", line 452, in storbinary
conn = self.transfercmd(cmd)
File "/usr/lib64/python2.6/ftplib.py", line 360, in transfercmd
return self.ntransfercmd(cmd, rest)[0]
File "/usr/lib64/python2.6/ftplib.py", line 326, in ntransfercmd
conn = socket.create_connection((host, port), self.timeout)
File "/usr/lib64/python2.6/socket.py", line 567, in create_connection
raise error, msg
socket.error: [Errno 113] No route to host
Any ideas?
regards, Richard
--
All internal models of the world are approximate. ~ Sebastian Thrun
_______________________________________________
https://mail.python.org/mailman/listinfo/tutor

_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

richard kappler

2015-09-11 16:17:54 UTC

Permalink

Figured it out. On the receiving machine I had to

# modprobe ip_conntrack_ftp

Post by richard kappler
I can connect via ftp, but when I try to send a file, I get a no route to
host error, I don't understand.

'220 Service ready for new user.'

fBOT.login('BOT', 'sick')

'230 User logged in, proceed.'

fBOT.storbinary('STOR newfile', oldfile)

richard kappler

2015-09-11 16:47:33 UTC

Permalink

No, apparently I didn't figure it out. I thought I had as after the
modprobe I was getting a an EOFError, but now I'm getting the no route to
host error again. I can ping it, and as you can see from the original post,
I am able to establish a connection and log in, it's just when I try to
send a file it goes bollocks up. Still need ideas.

regards, Richard

Post by richard kappler
Figured it out. On the receiving machine I had to
# modprobe ip_conntrack_ftp

Post by richard kappler
I can connect via ftp, but when I try to send a file, I get a no route to
host error, I don't understand.

'220 Service ready for new user.'

fBOT.login('BOT', 'sick')

'230 User logged in, proceed.'

fBOT.storbinary('STOR newfile', oldfile)

--
All internal models of the world are approximate. ~ Sebastian Thrun

Martin A. Brown

2015-09-11 22:22:48 UTC

Permalink

Hi there Richard,

Strictly speaking, it's no Python question, but... good ol' FTP.

Post by richard kappler

Post by richard kappler
socket.error: [Errno 113] No route to host

Your program is receiving an EHOSTUNREACH.

Post by richard kappler

Post by richard kappler
import errno
errno.errorcode[113]

'EHOSTUNREACH'

This occurs at precisely the moment that your program is trying to
initiate a data transfer. Every firewall administrator in the world
loves FTP for precisely this reason. (And, when I say "love", you
can replace this with a verb or <expletive/> of your choice.)

Without packet captures, I will merely guess (based on experience).

1. The receiving machine is running the Python program, builds a
connection on port 21 (this is called the FTP command
channel), you log in and all is well.
2. The moment you try to transfer any data, the FTP client (your
receiving machine) and the FTP server negotiate either FTP
passive mode or FTP active (retronym) mode. I'm guessing
that your FTP client is choosing passive mode. (Your FTP
client might produce logging of this negotiation.)
3. Using the connection information, the client attempts to build
an FTP data channel. So, your machine running the Python
program initiates a connection to the FTP server.
4. The FTP server is (probably) configured to allow connections
inbound to TCP/21 (FTP Command Channel), but doesn't know to
allow the connections to the ephemeral port(s) negotiated
during step 2 (above). So, the firewall on the FTP Server
sends an ICMP Type 3, Code 1 [0].

Post by richard kappler

Post by richard kappler
Figured it out. On the receiving machine I had to
# modprobe ip_conntrack_ftp

Right instinct! Try this same command on the FTP server side.
Unless your Python FTP client is negotiating active mode, the server
will be the "problem" in this case.

Post by richard kappler
No, apparently I didn't figure it out. I thought I had as after
the modprobe I was getting a an EOFError, but now I'm getting the
no route to host error again. I can ping it, and as you can see
from the original post, I am able to establish a connection and
log in, it's just when I try to send a file it goes bollocks up.
Still need ideas.

Hopefully, my idea #1 helps. (If not, you'll need to do some packet
captures and probably crank up the logging on the FTP server, too.)

I do have another idea, though. Have you ever wondered about the
slow demise of FTP? All of this command-channel, data-channel, PORT
or PASV nonsense goes away when you use a protocol that runs over a
single TCP port. Worked fine in the early days of the Internet
before firewalls and NAT.

Anyway, short idea #2:

If it's anonymous access, use HTTP.
If authenticated access, use ssh/scp/sftp.

Good luck,

-Martin

[0] http://www.networksorcery.com/enp/protocol/icmp/msg3.htm

--
Martin A. Brown
http://linux-ip.net/
_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Robert Nanney

2015-09-12 03:45:54 UTC

Permalink

I may be mistaken, but it looks like you are trying to open the socket on
port 2021. Standard ftp uses 21. Is the server listening on 2021?

Post by Martin A. Brown
Hi there Richard,
Strictly speaking, it's no Python question, but... good ol' FTP.
socket.error: [Errno 113] No route to host
Your program is receiving an EHOSTUNREACH.

Post by richard kappler

Post by richard kappler
import errno
errno.errorcode[113]

'EHOSTUNREACH'
This occurs at precisely the moment that your program is trying to
initiate a data transfer. Every firewall administrator in the world loves
FTP for precisely this reason. (And, when I say "love", you can replace
this with a verb or <expletive/> of your choice.)
Without packet captures, I will merely guess (based on experience).
1. The receiving machine is running the Python program, builds a
connection on port 21 (this is called the FTP command
channel), you log in and all is well.
2. The moment you try to transfer any data, the FTP client (your
receiving machine) and the FTP server negotiate either FTP
passive mode or FTP active (retronym) mode. I'm guessing
that your FTP client is choosing passive mode. (Your FTP
client might produce logging of this negotiation.)
3. Using the connection information, the client attempts to build
an FTP data channel. So, your machine running the Python
program initiates a connection to the FTP server.
4. The FTP server is (probably) configured to allow connections
inbound to TCP/21 (FTP Command Channel), but doesn't know to
allow the connections to the ephemeral port(s) negotiated
during step 2 (above). So, the firewall on the FTP Server
sends an ICMP Type 3, Code 1 [0].
Figured it out. On the receiving machine I had to

Post by richard kappler

Post by richard kappler
# modprobe ip_conntrack_ftp

Right instinct! Try this same command on the FTP server side. Unless your
Python FTP client is negotiating active mode, the server will be the
"problem" in this case.
No, apparently I didn't figure it out. I thought I had as after the

Post by richard kappler
modprobe I was getting a an EOFError, but now I'm getting the no route to
host error again. I can ping it, and as you can see from the original post,
I am able to establish a connection and log in, it's just when I try to
send a file it goes bollocks up. Still need ideas.

Hopefully, my idea #1 helps. (If not, you'll need to do some packet
captures and probably crank up the logging on the FTP server, too.)
I do have another idea, though. Have you ever wondered about the slow
demise of FTP? All of this command-channel, data-channel, PORT or PASV
nonsense goes away when you use a protocol that runs over a single TCP
port. Worked fine in the early days of the Internet before firewalls and
NAT.
If it's anonymous access, use HTTP.
If authenticated access, use ssh/scp/sftp.
Good luck,
-Martin
[0] http://www.networksorcery.com/enp/protocol/icmp/msg3.htm
--
Martin A. Brown
http://linux-ip.net/
_______________________________________________
https://mail.python.org/mailman/listinfo/tutor

_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Martin A. Brown

2015-09-12 16:24:09 UTC

Permalink

Hello and good morning

Post by Robert Nanney
I may be mistaken, but it looks like you are trying to open the
socket on port 2021. Standard ftp uses 21. Is the server listening
on 2021?

Ooof! And, in fact, that is a great point! I overlooked that in
the original snippet!

Everything I wrote still stands, except that you need to tell the
ip_conntrack_ftp (or nf_conntrack_ftp) kernel module to watch for a
command channel on TCP/2021.

modprobe ip_conntrack_ftp ports=21,2021

That means that the ip_conntrack_ftp module will watch flows on both
ports.

I'm glad you observed that important detail, Robert!

-Martin

Post by Robert Nanney

Post by Martin A. Brown
Strictly speaking, it's no Python question, but... good ol' FTP.
socket.error: [Errno 113] No route to host
Your program is receiving an EHOSTUNREACH.

Post by richard kappler

Post by richard kappler
import errno
errno.errorcode[113]

'EHOSTUNREACH'
This occurs at precisely the moment that your program is trying to
initiate a data transfer. Every firewall administrator in the world loves
FTP for precisely this reason. (And, when I say "love", you can replace
this with a verb or <expletive/> of your choice.)
Without packet captures, I will merely guess (based on experience).
1. The receiving machine is running the Python program, builds a
connection on port 21 (this is called the FTP command
channel), you log in and all is well.
2. The moment you try to transfer any data, the FTP client (your
receiving machine) and the FTP server negotiate either FTP
passive mode or FTP active (retronym) mode. I'm guessing
that your FTP client is choosing passive mode. (Your FTP
client might produce logging of this negotiation.)
3. Using the connection information, the client attempts to build
an FTP data channel. So, your machine running the Python
program initiates a connection to the FTP server.
4. The FTP server is (probably) configured to allow connections
inbound to TCP/21 (FTP Command Channel), but doesn't know to
allow the connections to the ephemeral port(s) negotiated
during step 2 (above). So, the firewall on the FTP Server
sends an ICMP Type 3, Code 1 [0].
Figured it out. On the receiving machine I had to

Post by richard kappler

Post by richard kappler
# modprobe ip_conntrack_ftp

Hopefully, my idea #1 helps. (If not, you'll need to do some packet
captures and probably crank up the logging on the FTP server, too.)
I do have another idea, though. Have you ever wondered about the slow
demise of FTP? All of this command-channel, data-channel, PORT or PASV
nonsense goes away when you use a protocol that runs over a single TCP
port. Worked fine in the early days of the Internet before firewalls and
NAT.
If it's anonymous access, use HTTP.
If authenticated access, use ssh/scp/sftp.
Good luck,
-Martin
[0] http://www.networksorcery.com/enp/protocol/icmp/msg3.htm
--
Martin A. Brown
http://linux-ip.net/
_______________________________________________
https://mail.python.org/mailman/listinfo/tutor

richard kappler

2015-09-14 15:55:18 UTC

Permalink

Thanks for all the assistance, turned out it was a problem with the
iptables not having an accept for eth1. Onward and upward!

regards, Richard

Post by Martin A. Brown
Hello and good morning
I may be mistaken, but it looks like you are trying to open the socket on

Post by Robert Nanney
port 2021. Standard ftp uses 21. Is the server listening on 2021?

Ooof! And, in fact, that is a great point! I overlooked that in the
original snippet!
Everything I wrote still stands, except that you need to tell the
ip_conntrack_ftp (or nf_conntrack_ftp) kernel module to watch for a command
channel on TCP/2021.
modprobe ip_conntrack_ftp ports=21,2021
That means that the ip_conntrack_ftp module will watch flows on both ports.
I'm glad you observed that important detail, Robert!
-Martin
Strictly speaking, it's no Python question, but... good ol' FTP.

Post by Robert Nanney

Post by richard kappler
socket.error: [Errno 113] No route to host

Post by Martin A. Brown

Post by Martin A. Brown
Your program is receiving an EHOSTUNREACH.

Post by richard kappler
import errno
errno.errorcode[113]

'EHOSTUNREACH'
This occurs at precisely the moment that your program is trying to
initiate a data transfer. Every firewall administrator in the world loves
FTP for precisely this reason. (And, when I say "love", you can replace
this with a verb or <expletive/> of your choice.)
Without packet captures, I will merely guess (based on experience).
1. The receiving machine is running the Python program, builds a
connection on port 21 (this is called the FTP command
channel), you log in and all is well.
2. The moment you try to transfer any data, the FTP client (your
receiving machine) and the FTP server negotiate either FTP
passive mode or FTP active (retronym) mode. I'm guessing
that your FTP client is choosing passive mode. (Your FTP
client might produce logging of this negotiation.)
3. Using the connection information, the client attempts to build
an FTP data channel. So, your machine running the Python
program initiates a connection to the FTP server.
4. The FTP server is (probably) configured to allow connections
inbound to TCP/21 (FTP Command Channel), but doesn't know to
allow the connections to the ephemeral port(s) negotiated
during step 2 (above). So, the firewall on the FTP Server
sends an ICMP Type 3, Code 1 [0].
Figured it out. On the receiving machine I had to

Post by Martin A. Brown

Post by Martin A. Brown
# modprobe ip_conntrack_ftp

Right instinct! Try this same command on the FTP server side. Unless

your
Python FTP client is negotiating active mode, the server will be the
"problem" in this case.
No, apparently I didn't figure it out. I thought I had as after the

Post by Martin A. Brown
modprobe I was getting a an EOFError, but now I'm getting the no route to
host error again. I can ping it, and as you can see from the original post,
I am able to establish a connection and log in, it's just when I try to
send a file it goes bollocks up. Still need ideas.

Hopefully, my idea #1 helps. (If not, you'll need to do some packet
captures and probably crank up the logging on the FTP server, too.)
I do have another idea, though. Have you ever wondered about the slow
demise of FTP? All of this command-channel, data-channel, PORT or PASV
nonsense goes away when you use a protocol that runs over a single TCP
port. Worked fine in the early days of the Internet before firewalls and
NAT.
If it's anonymous access, use HTTP.
If authenticated access, use ssh/scp/sftp.
Good luck,
-Martin
[0] http://www.networksorcery.com/enp/protocol/icmp/msg3.htm
--
Martin A. Brown
http://linux-ip.net/
_______________________________________________
https://mail.python.org/mailman/listinfo/tutor

--
Martin A. Brown
http://linux-ip.net/