TurboFloat Client unable to reach Server: TF_E_INET

I'll look into reproducing this. Do you get anything in your log?

Hi Wyatt,

No, unfortunately, has nothing, except the following notification:2013-12-05, 15:28:14.481365 <notification> Activated successfully.

It is just if the tcp call was failing. After about 10 sec (not counted, just an impression) there is the error code 4. Like a timeout. So nothing reached the server, it seams. (I have no firewall that blocks an outgoing call, especially not on localhost for tests. Unless Windows 8.1 is doing more that asked to. But I would be surprised; I can check tomorrow.)

My two side questions were:- Is the server socket listening to all addresses (including localhost).- Is there a way to know to which ip/port the client dll tried to connect to? (Just to see if this is a SaveServer() problem, even if the return value is 0. -- It would have been interesting in such a case to be able to call RequestLease() with two parameters for server and port to use (to bypass SaveServer).)

If I can test anything to be of help, let me know.

Best regards,Alexandre Leclerc

Hi Wyatt,

I used process monitor to see what is going on. It looks like the dll tries to make a call to our DNS server and fails. Our main business firewall uses OpenDNS as DNS server. This works flawlessly since many years with a whole range of weird softwares.

Here is what Process Monitor shows :TCP Reconnect Alexandre-W8.office:52178 -> hit-nxdomain.opendns.com:4998TCP Reconnect Alexandre-W8.office:52178 -> hit-nxdomain.opendns.com:4998

Then after two failiures it stops. (And get Error 4, TF_E_INET.)

I do not understand why the tcp call is going there. The port value is good (4998) which is the port I try to reach on my server. I also use an IP address and not a server name (but also tried that with same result).

I used Wireshark to get more details. The only thing I see is that the DLL tries to reach the following IP address (which points to the faulty domain):http://networktools.nl/traceroute/67.215.65.132

This is not even the DNS Server IP address.

Maybe this can help you understand what is going out?

Best regards,Alexandre Leclerc

This is very odd. I haven't been able to reproduce this yet. Try use TA_SYSTEM from the TF_SaveServer(). See if that fixes it.

Also, is something preventing loopback addresses (127.0.0.1) on your machine? Perhaps a group policy or some filtering software? Your DNS should never be contacted for a 127.0.0.1 address.

Hi Wyatt,

Unfortunately, there is nothing special on my PC. Almost a bare-bone Windows 8.1 PRO, standard MS network (no group policy).

I made the test with TF_SYSTEM with no difference. It was not able to contact my server (not 127.0.0.1 for that test).

Best regards,Alexandre Leclerc

My gut feeling is that something on your network is blocking the request from the TurboFloat library. If it helps you: the data is "binary blob" data using TCP on the port specfied. Some overly "protective" firewall or router might reject the data because it doesn't "look normal". That is, it's not HTTP, FTP, or a well known format.

Also, are you installing the TurboFloat Server, or just running it from commandline? The problem might be that you're running it from commandline from an "un-elevated" user (someone without sufficient permission to "listen" for incoming traffic on the network),

Can you try something. Try activating & installing the TurboFloat Server on your development machine (12.7.0.0.1). Use the default config file -- only change the log file location to somewhere easy to find. Then use TF_SaveServer(L"127.0.0.1", 13, TF_SYSTEM) in your test app.

Then try everything again. Does it work?

If it doesn't work then we might have to arrange a time I can remotely help you out with this.

Hi Wyatt,

I'm not running from command line: I never was able to make it run that way (in elevated mode). The program quits. So I simply installed it (with elevated rights) for my tests.

I re-installed it locally with a new TF activation key with the default config file, except c:\tfs-log.txt for the logs. This way I have a TFS installation on our main server and on my local PC at the same time for testings.

I ran a new test in debugger mode and it failed with the same error (and same call sent to the weird address, but on port 13): Alexandre-W8.office:55877 -> hit-nxdomain.opendns.com:daytime

(Port 13 was/is? used for the old daytime protocol, that is why it shows as such.)

I remarked a very small detail but I don't know if it can be of help: the Version GUID is "78079 [...] 106". In my code I use this GUID, in LimeLM it is the same. Everywhere. BUT when I see the events in Process Monitor it shows as: "C:\ProgramData\TurboFloat\87079 [...] 106". Notice that the first two numbers are reversed!

Any-way, I decided to try the same code on another machine, WinXP. This time it was calling the TFS ont our server (to simplify the testing process). It resulted in the exact behaviour and error code and process monitor trace (except the port was 4998).

I made a final test by changing my DNS setting on my machine by forcing the default DNS serveur of our Internet Access Provider instead of OpenDNS. Results were differents: after an instantaneous call to RequestLease() I had the error 4. But with no TCP reconnect events in process monitor. So I'm persuaded that TurboFloat.dll is making a systematic call to DNS servers even when this is not required (it should not with IP addresses). I'm not able to get any trace on Wireshark.

I'm available any moment for remote support if you desire to do so. (For that, I'll send you my contact information at support@wyday.com after this post - but you can continue here too if you want.)

Best regards,Alexandre Leclerc

I remarked a very small detail but I don't know if it can be of help: the Version GUID is "78079 [...] 106". In my code I use this GUID, in LimeLM it is the same. Everywhere. BUT when I see the events in Process Monitor it shows as: "C:\ProgramData\TurboFloat\87079 [...] 106". Notice that the first two numbers are reversed!

That's expected. Nothing to worry about there.

I'm not running from command line: I never was able to make it run that way (in elevated mode). The program quits. So I simply installed it (with elevated rights) for my tests.

That shouldn't happen. Can you start an elevated command prompt then do the following:

1. Uninstall the TurboFloat Server instance from the computer (TurboFloatServer.exe -u)
2. With the same elevated command prompt run the TFS from commandline (TurboFloatServer.exe -x)
3. You might see a prompt from the Windows Firewall asking if you want to allow it to listen for connections. Click allow.
4. Does it run now? If not, can you tell me the output on the command prompt window.

If it does run, can you try connecting your app (or our test app) to the TFS (127.0.0.1, port 13).

I'm available any moment for remote support if you desire to do so. (For that, I'll send you my contact information at support@wyday.com after this post - but you can continue here too if you want.)

We're going to try using the OpenDNS servers on our test machines to see if we can reproduce this error. The DNS servers you use shouldn't effect anything.

So I'm persuaded that TurboFloat.dll is making a systematic call to DNS servers even when this is not required (it should not with IP addresses). I'm not able to get any trace on Wireshark.

TurboFloat always tries to resolve with the DNS servers. IP addresses should just be spit back at TF (it has on every one of our test machines across DNS configurations).

Hi Wyatt,

After much in-depth debugging and analyzing I found the culprit: a non-UNICODE string!

I knew I had to "speak" Unicode to TA and when implementing TF I did the same. But, I "forgot" about it when calling SaveServer(), using a standard strings. I realized the when I called GetServer() just to see what address TF was really calling. I only saw garbage. What's that? Oops! After a quick fix, I got my lease!

I made the test on our server on port 4998: worked great too. With OpenDNS too.

I'm glad all works and that this is not a problem in TFS!

Best regards and thank you for all your help.Alexandre Leclerc

PS: I would suggest to add Q&A section in the help with this kind of boring problems. It does not work, get an error 4? Make sure all parameters are sent in UNICODE in all function calls.

PS2: You are right, TFS works in command line with -x.

Great! I'm glad you got it to work. 😀