[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