Customers can't connect to verify the license (Australia / New Zealand)Solved

Have them run wyday.com in Internet Explorer (not Chrome, not Firefox, not anything else). Does it work? It will likely show an error (proxy, firewall, something else).

Make sure they whitelist your app in their firewall. They might be inadvertently blocking your app from contacting the servers.

So I got back in touch with the customer (they live in another timezone so it's a bit difficult) and we run more tests. It connects without problems to wyday.com, I can't call deactivate (error code 4 again).One thing I would like to try is to remove all the licensing information from customer's computer and try a fresh start, can you tell me what do I remove to achieve that?

Any other ideas? It seems the Internet connection is working flawlessly on the customer's computer but TurboActivate can't connect to the server. It really does look like a problem in TurboActivate right now as we tried to switch off all the antiviruses/firewalls/Windows Defenders on customer's computer, they can connect to all the sites etc. Please help!

This just happened to another user. They have no 3rd party Firewall/Antivirus installed, they have disabled Windows Firewall and they can easily reach wyday.com (from Internet Explorer as well).They are on Windows 8 and I've verified facts about antivirus/firewalls myself (we screenshared and they showed me).

It really does look like a problem with TurboActivate at this point. Both users are located in Australia btw but I guess this is just a coincidence.Please at least let me know how to clean the computer from all TurboActivate stuff so we can try a fresh start. As you can imagine the issue is quite annoying to the users and stressful to me so I would appreciate quick help on this one.

I thought that another possibility is that maybe they have some kind of malware and the responses from the server are misformed. Is there any kind of debug mode so I can if anything is getting through/back?

It really is strange as Internet connection is working well for everything else on their computer. Any list of things to check? Blocked ports? Proxies? I mean from the user's perspective it just randomly stopped working after working for several months (and as time between checks is 7 days it successfully verified the license many times in the past) and I am positive it's not firewall/antivirus blocking anything.

Maybe at least you could provide some description of functions TurboActivate uses for Internet connection so I can try writing a test program using something similar to see if it works? If I ping http://wyday.com from within the app successfully would it rule out connection problems?

Honestly an "Internet error" (error code 4 -- all error codes and their number, descriptions, etc, are listed in TurboActivate.h) is just TurboActivate's way of saying "I sent stuff the servers and I didn't get back a valid response". The reason why could be a million different things.

If they can get to wyday.com from internet explorer, and your app is not being blocked by whatever firewall software might be on the computer, then something else on the network is misbehaving.

Use WireShark to see where the mis-configuration is on the customer's network.

I sell software to non-business customers who are usually not computer experts. Making them to install WireShark and give me valuable information is quite a bit to ask for.

The problem is that everything else works but TurboActivate doesn't. If there was some way to at least know what is happening (is there no response? misformed response?).Again, could you tell me what to do to remove all TurboActivate information from a computer so we can try a fresh start? Maybe it works then or at least we can rule out that the information got corrupted.

It's frustrating because TurboActivate is a black box which just says "network ok"/"network not ok" without giving any useful information. I am also not very comfortable with a situation where we can't send you back any useful debug info and we must just assume there are no bug in TA. I mean, for example if there was a way to log the communication with the server then it would clear things up quite fast.

>> "The problem is that everything else works but TurboActivate doesn't."

That's a key bit of information (unless by "every else" you just mean browsers -- and not other applications that also talk to servers). TurboActivate uses it's own user-agent string (it doesn't "fake" being Internet Explorer). That might be the problem, especially if the customer has misconfigured proxies, firewalls, switches, or routers.

In TurboActivate 4.0, rather than using the typical user agent we've previously used -- TurboActivate / VERSION (https://wyday.com/limelm/) -- we're spoofing the Internet Explorer user agent. We've recently made this change to remove this variable. And because customers do stupid things like configure their proxies to reject certain user agents. And because a handful of proxies crash on "non-spoofed" user agents.

User-agents are effectively useless, but that's another story altogether.

>> "It's frustrating because TurboActivate is a black box which just says "network ok"/"network not ok" without giving any useful information."

There's not a whole lot TurboActivate can provide more than "I could talk to the servers" or "I couldn't talk to the servers". TurboActivate is typically used from from low-privileged processes, and it's happening on a single computer. In other words, TurboActivate doesn't have the access to know what could possibly be failing in the network. All it knows is the network is failing. It doesn't know *where* in the network it's failing. And it doesn't not *why* it's failing in that particular part of the network. It wouldn't have access to that information even if we added that type of diagnostics to TurboActivate.

That's why we recommend using WireShark. It lets you see the whole picture (a picture that's just not visible to TurboActivate).

>> "gain, could you tell me what to do to remove all TurboActivate information from a computer so we can try a fresh start?"

This won't help. The problem isn't the files on the computer. The problem is TurboActivate cannot successfully get a response from the activation servers because their network is misconfigured. The solution for a customer that doesn't know how to properly configure their network (beyond, say, having them hire proper network admins), is for them to use offline activation: http://wyday.com/limelm/help/offline-activation/

Email me and I'll tell you what files to remove (tell me the version of Windows, version of TurboActivate, your Version GUID).

Thank you for your reply, that clears things a bit.

>>This won't help. The problem isn't the files on the computer. The problem is TurboActivate cannot successfully get a response from the activation servers because their network is misconfigured

Let's assume the TA info (w/e it saves locally) got corrupted, is it 100% that ERROR code 4 won't occur then?I mean I would just really like to know if it's getting any response and it's invalid (which could occur if it sends corrupted info or if some malware or say ISP injecting some ads or something else to it) or if it just doesn't get any response from the server (which could suggest some messed up proxy settings or likely some malware).

>>That's a key bit of information (unless by "every else" you just mean browsers -- and not other applications that also talk to servers)

My customers have a lot of software that talk to servers installed as a rule because it's needed in the niche.

>>There's not a whole lot TurboActivate can provide more than "I could talk to the servers" or "I couldn't talk to the servers".

Yeah I get it. I just want to know if it's getting an invalid response or no response at all as that would help to narrow down the problem.

Most of my customers don't configure any network settings. They just click "connect" and then update Windows when prompted. They of course do stupid stuff all the time (like downloading malware or some nonsense antivirus programs but they are not setting proxies or anything of the kind).

>> is for them to use offline activation: http://wyday.com/limelm/help/offline-activation/

Yeah, that's a good idea. If I can't get it solved with them I will send them an offline activation, hopefully it can work if there is already a normal one made.

>>Email me and I'll tell you what files to remove (tell me the version of Windows, version of TurboActivate, your Version GUID).

Ok, I will email tomorrow with that information. Thank you very much!

I've just found out that another customer who requested a refund was from Australia as well.That makes it 4 people already. It really seems that TA has problems with something local to Australia at this point. My wild guesses are:

-some timeout settings which are too small if they try from Australia-ISPs there blocking communication to wyday.com in some way (but they can reach it from Internet Explorer and they can ping it without problems)-ISPs there inserting something to http communication?

At this point I am almost sure it's about them being in Australia as it works for some 2k+ people around the world without many problems. Any ideas what could be done to investigate it?

>>In TurboActivate 4.0, rather than using the typical user agent we've previously used -- TurboActivate / VERSION (https://wyday.com/limelm/) -- we're spoofing the Internet Explorer user agent. We've recently made this change to remove this variable. And because customers do stupid things like configure their proxies to reject certain user agents

Could it be the reason? Could ISP do that on their level? (The customer didn't change anything themselves and there are 4 of them already all from Australia). I mean it would be very useful if TA at least logged the http response it gets. Is it a timeout? Is it an invalid response? Is it 403?I mean, it really isn't user's fault and they didn't "misconfiguring the network". They live in major Australian cities and the connection is not going through. As all other services work for them it looks like something in TA which is causing this.

So I am reading that some Australian DNS services are very slow lately. Is it possible that it causes timeouts?Any more information about how TA connection works (what kind of http requests it sends, timeout settings etc.) so we could guess what the problem is?

>> "Could ISP do that on their level?"

Yes, but I've never seen or heard of an ISP doing that. Doing stupid things based on the user agent is typically reserved for poorly informed IT admins.

>> "So I am reading that some Australian DNS services are very slow lately. Is it possible that it causes timeouts?"

TurboActivate uses a 60 second timeout for DNS requests. That might be the problem. There are a number of internet connectivity improvements coming in TA 4.0. So, the bug (whatever it is) might've already been fixed. But we have no way of knowing. We need more information. Preferably a way to reproduce the bug. But using WireShark and showing us where the error is happening is the best way to give us useful information.

>> "I mean it would be very useful if TA at least logged the http response it gets. Is it a timeout? Is it an invalid response? Is it 403?"

We'll consider adding more diverse internet error codes to a subsequent version. I can tell you it's not a 403 (or any valid error code from our side of things).

Also, if the error appears immediately then you know it's not a timeout.

Regardless of what we output (or even could output) the only way to find the real cause is to dig into the communication to/from the servers. Remotely connect to your customers and use WireShark to see the communication and see where it's failing.

>> "-some timeout settings which are too small if they try from Australia"

Our timeouts are insanely large (every stage has a diferrent timeout value -- 1 minute for DNS, 5 minutes for communication from the server, etc.). More than long enough to traverse the world several thousand times on well-configured networks.

>>Our timeouts are insanely large (every stage has a diferrent timeout value -- 1 minute

Yeah, it can't be the timeout.

It looks like some kind of Heisenbug though. I got the customer to install Fiddler (http://www.telerik.com/fiddler) to log the http communication and it turned out the activation worked with that running.We turn off Fiddler and it couldn't reach the server anymore (we tried to deactivate). Switch Fiddler on again and again we got it working.

I am not sure if it's Fiddler or TA which is inserting User-Agent header but the logged (working) request looks like that:

POST http://wyday.com/limelm/api/rest/ HTTP/1.1User-Agent: TurboActivate/3.4.6.0 (http://wyday.com/limelm/)Host: wyday.comAccept: /Accept-Encoding: deflate, gzipConnection: Keep-AliveContent-Length: 427Content-Type: application/x-www-form-urlencoded

method=limelm.activation.isgenuine& (long message edited out by me)

Could it be that some proxy used by user's ISP doesn't work with empty User-Agent and that Fiddler is adding that to the request and makes it work? (Just guessing here as I am quite clueless about networking)

I have dug around a bit and it seems that Fiddler magically fixing various issues is a common case. Some links that may give some light:

1)http://www.telerik.com/blogs/help!-running-fiddler-fixes-my-app-

Many possible reasons

2)http://stackoverflow.com/questions/21481682/httpwebrequest-the-underlying-connection-was-closed-the-connection-was-closed/21487464#21487464

Someone explaining a bug in Net Framework causing issues (which running Fiddler fixes); it's about closing connections (maybe the LimeLM server doesn't keep the connection alive for long enough; someone mentioned issues with redirect and keep-alive as well)

3)Apparently it might a certification problem as well (Fiddler negotiates it by itself and thus may make things work).

It worked for another guy as well.I am assuming it's one of the bugs mentioned in the article I linked present in TA and for now I am recommending my customers to install Fiddler to make the activations work.

I am not sure how to go around reproducing, I guess maybe trying a VPN from Australia or inserting artificial delays could work. I think anything on the user's side or ISP side is ruled out now though.

Hmmm... this is a tricky one. Our servers are configured correctly. Unfortunately "fiddler is magic" is not really a good answer, or all that useful. It's a nice short term fix, but not really a permanent solution.

It really would be most useful if you were able to log in remotely to one of these customers and get a WireShark log of all the data/to from the computer when activation is happening. WireShark doesn't do "magic" like fiddler does (in other words, it doesn't interfere with the behavior of the program).

And, although those articles are nice, they don't get us a whole lot closer to understanding the problem with any specificity. Maybe "slow proxy determination", but from what it sound like the customers aren't using proxies. The other solutions on that blog post don't apply.

I've made WireSharks logs with the customer, one with a filter (with IP of wyday.com, the one I've sent you) and one without any filters. It seems that TCP handshake fails (wyday.com keeps sending packets and never gets a reply).The error code 4 appears instantly so I doubt it's firewall (because then it would wait for a timeout?). Maybe the port is closing for some reason? Is it safe to eliminate firewall as a reason because of speed at which error code 4 is returned?

Tell them to retry now (we've disabled the nagle algorithm on our servers, and for the next version of TurboActivate we've also disabled the nagle algorithm client-side -- the algorithm offers no benefit in our use-case). If it doesn't work, then also tell them to disable the "delayed ACK" feature in Windows: https://support.microsoft.com/en-au/kb/328890

Let me know which fixes things. If it's the first (just retrying the activation), then you're good to go, if it's the second, then we've worked around shoddy configurations to get everything to work in TA 4.0 (out soon).

Got the same issue here.

Also from Australia.

About a week ago my three clients apps stopped working.

TA works on its own but not from within the app.

I checked with previous working versions - they also stopped.

We're going to release TA 4.0 (very very soon). And then we'll ask our users to upgrade to the latest version and reconfirm. Something funky is going on with some Australia / New Zealand networks very recently. I have no idea what has changed.

I do know we've significantly improved our handling of misconfigured networks in TA 4.0, so hopefully that will solve it. If it doesn't we'll dig into it more deeply.

In the meantime, have them activate offline: http://wyday.com/limelm/help/offline-activation/

Wyatt wrote:> Something funky is going on with some Australia / New Zealand networks very recently. I have no idea what has changed.

It's a farce: https://en.wikipedia.org/wiki/Internet_censorship_in_Australiahttp://www.smh.com.au/technology/technology-news/how-asics-attempt-to-block-one-website-took-down-250000-20130605-2np6v.htmlWe have grand plans for a National Broadband Network but that has descended into a farce of budget overruns and technology compromise: https://delimiter.com.au/2016/06/21/fact-check-turnbull-misleads-qa-audience-nbn/ - it is rife with politicking, rorting and incompetence.

It might be interesting to see if these problems are on the Telstra cable network, they tend to have some weird issues. The standard issue modems for that don't pass things like VPN and Telstra tend to tweak things without telling anyone. They've had a spectacularly #FAIL of a year (they are usually the most solid ISP, they are the national telco).

I just tried it behind an NTLM corporate productivity firewall via Fiddler4 in Sydney and it was ok. It never works without Fiddler but I assumed that was an NTLM thing they do here to stop you doing anything useful.

FYI the alpha geek hangout for broadband discussion in Australia is https://forums.whirlpool.net.au/

I'm having a similar problem with TA returning error code 4.

What is the exact host they need to be able to access for licensing? Is it just wyday.com? Not www.wyday.com or something else?

@CADbloke

Man, that's depressing. It seems like a lot of the Internet infrastructure around the world is held together by duct tape and prayers.

@sohail

The standard debugging principles hold for this. That is, you need to give us a whole lot more information for us to help you. If you're getting TA_E_INET (return code 4 is TA_E_INET, see TurboActivate.h) there's a 99.99% chance it's because the customer has a restrictive internet policy (i.e. blocking all traffic or all but a set of whitelisted domains/IPs) or they're doing something stupid. In either case the way to test this is documented many many times on this forum:

On Windows:

1. Open Internet Explorer. Type "http://wyday.com" in the browser window. Does it work? If not, there's your problem. Stop and fix it. Next, try "https://wyday.com" in that Internet Explorer window. Does it work? If not, there's your problem. Stop and fix it.

Don't use Firefox. Don't use Opera. Don't use Chrome. Always use Internet Explorer for that test. Why? Because TurboActivate uses the same proxies that Internet Explorer uses. So if the customer screwed up the proxies you'll be much more likely to see it in Internet Explorer.

2. If contacting https://wyday.com and http://wyday.com both work unmolested in Internet Explorer (i.e. no junk being inserted into the communication) *and* TurboActivate is still returning TA_E_INET in C/C++ or throwing and InternetException in another programming language, then you can be fairly sure the problem is on that computer, and not in the LAN or the wider internet.

What's that mean? It's a firewall. Or an anti-virus/anti-malware program. Or some other junk on the computer blocking or "filtering" communication to/from your app.

How do you fix it? It depends. The quick solution: disable the junk. Turn off the firewall. Turn off the anti-virus/anti-malware junk. Try it again. Does it work? If so, you found the source of the problem. Now you just need to figure out how to configure the firewall/anti-virus/anti-malware to add your app and/or TurboActivate to their whitelist (or exclude it from whatever filtering that/those program(s) are doing).

For Mac OS X / macOS:

Follow the instructions above, but replace "Internet Explorer" with "Safari"

For Linux:

For the instructions above, but replace "Internet Explorer" with whatever browser you happen to have.

Did you follow the instructions above and TurboActivate is still returning TA_E_INET? Now it's time to break out WireShark and give us logs of the communication to/from your app so we can see where things are going off the rails.

I have a hunch that you found this topic but it doesn't actually apply to you. Hence my instructions above.

>>Turn off the firewall

I just want to point out that turning off Windows Firewall doesn't actually turn it off for all case. It's safer to add relevant exceptions first as it can still block the communication when turned off (crazy I know but google it).

Wyatt wrote:> @sohail> > The standard debugging principles hold for this. That is, you need to give> us a whole lot more information for us to help you. If you're getting> TA_E_INET (return code 4 is TA_E_INET, see TurboActivate.h) there's a> 99.99% chance it's because the customer has a restrictive internet policy> (i.e. blocking all traffic or all but a set of whitelisted domains/IPs) or> they're doing something stupid. In either case the way to test this is> documented many many times on this forum:

The user in question is one among a few who is using the application on their site but this one particular guy is the only one having problems. Crucially, he is not in the technical part of the company so I suspect network configuration based on user role is the issue. I've spent about an hour with the customer trying to narrow it down to being LimeLM. I previously thought it was hardware. The symptoms:

1. Hanging in some curl call (I took a sample through Activity Monitor when it was hanging)2. Error code 4

Before your response, I have already asked them to check wyday.com in Safari, just waiting to hear back. It sounds to me like this will ultimately be the issue.

It's a good idea to spoof the IE/Safari/Whatever user agent.

I appreciate the time you took to list out the standard debugging steps. I think I'm in the right thread, however.

I played around with it using VPN connections from various places as well as tools to introduce artificial delays.Delays (either in sending or receiving) aren't the reason for this problem. For example with delays there is a long pause until error code 4 appears while in my case it appears instantly. It really does look like TurboActivate gets the TCP/IP packet but doesn't understand it and produces an error.

It would be very helpful if there were debug mode so we could at least know if the packet gets there although with how fast it happens it seems there are only a few possibilities:

1)TurboActivate tries to read info from the socket and gets an error (socket closed, EOF, I don't know what)2)It in fact gets the TCP/IP packet but can't parse it and produces an error3)it gets re-tranmission packet very fast after the first one and is unable to ignore it

It would be easy to say if there was an option to log what it gets available. The we could:

1)be sure TurboActivate is the problem if it gets the packet but doesn't respond2)be sure user configuration is the problem if TurboActivate doesn't get the packet

Again, 2) is very unlikely because there would be delay, not instant response with error code 4.

>> "1)TurboActivate tries to read info from the socket and gets an error (socket closed, EOF, I don't know what)2)It in fact gets the TCP/IP packet but can't parse it and produces an error"

That's what it sounds like. What would be ideal is a way to reproduce this. We haven't been able to reproduce it anywhere where we have developers (and not for lack of trying).

Also, like I said above, we're close to the TA 4.0 release. When it's out we're going to have you test again on this malfunctioning networks. If it doesn't solve it we're going to need access to a computer on a network that is showing this behavior.

I am unable to reproduce it as well and unfortunately all my customers to whom that problems happened are not very technical and really are just happy with workaround. I am thankful to them that they at least agreed to run those WireShark logs. If I ever get more technical/keen on cooperating customer having this error I could give you full report.

Another thing I (or maybe other people with this problem) could do is to run a test version with debug info from the affected computers. If you would like to do that, let me know 🙂

We also have a large number of users in Australia and New Zealand that have encountered this problem. It's quite disappointing to find out that 2 very large countries are not currently able to activate using this product.

Can the developers please chime in on what options are available to work around these issues? We have already performed detailed troubleshooting with several of these customers, and oddly enough, we are able to access many other sites successfully from our software - it's just the turboactivate servers that don't seem to be reachable.

And please don't just ask us to wait for the 4.0 version. We've been hearing that for 6 months now. What solutions are available for today's customers?

>> "We also have a large number of users in Australia and New Zealand that have encountered this problem. It's quite disappointing to find out that 2 very large countries are not currently able to activate using this product. "

This is a new problem caused by some weird configuration issue by some ISPs on those 2 countries. These issues didn't exist before a month or so ago.

>> "And please don't just ask us to wait for the 4.0 version. We've been hearing that for 6 months now. What solutions are available for today's customers?"

Solutions are already discussed in this topic.

Solution 1: Use offline activation for customers effected by this as a temporary workaround.

Solution 2: Use fiddler for customers effected by this as a temporary workaround.

Permanent solution #1: When TurboActivate 4.0 is out, just use that. Among other things we significantly improved it's ability to handle faulty misconfigured networks.

Shoot me an email and I'll send you a link to a test version 3.4.7 which has the new networking code from TA 4.0.

Email me at wyatt@wyday.com and I'll send you the link of TA 3.4.7 to test for these customers. If it works, then we'll push it live to all customers. If it doesn't work we'll need access to someone's computer who is getting this problem.

I'm having the same problem, something has changed on the wyday side of things. I have used TurboActivate for 3 years with no issues and today all of my users that run the software on a VPS are getting an IsGenuineResult.InternetError response when a call to IsGenuine is made.

We can also confirm what others have said. Turboactivate appears to be completely broken for all customers in Australia and NewZealand. We have had dozens and dozens of customers in the last week come to us complaining about activation problems on Windows and Mac computers. There does not appear to be any way to fix it, so if you have any customers in these 2 countries, avoid using turboactivate until this is fixed.

Unfortunately, this also creates an extremely negative situation for our company, since we are the ones who have to explain why all customers in these two countries are not able to install our software. We have also had significantly increased customer support needs as a result of so many new upset customers.

For everyone's sake, let's hope this get's resolved much faster than the 5 months we have all been waiting for the much promised v4.0... frankly, I completely ignore any comments about that version at this point since it has literally been promised for months and we need a solution that works today, not half a year from now

Hey Eric,

I'm sorry you've been having problems. We're looking into this. Shoot me an email and I'll send you version 3.4.7 with the new networking code.

But first, have one of these customers try again. We've recently (in the past 12 hours) updated our DNS entries and IP addresses to mitigate a DDoS attack. That problem is solved, but the solution we took might also fix your customer's problems.

Make sure the customer's DNS is not caching one of our old, now-defunct, IP addresses. For example "97.107.142.53" is now a dead IP address.

>> "Turboactivate appears to be completely broken for all customers in Australia and NewZealand"

The problem was only effecting a subset of customers in those countries. Please try again now (after making sure they have the updated DNS entries)

---

@triplegang

Make sure your customers DNS servers are refreshed. We recently changed IP addresses to mitigate a DDoS attack. Read about it here: https://wyday.com/blog/2016/ddos-mitigation-and-expanding-our-servers/

It looks like the libraries on the website is still at 3.4.6. If the 3.4.7 libraries are still untested and unfinished, we can't afford to put them into our products. We need a production-ready solution that will work for Windows and Mac. Please verify if these new libraries are fully tested and which exact platforms you have libraries for.

We still have many customers that are still having problems with this issue, so the IP address change did not resolve it. Unfortunately, even if it's just part of Australia and New Zealand, it seems to be quite a large part, as we have been asking users where they are located, and it covers a very large part of both of those countries. Again, this is a very serious issue for us, as there is currently ZERO way for these customers to activate our products (we do not allow offline activation). This is extremely frustrating 😈

Did you try asking them to install Fiddler and activate when it's running?This workaround works for my affected customers.

Yes, we have tried, but many customers refuse to install an entirely different application just to be able to activate ours. It has caused many many very upset customers, and rightfully so! Can you imagine if you purchased a software product and spent several hours just trying to get it to activate? Finally, the best advice they can give you is to go install a completely different program without any other possible fix or explanation? I would return the product immediately if that was me, and many of our customers have done exactly that.

We have several different products, and many of them use various APIs for different tasks. With every single affected customer we have worked with, our software products can communicate with every other API except for wyday. It is literally the only one that doesn't work. So it isn't some generic thing that affects these countries as a whole. It's a problem with wyday specifically.

Being told that v4.0 was coming for almost 6 months is already worrisome, but now adding this on top makes me very worried about the future of turboactivate.

>> "If the 3.4.7 libraries are still untested and unfinished, we can't afford to put them into our products."

The only thing changed between 3.4.6 and 3.4.7 is the networking improvements that are in 4.0 (which have been very heavily tested).

The only thing holding us up from releasing 3.4.7 is whether it actually fixes the problems some Australian and New Zealand customers are experiencing. And to know that we actually need confirmation. We haven't been able to reproduce it ourselves (and we've even tried directly from a couple networks in Australia, with everything working exactly as it should work).

That's a long way of saying, please email me, I'll send you a link to 3.4.7 and have a customer that is having this problem try it out. If that doesn't work then we'll need access to a customer's computer that has this problem.

>> "Being told that v4.0 was coming for almost 6 months is already worrisome, but now adding this on top makes me very worried about the future of turboactivate."

4.0 is a unique case: a lot of necessary improvements to the backend to handle the high-load of verified trials delayed the release of 4.0. Much more than we anticipated.

Future release won't have anywhere near the same amount of delays. This was unusual, and not the best way to handle the big release.

At any rate, shoot me an email at wyatt@wyday.com and I can send you the link for 3.4.7 so you can test it with a customer that is having this problem (and that didn't already rule out configuration issues on their end: https://wyday.com/forum/t/3358/customers-cant-connect-to-verify-the-license-australia-new-zealand/#post-16490 )

>>The only thing holding us up from releasing 3.4.7 is whether it actually fixes the problems some Australian and New Zealand customers are experiencing.

I will drop you an email asking for it but I can't promise I verify it as I don't have that many customers in Australia/New Zealand and not all of them get this issue (I think it was 4 people total as of today, all of them happily installed Fiddler). When I get someone on the line I will ask them to test it though.Now, if you could make a test version which doesn't deactivate when Network interface is disconnected that would be fantastic 🙂

Wyatt wrote:> The only thing holding us up from releasing 3.4.7 is whether it actually fixes the> problems some Australian and New Zealand customers are experiencing. And to know> that we actually need confirmation.

I can confirm that 3.4.7 fixed the problem for one of our customers in Australia. So nothing should be holding you back now. Please let us know when the release is actually finalized with full Mac and Linux installers.

>> "Please let us know when the release is actually finalized with full Mac and Linux installers."

The 3.4.7 release will be for Windows-only. This "Australia" bug doesn't effect Mac and Linux (we've had no reports for those platforms).

We'll get it out either tomorrow or the day after.

Wyatt wrote:> The 3.4.7 release will be for Windows-only. This "Australia" bug doesn't effect Mac> and Linux (we've had no reports for those platforms).

We have had users affected by this on the Mac, so consider it reported. Others in this thread have also mentioned affected users on Macs. So not sure what you mean by "not reported".

Wyatt wrote:> This is a new problem caused by some weird configuration issue by some ISPs on those> 2 countries.

If this is the cause, why would there be ANY reason to think this would be Windows-only? An ISP issue would affect any computer, regardless of the operating system. And you now have multiple people on here confirming this exact fact.

>> "We have had users affected by this on the Mac, so consider it reported."

Ok. We'll do builds for all the platforms.

>> "If this is the cause, why would there be ANY reason to think this would be Windows-only?"

Because (a) the network stacks are different on each platform and (b) networking is complex.

>> "And you now have multiple people on here confirming this exact fact."

We still don't have any logs from Linux or Mac OS X showing this problem. Yes, people are reporting TA_E_INET on those platforms, but 99.99% of the time that's because the customer messed up their internet settings and/or are actively blocking your app from accessing the activation servers.

But we'll just play it safe and release 3.4.7 on all platforms just to eliminate the possibility of this bug (and close this issue for good).

We've just released TurboActivate 3.4.7 for Windows and Mac OS X. Linux is still at 3.4.6 because (a) we've had no confirmed reports of this problem on Linux and (b) backporting the 4.0 networking changes to the Linux version is holding up the 4.0 release.

https://wyday.com/blog/2016/turboactivate-3-4-7-is-out/

We already have several customers from these countries using Linux that are getting these exact same error messages. What are we supposed to tell them? Apparently you only prepared Windows and Mac libraries, even though the issue obviously affects Linux as well, correct? Are we supposed to just continue waiting many more months for the promised version 4.0??

>> "We already have several customers from these countries using Linux that are getting these exact same error messages. What are we supposed to tell them?"

Ok, we just released 3.4.7 for Linux. You can get it on your API page: https://wyday.com/limelm/api/#turboactivate

>> "Apparently you only prepared Windows and Mac libraries, even though the issue obviously affects Linux as well, correct?"

We hadn't had reports of this problem happening on Linux. We're in a rush to get TurboActivate 4.0 out, so I made a judgement call (save 15 or 16 hours backporting the networking code for Linux and apply that to get TurboActivate 4.0 faster).

>> "Are we supposed to just continue waiting many more months for the promised version 4.0??"

I'm sorry for the delays. Once 4.0 is out we're changing the process in which large changes are rolled out so we're not in the situation again.