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

[Carlo Florendo]

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 (www.sysinternals.com) 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

%SystemRoot%\system32\drivers\etc

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

--
Carlo Florendo
Astra Philippines Inc.
www.astra.ph


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/