[Tutor] ftp socket.error
Martin A. Brown
martin at linux-ip.net
Sat Sep 12 18:24:09 CEST 2015
Hello and good morning
> 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
>> 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.
>>
>> >>> 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
>>>>
>>>> # 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
>>> 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 - Tutor at python.org
>> To unsubscribe or change subscription options:
>> https://mail.python.org/mailman/listinfo/tutor
>>
>
--
Martin A. Brown
http://linux-ip.net/
More information about the Tutor
mailing list