This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[SOLVED] Re: other services ok, ftp not (was 1.5.11 - tcp problems)

Hello Brian,

What we had was *not* a cygwin problem after all...

Brian Dessent wrote:

Carlo Florendo wrote:

Anyway, I got this error:

getservbyname() returned NULL: win32 error 11004

Googling shows that this is consistent with trying to run a program/server that tries to look up its port in the services file when no such matching line exists.

I also read the message regarding the \r\n and \n line endings (still
not in my mailbox) and Corinna's reply.  I've checked the services file
and confirmed that the line endings are \r\n  (with the simple test of
^M showing up when invoking `vim -b'.  Notepad also views the file
correctly, thus it's really \r\n.).

I'm confident we're getting close!

Closer yes,

Yes. In fact, ftp is working perfectly well now. Thank you very much. More below...

but I'm afraid I don't have much else coming to mind. Everything indicates that it's not finding what it's looking for in the
services file.

Correct. That is because the services file wasn't present in the first place. Let me explain...

Since the `services' file was involved, I thought of having a way to monitor which files the ftp client accesses to make sure that it really accesses the `services' file. I then remembered that I had this copy of sysinternal's ( filemonitor program filemon.exe which displays file access on a system in real time. Thus, I simply fired up filemon.exe, then fired up ftp, and poof, got the answer right smack in my face.

ftp was trying to access c:\winnt\nsdb\services. I then checked my system and c:\winnt\nsdb\ really existed but c:\winnt\nsdb\services did not. Then, I wondered why it was looking at that directory and not c:\winnt\system32\drivers\etc. I had no way of finding out where the system got c:\winnt\nsdb but I first assumed that it got that location from the registry. I fired up regedit and looked for all instances of `nsdb'. Interestingly, I got this registry key/value:

\HKLM\SYSTEM\ControlSet001\Services\Tcpip\Parameters\DataBasePath = %SystemRoot%\nsdb

I changed the registry entry value to


then fired up ftp. Whew! It worked perfectly.

I searched on the cause of a modification of this registry entry and it was a virus (which has long been removed from the system).

One thing is clear though, this is not a Cygwin problem.  The mingw
example shows a minimal testcase that involves no Cygwin code at all,
just direct calls to the Winsock functions.  I'm willing to bet if you
found a regular windows application that tried to look up a port using
getservbyname() it would fail in the same way.

Correct again. In fact, I made a simple program in VC++ that used getservbyname() and it failed exactly the same way as
your *.c codes.

 This is a relatively
rare/antiquated thing to do as most apps either have the port
configurable via a URL or a config file, or they just hard-code it.

If you want a quick and dirty solution, comment out the call to
getservbyname in the ftp source code and modify it to assume port 21. But that's admitting defeat, really.

We won't, we didn't and we won. Thanks Brian and to everyone for the valuable comments which led us to lay this problem to rest.
On a curious note, why do the inetutils apps like ftp, telnet, etc. still use getservbyname() and the other getserv functions when, as you said,
these apps could just have the port and protocol hardcoded or specified in a config file?

In any case, this is what I like with cygwin the cygwin mailing list. They're the best! Cygwin...It Rocks!

Best Regards,


Carlo Florendo
Astra Philippines Inc.

-- Unsubscribe info: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]