Article delegate-en/3438 of [1-5169] on the server localhost:119
  upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
Newsgroups: mail-lists.delegate-en

[DeleGate-En] Re: ftps fails to work with client side ssl utilized.... connected but directory hangs
01 Aug 2006 19:54:27 GMT (Yutaka Sato)
The DeleGate Project


On 08/02/06(04:27) you Michael Ingardia <> wrote
in <_A3436@delegate-en.ML_> (nntp://
 |Ok I tried this remotely, and in order to hit my ftp server you have to 
 |have an active connection.  PASV fails due to fire wall rules most likely.
 |Here is the log:
 |08/01 14:14:55.58 [2880] 1+0: gethostbyname(-) unknown[0.00s]
 |08/01 14:14:55.58 [2880] 1+0: [FCL] callFilter2: 27=1 38=1 sslway
 |08/01 14:14:55.67 [2880] 1+0: ## SSLway ## 0.090000 sescache[1] HIT=0
 |(WIN) 14:55.768 [3856] >>>> [0] 1836 is not socket, retrying 
 |WSADuplicateSocket ...
 |(WIN) 14:55.768 [3856] FATAL: inherited handle[0] 1836 is not socket

I think this is the problem.  Maybe inheriting the socket handle (connected
to the client or server) from DeleGate to the SSL wrapper process (SSLway)
fails by some reason, then DeleGate detects the reset of connection.
On Windows, with VPN or so, it is known that DeleGate causes this
failure, maybe because the DuplicateHandle() is not supported or supported
by the VPN or so....
For example:<URL:>
What is special in your case is that it seems work partially.

Anyway, if you succeed it on Unix, it is the problem of DeleGate on
Windows with some special network configuration.
If you fail it on Windows even for ftps:// then the
problem is not specific to the server.

  9 9   Yutaka Sato <>
 ( ~ )  National Institute of Advanced Industrial Science and Technology
_<   >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan
Do the more with the less -- B. Fuller

  admin search upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]