Socket error errno 11004 host not found

FTP is an easy way to transfer files.

But, a mistake in single step during the connection can lock you out and throw errors. One such error is FTP “socket error 11004“.

What’s socket? And, what’s this number in the error means? Well, we’ll see the answers to all these questions.

Fixing FTP issues of our customers is one of the common tasks that we do as part of our Outsourced Technical Support for web hosts.

Today we’ll discuss the top 3 reasons for this error and how we fix them.

What is FTP ‘socket error 11004’?

Before we go on, let’s first get an idea of this error.

A socket is the end point of communication between the client and the server, and this socket is bound to a port number.

In a normal FTP connection, the server listens on its socket. When the client makes a successful connection to the server, a new socket is created at the server end and client end to exclusively serve the client’s requests.

A socket error can occur if the above things aren’t going well or if something blocks the connection between the client and the server.

Liekwise, FTP socket error 11004 means that the name lookup(translation from domain name to IP address) has found a host, but no valid data.

FTP ‘socket error 11004’ – Causes and Solutions

We got a clear idea of this error. Now, let’s see the main reasons for the FTP ‘socket error 11004’ and how our Support Engineers fix them.

1) Typo in FTP hostname

Users should enter the FTP Host details to establish a connection and it can be the server hostname or IP address.

For example, to connect to a remote server server.hostname.com, users should enter the FTP host as server.hostname.com or ftp.server.hostname.com or the server IP address.

A typo in the FTP hostname/IP address or a missing Host field in the FTP settings can lead to this error. Similarly, even a single additional space in the hostname can also result in this error.

For example, one the of the common mistakes that we’ve noticed is that users erroneously enter the FTP hostname in their FTP clients as “ftp://ftp.domain.com“. But, the FTP server considers this to be an invalid host and rejects the connection.

Consequently, users see FTP ‘socket error 11004’

How we fix?

Firstly, our Support Engineer check the DNS connectivity of the FTP server using the below command.

dig ftp.domain.com

Further, we compare it with the user’s  FTP client settings. If a typo has been noted in the FTP hostname, we’ll immediately correct it.

For example, if the customer uses ftp://ftp.domain.com as the hostname, we ask the customer to change it to ftp.domain.com, domain.com or the domain’s IP address.

2) Bad DNS records of FTP host

Similarly, missing DNS records or incorrect DNS records for the FTP host can lead to this error.

This usually happens when you migrate the domain to a new server or change the DNS records of the domain.

Recently, we got a support ticket where the user complains that he can’t do FTP with hostname ftp.domain.com. Later, we identified that the domain was recently migrated and that the DNS records for ftp.domain.com are missing.

How we fix?

For DNS issues, our Support Engineers check the DNS connectivity of the FTP hostname using the telnet command. If we find any missing or incorrect DNS entries, we’ll correct the DNS settings of the domain to point to the correct server. During the propagation period, we suggest the customer to use the domain’s IP address as the FTP host.

3) Firewall blocks

Another possibility is firewall blocking the connection. Antivirus software or third party firewalls on the user’s PC can sometimes block connections.

How we fix?

We resolve this by asking the users to temporarily turn off all security applications(Windows firewall, software firewall, etc.) one by one. This helps us figure out exactly which app is causing the error, and fix its settings.

So, if you need help to solve your FTP issue, click here to get a Support Engineer to look into your issue.

Conclusion

In short, FTP “socket error 11004” can happen due to bad DNS records, firewall blocks, and more. Today, we’ve discussed the top 3 reasons for this error and how our Support Engineers fix them.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

The problem here is that in a TCPHandler, a «request» is actually a complete connection, from beginning to end.* Your handler gets called on accept, and when you return from it, the socket gets closed.

If you want to build a request-response-protocol handler on top of that, which processes multiple protocol-level requests on a single socket-level request, you have to do that yourself (or use a higher-level framework). (Subclasses like BaseHTTPServer demonstrate how to do this.)

For example, you can just use a loop within your handle function. Of course you probably want to add an exception handler here and/or deal with EOF from rfile (note self.rfile.readline() will return '' for EOF, but 'n' for a blank line, so you have to check it before calling strip unless you want a blank line to mean «quit» in your protocol). For example:

def handle(self):
    try:
        while True:
            request  = self.rfile.readline()
            if not request:
                break
            request = request.rstrip()
            print "RX [%s]: %s" % (self.client_address[0], request)

            response = self.processRequest(request)

            print "TX [%s]: %s" % (self.client_address[0], response)
            self.wfile.write(response + 'n')
    except Exception as e:
        print "ER [%s]: %r" % (self.client_address[0], e)
    print "DC [%s]: disconnected" % (self.client_address[0])

This will often work with your existing client, at least over localhost on an unloaded machine, but it’s not actually correct, and «often works» is rarely good enough. See TCP sockets are byte streams, not message streams for a longer discussion, but briefly, you also need to do the stuff mentioned in David Schwarz’s answer: append newlines to what you write from the server (which I already did above), and have the client read line by line instead of just trying to read 1024 bytes at a time (which you can do by writing your own buffer-and-split-lines code, or just by using the makefile method, so it can use rfile.readline() just like the server side does.)

Not fixing the client won’t cause the problems that answer claims, but it will cause problems like this:

Sent:     request type 01
Received: resp
Sent:     request type 02
Received: onse type 01
response typ

And you can see that in a real program that actually tried to process the responses programmatically, a response like resp or onse type 01nresponse typ isn’t going to be very useful…

_{* Note that SocketServer is an ancient design that nobody really loves. There’s a reason Python 3 added asyncio, and that people in Python 2 usually use third-party frameworks like Twisted and gevent. They’re both simpler for simple tasks, and more flexible/powerful (and a lot more efficient) for complex tasks.}

I am trying to connect using the example:

import splunklib.client as client

# Create a Service instance and log in 
with client.connect(
        host="http://myhost",
        port=0000,
        username="me",
        password="my password") as conn:
    # Print installed apps to the console to verify login
    for app in conn.apps:
        print app.name

But I am getting the following error:

Traceback (most recent call last):
  File "C:/Users/anshanno/PycharmProjects/splunkTest/splunkSDKtest.py", line 8, in <module>
    password="my password") as conn:
  File "C:Python27libsite-packagessplunk_sdk-1.6.0-py2.7.eggsplunklibclient.py", line 321, in connect
    s.login()
  File "C:Python27libsite-packagessplunk_sdk-1.6.0-py2.7.eggsplunklibbinding.py", line 857, in login
    cookie="1") # In Splunk 6.2+, passing "cookie=1" will return the "set-cookie" header
  File "C:Python27libsite-packagessplunk_sdk-1.6.0-py2.7.eggsplunklibbinding.py", line 1201, in post
    return self.request(url, message)
  File "C:Python27libsite-packagessplunk_sdk-1.6.0-py2.7.eggsplunklibbinding.py", line 1218, in request
    response = self.handler(url, message, **kwargs)
  File "C:Python27libsite-packagessplunk_sdk-1.6.0-py2.7.eggsplunklibbinding.py", line 1357, in request
    connection.request(method, path, body, head)
  File "C:Python27libhttplib.py", line 1053, in request
    self._send_request(method, url, body, headers)
  File "C:Python27libhttplib.py", line 1093, in _send_request
    self.endheaders(body)
  File "C:Python27libhttplib.py", line 1049, in endheaders
    self._send_output(message_body)
  File "C:Python27libhttplib.py", line 893, in _send_output
    self.send(msg)
  File "C:Python27libhttplib.py", line 855, in send
    self.connect()
  File "C:Python27libhttplib.py", line 1266, in connect
    HTTPConnection.connect(self)
  File "C:Python27libhttplib.py", line 832, in connect
    self.timeout, self.source_address)
  File "C:Python27libsocket.py", line 557, in create_connection
    for res in getaddrinfo(host, port, 0, SOCK_STREAM):
socket.gaierror: [Errno 11004] getaddrinfo failed

Has anyone else experienced this or know what is causing the issue? I have replaced my connection info for obvious reasons

Any help is appreciated.