Timeout don't works in blocking mode during 'tri (General questions)

Hi,
One of my app uses SFTP connection in blocking mode and I found following problem: one of my clients uses Kerio firewall as a proxy. He is mysterious as Gandalf about exact configuration, however there is something rotten inside, because at first it allows connection to outer SFTP and in the next step it cancels session.
The problem is that wodFTPdlx in the blocking mode hangs in such situation and only way is to shoot the app down via task manager.

Sorry I can't supply more info, it seems that socks layer (maybe?) doesn't count on timeout when in the middle of a handshaking process
in the blocking mode.

Yesterday another client reported same issue - he connects from LAN where (he thinks so far) is incorrect MTU set at the gateway, which leads to same situation mostly (Nth packet from handshqaking process is trashed).

There are reasons why we have to use blocking mode here so I'd like to solve it somehow. Maybe I'm asking for give me that, dunno what , but it's all I know about problem, unfortulatelly.

Could you please take a look at it?

Thanks in advance.

Miker

P.S. Currently I have one (very communicative) client with such problem, so if you would like to test something there, just let me know.

Hi Miker,

We need some time to test this.
I just tried this and I installed Kerio Firewall and now I have problems...
I cannot establish my connection to outside. So I will try this, but I need some time, is this Ok for you?
In mean time you can add some debug code.

For example:
Under the FTPRepy event add this code

Debug.Print REPLY: & Command & ReplyText & ReplyText

and before you call connect add this hiden feature, for example:

FtpDLX1.DebugFile = c:debug.nfo

and send that info to: techsupport@weonlydo.com

Regards,
Alan

We need some time to test this.
I just tried this and I installed Kerio Firewall and now I have problems...
I cannot establish my connection to outside. So I will try this, but I need some time, is this Ok for you?

Sure. Thanks for reply in turn.

In mean time you can add some debug code.
...

Ok, I'll try to manage it during weekend. In case I'll be unsuccessfull catching him I send you results during mon-tue.

Thanks again.

Miker

Edit: Hmm now I see that FTPReply event is fired for FTP and FTPS only, so I'll switch that test client to FTP, hoping that it invokes the problem, too (if you have no other idea).

Miker,

Yes, you are right, I overlook that. You can try with FTP, if problem occur send us and FTPReply info., if not send us only debug file.
Besides that I have more question for you, so we can try to duplicate this problem.
What you mean under next step , call another Method, right?
What version of wodFtpDLX ActiveX component do you have?
Maybe this is fixed in new version if this even wodFtpDLX problem.
Does this problem occur with any other client?
I'm asking this because, I'm trying to isolate problem.

Regards,
Alan

Yes, you are right, I overlook that. You can try with FTP, if problem occur send us and FTPReply info., if not send us only debug file.

Ok. I can try to push it via FTPS - after all it's much closer to SFTP that silly FTP - but I need admin's cooperation and he's out of reach now, so it have to wait for monday.

What you mean under next step , call another Method, right?

No, it never returns from calling the .Connect method, unfortunatelly. If it would, I'd get an additional info maybe ... I have no chance to run tcpdump/pcap etc nor to see logs, I only guess what exactly happens based on comments from a techie of the affected company. He said that he saw in the Kerio logs that connection was established (first part of handshake exchanged in both directions) and suddenly canceled during 2nd or round (with no clear reason, but it's not my problem, fortunatelly). FYI he was very disappointed as it was his first bad experience with Kerio, which he's using for years. There were config stages when he got a working state, changed something to test it and reverted changes, but it was not working anymore; sometimes reload helped, sometimes reboot .

What version of wodFtpDLX ActiveX component do you have? Maybe this is fixed in new version if this even wodFtpDLX problem.

2.5.7.220. It was first thing I tried to update. IMHO only wodFTPDLX problem is that it (guessing) hangs inside of .Connect if connection is established, but then broken because of network problems.

Does this problem occur with any other client?
I'm asking this because, I'm trying to isolate problem.

I understand. As I said, I have two cases, one is that company with Kerio and second is a single person connected via some small ISP. Currently there are just about twenty installations, but another a few hundred installations waits for a upgrade to solution using wodFtpDlx.

Excluding that single person the rest of installations (only five of them live under Kerio), which are connected via CDMA (road warriors), are working perfectly with one strange exception, but I can't use him for any tests, because it's a manager.

Let me know if you'll need ani further info, code samples etc.

Regards,
Miker

Hi Miker,

I just tried this and works like a charm.
I tried every protocol and I set Blocking Property to True and everything works fine for me, again.
Can you prepare same samples which causes problem like yours?

Only one time, with our sample, I met problem like yours, but I didn't set full path for Remote path. When I called ListDir Method I met some problems, but full path resolved this. This probably isn't your case, so i would suggest you give me some samples.

Regards,
Alan

I tried every protocol and I set Blocking Property to True and everything works fine for me, again.
Can you prepare same samples which causes problem like yours?

Ok, I'm sending part of the code which inits, connects and disconnects (to techsupport-at- weonlydo-dot- com). However I have to point out that problem occurs ONLY when network communication is interrupted during the SFTP (SSH to be exact) handshake process and it causes that .Connect method never returns. I understand it's not easy to simulate such environment (hmm if you have some linux box it wouldn't be too difficult maybe - i suppose that fw rule, which accepts first outgoing packet and immediatelly disables itself would do that job; I'll try it next week).

Regards,
Miker