Proxies - or something like that

Hey Michael,

but LimeLM can't call home

What's the exact error?

I'm wondering - is this a proxy issue - it's quite likely that the customer has internet proxy and like (just trying to confirm that).

It might very well be a proxy issue. TurboActivate uses almost the exact same method as the AutomaticUpdater to get proxies (it's not exactly the same because they're written in different languages, for starters, and other small differences). Try letting the user pass in their exact proxy.

Are they using NTLM proxies or something like that?

Thanks for the quick reply.

#1: I don't know the exact error (!) but the only error I don't report into debug is "InternetException". Overnight we'll add that and get them to try again.

#2: They won't know their proxy settings (!) - "IT" will set that up for them; and so I can't ask them; it'll baffle them.

#3: Just found this on the WyUpdate help pages about proxies:" If the proxy settings in Internet Explorer are misconfigured, wyUpdate tries again without the proxy settings."

Does LimeLM do the same?(trying to work out what differences there may be)

If I do a TurboActivate.SetCustomProxy(string.Empty) will that be the same sort of action?

Thanks, Michael.

Does LimeLM do the same?(trying to work out what differences there may be)

Yes, TurboActivate does the same.

Morning Sam,

Our new version didn't work. That wasn't a surprise. It didn't log anything either. That was a surprise. More and more debug going in to find out why.

In the meantime we've remembered that TurboActivate EXE didn't work either! Guessing that uses similar code to the IsGenuine() check - so - where is it trying to get to and how? (i.e. what web address etc.)

We know that they can access "normal" web sites: they can use the LimeLM management site and then can use AutoUpdate to http://www.dyetech.co.uk/ADirectory/Update.zip - so basic internet access works...

Thanks, Michael.

Debug log; if it's of any use:

12/Oct/30 09:23:40:18815 CheckLicenseIsGenuine startingError 09:24:01 30/Oct/2012CheckLicenseIsGenuine InternetException

Connection to the server failed. at TurboActivate.IsGenuine(Boolean& needsReactivate) at FlowSizeTool.frmMain.CheckLicenseIsGenuine(Boolean bCloseIfNot, Boolean bSetProxy)

App Version 0.86.0.16202CLR 2.0.50727.5456OS: Microsoft Windows NT 6.1.7601 Service Pack 12012/Oct/30 09:24:01:34115 CheckLicenseIsGenuine finally

Tell the customer to "http://wyday.com/" into their browser. Tell me what they see.

My guess is they have filtering software that blocks wyDay. About 2 years ago a crummy "web filtering" company, Websense, automatically classified wyDay as a "hacking" site. We got it resolved quickly, however we've found that end-users that run old, non-updated filters might run into a problem accessing wyday.

Morning Wyatt,

OK; have been really scratching my head and doing loads of tests; here's the best summary I can come up with!

1. Web browsing is ok: they can get to your site. We know that 'cause they're using the LimeLM management interface to practise key issuing etc.2. AutoUpdate (wyUpdate) works fine from their PCs to my web site (http://www.dyetech.co.uk/theapp)3. License DLL fails with InternetException in IsGenuine()4. TurboActivate.EXE fails too - offers offline activation instead.5. It's their network; one of the testers is using a VPN; if he disconnects that it's all fine (i.e. via home broadband without the VPN). The other tester is "internal" so direct on network - can't do it at all.

(both testers have tried steps 1 - 4: same results for both)

*so* it's something on the corporate network that is stopping the application working; but not wyUpdate and not a web-browser.

I've got them to tell me their proxy settings using netsh winhttp show proxy - and there isn't one.

I've asked about a firewall - neither user remembers having to explicitly allow wyUpdate through nor being asked about TurboActivate - so it's probably not a local firewall issue. Why a corporate firewall would block TurboActivate but not wyUpdate; and why only the TurboActivate key stuff not the web site stuff I don't know.

Is it HTTP or HTTPS? Sorry, out of my depth with corporate firewalls and how they can work!

HELP! What I guess I need to find out is where the TurboActivate.EXE is failing - is the query reaching you or not? (so is it failing to send the request or failing to hear the response) and somehow begin to work out what is blocking it and why (and therefore how to get round it).

Really confused!

Thanks,

Michael.

Good afternoon,

Just finished a conference call with the customer about this; and they want to escalate to their IT team to "open a portal" or whatever to allow TurboActivate to work.

Given that a web browser works; what's different with TurboActivate? It's using HTTP... It's using the wyDay servers... It sends a POST request... And why does wyUpdate work? That uses a GET request...

I've looked at the HTTP headers and i notice that TurboActivate sets itself as a UserAgent; whereas wyUpdate claims to be Mozilla/5.0.

The other difference might be the content type - I guess the firewall could be blocking the content type used for TurboActivate?

Sorry, all stabs in the dark - I need to know what to say to the "IT" team; in terms they can understand; so they know what the issue is and what to do.

Any help at all appreciated!

Thanks,

Michael.

Hey Michael,

TurboActivate sends POST to "wyday.com/limelm/...", on HTTP using the user agent "TurboActivate / VERSION"

wyUpdate sends GET to "yoursite.com/...." on HTTP/HTTPS/FTP/FILE (or whatever you've chosen) using an impersonated Internet Explorer user agent.

So it sounds like they're either blocking POST requests or blocking unknown user agent requests. Also, they still might not be using the correct proxy. Tell them to explicitly pass in their proxy to TurboActivate. That's the first thing they should try.

Thanks for the response Wyatt,

Given that I can't find any proxy settings by using that netsh command I'm going to be a bit vague about that - though I have asked the specific question. Also wyUpdate works without any special knowledge of the proxy?

A firewall that blocks things is (to my mind) a more likely scenario. How difficult is it to give me a TurboActivate.EXE which impersonates IE? No guarantees; just a quick rebuild; so that we can test it?

Sorry; but I end up having to be proactive and try things rather than waiting for answers from an IT dept that might never happen!

(as they can fill in forms on web sites like LimeLM that implies POST is allowed?)

Thanks,

Michael.

We've put together a test version for you to try, and I've emailed it to you. Tell me if it works.

Thanks Wyatt,

It didn't solve the problem; but that's ok 'cause it eliminates a possibility.

Just wanted to record thanks for doing that so quickly - really appreciated.

Next stage is to try and get the corporate IT people involved properly. I'll post back as soon as I know anything; which won't be too long as this is a bit of a hot potato at the moment for them!

Ta,

Michael.

OK; total humble pie time probably.

It turns out (now "IT" are involved) that a proxy server is in use. However how this proxy server is working I have yet to find out; and it's obviously not working the "easy" way as TurboActivate can't find out - but wyUpdate can?

Sorry; really confused!

Thanks,

Michael.

OK; I've written a little console app to connect to the internet.It detects proxy settings and authentication required.The results are that it returns the proxy server in use and states that authentication isn't required.

So; back to square 1 really:

a. wyUpdate worksb. LimeLM (TurboActivate DLL or EXE) doesn'tc. these are to different web addresses but not sure that makes a differenced. I've been told that if you put the proxy server details into IE manually then TurboActivate workse. It's a fairly standard proxy http://proxy.country.company.com:8080/f. The proxy doesn't appear to require authentication

Dunno what to do next!

Thanks,

Michael.

d. I've been told that if you put the proxy server details into IE manually then TurboActivate workse. It's a fairly standard proxy http://proxy.country.company.com:8080/

Yes, putting the proxy into Internet Explorer should fix things. Or passing the proxy directly to TurboActivate.

Are you saying it now works?

If you tell me where they normally store their proxy details then we might be able to expand our proxy detection in TurboActivate.

Afternoon Sam,

We haven't solved the problem; unfortunately; but we've narrowed it down.

The IT people (who know things...) can get it to work by changing their settings in IE from auto proxy to a manually inputted proxy (they know what to put in there).

But that doesn't work for the vast majority of users who don't know nor care about proxy settings (they can't change their proxy settings, so are "stuck" with the auto detect).

We know that on their PCs without any changes:

a. wyUpdate worksb. TurboActivate doesn'tc. A web site access to the wyUpdate site or LimeLM does work

So there's some difference.

I've written a small test program (console) which successfully gets the proxy settings and appears to work ok. This is in .NET. I can send this over if you want; it's nothing special; just uses WebRequest.DefaultWebProxy.GetProxy().

I obviously don't know the code within TurboActivate.DLL / .EXE: but it's not (for some reason) reading the auto-proxy from IE.

I don't know what else to suggest - except some debug in TurboActivate that dumps to a file what it finds in terms of proxy etc. so we can see why/where it's not happy???

It *does* seem to be a TurboActivate issue; but I can't see why, as far as I know they're doing nothing special and straightforward .NET code seems ok?

Thanks,

Michael.

If you could send us the autoproxy script they're using that would be helpful. TurboActivate does work with auto proxy, however it rejects incorrect and buggy auto-proxy scripts (wyUpdate / .NET is more forgiving).

If you could send us the script they're using we could modify TurboActivate to be more flexible.

Also, whether the customer uses manual proxy setting or auto-proxy scripts, these must bet set so Internet Explorer can read them. They can't take any shortcuts like writing directly to registry or anything like that.

If they are taking shortcuts please tell me what they are so we can evaluate whether to modify TurboActivate to account for them.

Evening Wyatt,

All working - by using .NET to detect proxy and pass the detected value in to the CustomProxy setting; and add to the command line for TurboActivate.

I can send you the .NET code if you want; it's nothing special; based around an article I found on the internet about detecting proxies, authentication etc. Just encapsulated in a class I can call and that's that, done...

I have asked (a couple of times) if I can be told details of their proxy configuration script so that I can see why it doesn't work for LimeLM.

If you're using WinHttpGetIEProxyConfigForCurrentUser then this returns blank in my tests (wrote a small console program to test things out; both the .NET way and that way).

So; working = good; bit of a hiccup but we've learnt a lot. Ideal if the .NET code I've done wasn't required (c.f. wyUpdate) but it works. Rolling out to a wider test audience as we speak.

Thanks for all your help; I'll post back if I get any details of the proxy script.

Michael.

Ok, thanks for the update. If they do get around to telling you how they setup their proxies please pass it along so we can see what's going on.

Good afternoon Wyatt,

Just feedback on this - once we'd implemented our own proxy detect code things worked; and have worked ever since. We've never managed to get hold of their proxy configuration file.

So it's a problem that "went away"...

Thanks,

Michael.

Hi

Did you ever fix TurboActivate to get automatic proxy settings?I just got a customer who can't activate his software.

Kind regards,Viktor

We have no known problems with automatic proxy configuration. If you have a problem with it you need to provide us with a lot more information. Preferably a way to reproduce the problem. Or, if not that, then at least the proxy configuration used by the customer.

OK, thanks for your reply.

We did not want to go through the hassle of getting more details from the customer,we only want him to be able to run our software, so we gave instructions for manual activation instead.

If this happens with more customers we will investigate this further.

/Viktor

Hi,

One of our customers has a floating license, it's activated on the server, but a client machine does not work well in a certain conditions. When they restart our product just after they close it, they can't get the license from the server with the error message as following : "Connection to the server failed".

They checked the followings for this issue.1. The connection between server and client by ping.2. The server service is running.3. Other client machine does not work well too with same message.

Could you please help us to get it resolved.

Best,

"Pinging" the IP address is not enough. There's also the port. Namely, the TFS must be installed on a machine, then the firewalls / anti-malware / etc., must all be configured to allow that TFS service to get incoming requests on the port you specify.

Also, this question really has nothing to do with the topic. The topic has to do with proxy misconfigurations. TurboFloat does not use proxies at all. It always makes direct connections. And if it can't make a direct connection then it will return TF_E_INET.