Web Deploy: Majority of installations fail (Source file not found)

[instrumentally]

I recent started an email campaign to notify contacts of the availability of a new software product of mine. Hundreds of emails were sent out and I've received dozens of responses in the way of attempts to download the software product. This product's installation is created using the latest version of Setup Builder using Web Deploy.

When the installation is compiled, all goes well. The code is signed and the files are uploaded to our local server.

I can download and install the stub/deployment just fine. (But then again, I am only 10 feet away from the server, so packets have a short distance to travel).

The problem is that the majority of email recipients who successfully download the EXE stub and then launch it encounter "Source file not found" error messages at various stages of the install. There are 307 .bin files associated with the deployment stub. But rarely does anyone successfully get all 307 files without getting the dreaded "Source file not found" message. Some users get the error with _00002.bin. Others with _00005.bin. Others at _00053.bin. Etc. The only common thing between all the users is that they never get all the way through the installation.

This has turned out to be a disaster. According to the LOG file, 8 out of 8 different users failed to complete the web deployment.

The hosting server is a Windows 2016 server running IIS.

I feel that I will need to give up on using the web deployment method since this is killing the resources we put into the email campaign.

[linder]

Hello,

unfortunately, or fortunately, it is not caused by SetupBuilder at all. And nothing changed in the web module for years. It's definitely a problem on your end, I am sorry :-( Web Update and Web Install work absolutely rock solid. It powers tens of thousands web updates and web installs without any problem.

I am sorry you have to give up on web install. I am sure it's just a configuration problem on your server. "Source file not found" means the file was not available when the web update clients requested it. Perhaps you can see in your server logs what caused this.

BTW, our own web install for SetupBuilder (it's the same module you are using) handled quite a few thousands web installs during the last 48 hours.

Friedrich

[linder]

By the way, if you are interested, please send me your stub and I'll test it from our machines. We are quite a few thousand miles away (but in fact, this does not make any difference). Perhaps we can see where your server has a problem.

But I can guarantee it is not caused by SetupBuilder. 300 cluster files is a simple and small project. There are Web Updates and Installs with 2000+ files out there serving 10,000+ customers. So unfortunately, there is nothing we can do from the SetupBuilder side :-(

Friedrich

[linder]

I see you already had this same problem in August 2018:

http://www.lindersoft.com/forums/showthread.php?47842-File-cannot-be-found-yet-it-can-be-found&p=89460#post89460
http://www.lindersoft.com/forums/showthread.php?47842-File-cannot-be-found-yet-it-can-be-found&p=89471#post89471

IMO, your issue is caused by a server configuration problem. "Soure file not found" is identical to a typical "404 Page not found" error. This error message is a Hypertext Transfer Protocol (HTTP) standard response code to indicate that the client was able to communicate with the server, but the server could not find what was requested.

Perhaps a typical "load balance configuration" problem.

Friedrich

[linder]

Hello again,

okay, please have a look at the attached screenshots. I have a full video of it if you are interested. I ran your Web Install and I am thousand miles away, located on another continent. There was not any problem - SetupBuilder installed (from the web) all your files successfully.

That means, your server was not under heavy load and was able to handle all requests. There was no "source file not found" / "404" error. Your product is ~400 MB, so perhaps your server can't handle the traffic if multiple users are downloading concurrently?

By the way, after reviewing your installation scenario, please allow me one question: why are you using Web Installation at all? As far as I can see, you always install all files. End users frequently do not need all the files contained in an installer (e.g. for updates). The Web Installation technology simplifies the user experience by first downloading a small "smart" installer which can retrieve just the pieces needed for the user's specific requirements. But if you always install all files, why don't you simply create a single-file setup.exe? I really do not see any advantage by using Web Installation in your specific case. Perhaps I am missing something.

And to work around your server issue and to stop the "source file not found" problem immediately, just unmark the "Enable Web Installation" feature in your SB project and recompile. SetupBuilder will generate a single-file installer with the same .exe name. Upload it to your site and you are done.

Friedrich

[instrumentally]

This issue has occurred with two totally different IIS servers. The issue existed with a Windows 2003 server and the issue continues with a Windows 2016 server. The IIS configuration are standard/default settings. If the default settings for a web site in IIS is to blame for my problems, then I believe your company needs to alert their customers of this issue and provide a fix. Just saying, "The problem is on your end, sorry" when the IIS servers are using default settings is disappointing.


Perhaps you can see in your server logs what caused this.

There is nothing in the server log that provides any clues. All I see is that the very last .bin file is never reached. You see _00001.bin downloaded just fine in the LOG file. You see _00002.bin downloaded just fine in the LOG file. You see _00003.bin downloaded just fine in the LOG file. And then that's it. No error codes. Just simply the .bin files stop being accessed by the stub EXE.

So the LOG files tell me nothing, and what I get from you is simply, "The problem is on your end, sorry."

[instrumentally]

Perhaps a typical "load balance configuration" problem.

There is no load issue on the server. The server is barely being used.

[instrumentally]

so perhaps your server can't handle the traffic if multiple users are downloading concurrently?

There were approx. 8 download attempts by 8 different users on the day in question. The odds of all 8 download attempts by 8 different users from 8 different locations ALL HAPPENING AT THE SAME TIME is about nil.

[instrumentally]

why are you using Web Installation at all?

Quite simple... Web spider search engines will find embedded EXE links in HTML pages and part of the spidering process, download the EXE in the process. This can lead to dozens to hundreds of unnecessary downloads of the EXE. If I have a 400MB EXE linked to a HTML page, then I run the risk of this useless bandwidth occurring. But if I use Web Deploy, and have only a 25K EXE stub, then the bandwidth usage is minimized since the search engine spider is highly unlikely to execute the downloaded stub.

[instrumentally]

just unmark the "Enable Web Installation" feature in your SB project and recompile. SetupBuilder will generate a single-file installer with the same .exe name.

I already did that shortly after I posted my original message. I simply could not afford wasting the email campaign resources by pointing interested respondents with the Web Deploy version.

Basically I am no forced to create a response arrangement where I send the respondent a HTML page that is not linked to any of my web site's pages. In this HTML file/page they will find a download link to the non-Web Deploy version. There is no way that I can make the 400mb EXE public as a result of this problem, because as I mentioned earlier, EXEs that are linked in public HTML files get downloaded by search engine spiders.

[linder]

So the LOG files tell me nothing, and what I get from you is simply, "The problem is on your end, sorry."

This really is not fair at all. We put quite a few resources into investigating your issue. If you check this forum, you'll not find any similar problem. Web Install is used by quite a few thousand companies worldwide since 15+ years. Even with "standard" server configurations (IIS, Apache, etc.).

But fact is, it is not caused by SetupBuilder, I am sorry. If your server returns a "page not found / 404" error, what can SetupBuilder do in this case? It fires a "retry", but this also failed.

BTW, did you see my successful web installation of your product in your LOG?

Friedrich

[linder]

Okay, doing two (2) more web installs from your server right now...

[linder]

Both web installations from your server succeeded (see attached screenshots). And we are thousands of miles away from you.

So please tell me, what else can we do to help in this case? The SetupBuilder web installations worked as expected and your server did not respond to file download requests with "404 page not found" errors at the time of our installations.

Friedrich

[linder]

And again two more successful web installations from your server. This time from Windows 7 and even a 16 year old Windows version (2003).

Friedrich

[instrumentally]

This really is not fair at all.

Fair or not, it was a factual statement that I am no further along in finding a solution than when I first posted the matter here.

I can understand your response in defending your product. But put yourself in my shoes. I have nothing more to work with than when I first posted my original message.


If your server returns a "page not found / 404" error, what can SetupBuilder do?

There are no "404" errors in the LOG file, however.

Here is a collection of LOG files for the past week:

http://hostsafe.com/temp/u_ex190324.zip

You won't find any 404 return codes from the server with regards to the _0000#.bin files.

So you are trying to tell me my problem is with my server returning error 404 codes and yet my server is not returning error 404 codes for the .bin files.

On 2019-03-24, the last .bin file that the stub attempted to download was _00005.bin which returned code 200. The remaining 390+ other .bin files were never downloaded despite no 404 messages occurring.

The same thing happened for 2019-03-22. _00005.bin was the last .bin attempted, and the LOG file shows code 200 was returned, not 404.

For 2019-03-20, _00003.bin and _00054.bin were the last .bin files downloaded, again, with code 200.

For 2019-03-19, _00001.bin, _00005.bin, _00053.bin and _00054.bin were the last .bin files downloaded, again, all stopping with code 200.


did you see my successful web installation of your product in your LOG?

Without knowing what day/time you downloaded/installed the app and what IP you were using, I cannot verify whether I see your attempt.

[instrumentally]

Yes, I can see that the app can be installed successfully. I know that because I can install it fine. However, take a look at the LOG files. You and I are the only ones who can install the .bin files from the stub EXE. All the other dozen plus users over the past 5 days end up dropping off anywhere between _00001.bin and _00054.bin (less than 15% complete) with no error 404s.

[instrumentally]

your server did not respond to file download requests with a "404 page not found error".

There are no "error 404" codes being returned from my server with regards to the .bin files.

[linder]

I can understand your response in defending your product. But put yourself in my shoes. I have nothing more to work with than when I first posted my original message.

No, I am not defending our product. If there is a bug or issue (and yes, SetupBuilder is not bug free) then we'll fix it immediately, period. A stable Web Installation is absolutely essential and quite a few large companies depend on our Web Installation and Web Update technology since years.


Without knowing what day/time you downloaded/installed the app and what IP you were using, I cannot verify whether I see your attempt.

Today, we did five successful Web Installations from your server via 93.224.41.6

Friedrich

[instrumentally]

Again, I am no further in solving this issue than when I posted this thread. There is no "error 404" issue to blame here. The LOG files prove that. There is no bandwidth/server access issue to blame either. The LOG files show how little traffic the server gets.

[linder]

So the one million dollar question is, what makes you and me so special? ;) And I am even downloading from another continent. If there was any issue in Web Install, we would see a lot of similar problem reports here and in our ticket system (btw, the HTTP component you are using is nearly 5 years old, dated May 09, 2014) and has powered quite a few million of downloads.

Friedrich

[linder]

Okay, just for fun I switched my ISP. Please see IP 37.80.148.220 in your LOG. This time it is a LTE cellular powered network. No timeout or file not found issue.

Unfortunately, there is absolutely nothing we can do to investigate what is goint on on your server and why your server does not respond to the GET file request (but always work fine for you and me; and I am at least 5000 miles away). See attached screenshot. 7 successful web installs from your server. Not a single web install failed from here using your original web install stub.

Friedrich

[linder]

The download process is very simple. The HTTP component sends a "GET" file request to your server. But your server does not respond to this file request (when you see a "source file not found" error). There is absolutely nothing from the SetupBuilder side-of-view that can be done to work around it.

To make it even worse (for us) is that it ALWAYS works when we install from your server (5000+ miles away). So what options do we have to solve this?

Friedrich

[instrumentally]

If there was any issue in Web Install, we would see a lot of similar problem reports here and in our ticket system

Yes, I understand. But that observation isn't solving the problem at hand.

Have you looked at the LOG files? Would you agree that your initial "error 404" suspicion isn't what we are dealing with here?

[linder]

Have you looked at the LOG files? Would you agree that your initial "error 404" suspicion isn't what we are dealing with here?

Yes and no. Your server simply stops responding and the GET request does not even "get through". That's why you do not see the "404" in your LOG. So there is absolutely nothing the HTTP component (WinSock) can do because your server stops communicating. Do you see what I mean? Your server does not log or send the "404" (I agree with you on this). But how to continue with the download if your server does not response to the GET request?

Friedrich

[linder]

It would be interesting to see, what your LOG reports if a file cannot be downloaded because it is an unknown MIME type.

Would it be possible for you to check this? Create a simple empty SetupBuilder project and use the "Download File..." script action to download a file with an unknown MIME type (so it gets blocked). Do you see such a download request in your LOG? What does "Download File..." stores in %_SB_ERRORCODE% after such an unsuccessful action?

I know it does not help at all to solve your problem, but I am 100% sure it is not caused by SetupBuilder (otherwise we would have seen thousands of support requests since the last recompile of the HTTP component in May 2014).

Friedrich

[linder]

Yes, I understand. But that observation isn't solving the problem at hand.

Have you seen these LOG files? Would you agree that your initial "error 404" suspicion isn't what we are dealing with here?

BTW, please check the attached log entries. Both Web Installations stopped at file 00005.bin. But one Web Install is dated 3-22 and the other one two days later 3-24. And directly after the "download issue" we see /wp-login.php requests with "404" results. Can you shed some light on this?

Friedrich

[linder]

Or this one (see attached). The same IP started four Web Installations. And three minutes later again four Web Installations. And then again a few seconds later /wp-login.php request (404 result).

Any idea?

Friedrich

[linder]

And again (see attached screenshot). Four simultaneous web installs started. And of course, again a /wp-login.php (404).

What is this?

Friedrich

[linder]

And here again... Wouldn't you agree it's no accident that we see the same entries again and again with the /wp_login.php after the "failed" web install?

Friedrich

[linder]

And here... nearly identical IP addresses, but they are not the same. Downloading a similar set of Web Install cluster files. Then stops downloading and again /wp-login.php (404).

Are these "fake" Web Installs installs? Perhaps the Web Installs were stopped by the client and not the server?

Friedrich

[linder]

And here is an interesting one... See attached screenshot. Different IP addresses from the same Web Install?????

And there are more suspicious items in your LOG.

Friedrich

[instrumentally]

And directly after the "download issue" we see /wp-login.php requests with "404" results.

Hackers will sniff for the existence of files on all public web sites. You need to look at LOG files more often. You'll get all kind of crazy GET requests for non-existent files all the time on a public server. Some hacker/sniffer is looking for doorway pages or login pages. That's why you see a 404 for /wp-login.php We don't use WordPress on our server, but some hacker is looking for a login page so that they can try hacking in.

[instrumentally]

And here is an interesting one... See attached screenshot. Different IP addresses from the same Web Install?????

My guess on this one is that some anti-virus site has been given my EXE to analyze. Sites like VirusTotal.com accept user's EXE uploads or URLs to files they wish to have verified for a virus. My guess is that one of these anti-virus sites is analyzing the contents of the installation package.

When I do a tracert on the IP in question, it traces to google.com It could very well be that Google is checking an email that I sent out to one of its users. The email I sent would have had a direct link to the EXE. I would not be surprised if Google isn't downloading and testing the file for viruses before delivering the email to its users.

[instrumentally]

directly after the "download issue" we see /wp-login.php requests with "404" results. Can you shed some light on this?

The wp-login.php request is coming from a different IP address that the stub EXE attempt to download the associated .bin files. That wp-login.php attempt isn't related to the SetupBuilder matter.

[instrumentally]

And of course, again a /wp-login.php (404).

The wp-login.php attempt is from 191.248.106.65. The .bin file requests are from 47.13.117.202. These are totally unrelated.

[instrumentally]

What does "Download File..." stores in %_SB_ERRORCODE% after such an unsuccessful action?

My dummy test EXE with a Download of an unknown file type did not generate an error code in the program/installer. The install completed without displaying any error.

On the server, the LOG file showed a 404 error for the unknown file type:

2019-03-25 22:33:32 192.168.1.15 GET /testing.123 - 80 - 192.168.1.1 SB8 - 404 3 50 15

"testing.123" was the file I instructed the installer to download.

[linder]

The wp-login.php request is coming from a different IP address that the stub EXE attempt to download the associated .bin files. That wp-login.php attempt isn't related to the SetupBuilder matter.

Okay, but it is very often directly after a "terminated" Web Install. IMO, it is related.

You started this support thread with "Web Deploy: Majority of installations fail (Source file not found)". So let me ask you, did you receive complains from (potential) customers? Did they send you screenshots from "Source file not found" error messages? Or did you start this support thread solely on the basis of the "aborted" Web installations LOG entries?

You sent the LOG yesterday and before that I assumed your customers reported massive "Source file not found" errors. Based on the information you provided, I brought the "404 error" and "server does not respond" into play. But as far as I can see from your server LOGs, automated processes start your Web Installation in a sandbox (even from different IPs) and then terminate it. And you are absolutely right: there is not any SetupBuilder related error code (e.g. 404) in your LOGs because the SetupBuilder Web Installation never failed.

Friedrich

[linder]

Perfect. Thanks for the confirmation. My "404" theory was based on your "Source file not found" statement.

Friedrich

[linder]

My guess is that ALL aborted/terminated Web Installations in your LOGs come from suspicious IP addresses and are automated downloads executed from within a sandbox.

For example, the 185.220.70.152 IP in your server LOG which I already mentioned in one of my screenshots (I have attached it again). It has been reported 6 times (Abuse IPDB) and 7 times in Stop Spam.

And please note the "/WP-login.php" attempts directly after the terminated Web Installs (on two different days). See attached screenshot. You said it's totally unrelated because it comes from another IP, but I really think it is related.

IMO, it is time to close this "Source file not found" support thread, wouldn't you agree? SetupBuilder is not responsible for the "8 out of 8 different users failed to complete the web deployment" issue you mentioned in your original post. The automated (hacker/sniffer/whatever) tools started and terminated these Web Installations - the "failed" installation attempts you see in your server LOGs are not real user downloads.

See: http://www.lindersoft.com/forums/showthread.php?47937-Web-Deploy-Majority-of-installations-fail-(Source-file-not-found)&p=90181#post90181

Friedrich

[linder]

You won't find any 404 return codes from the server with regards to the _0000#.bin files.

Correct. After spending many hours on this and after analysing your LOG files, I came to the conclusion that there were NO 404 errors. All SetupBuilder Web Installation GET requests succeeded!


So you are trying to tell me my problem is with my server returning error 404 codes and yet my server is not returning error 404 codes for the .bin files.

Well, the good news for you is, that you do not have a server problem. And the good news for us is, there is no SetupBuilder Web Installer problem.


On 2019-03-24, the last .bin file that the stub attempted to download was _00005.bin which returned code 200. The remaining 390+ other .bin files were never downloaded despite no 404 messages occurring.

This download came from IP 185.220.70.152. It's listed several times in abuse and spam databases.


The same thing happened for 2019-03-22. _00005.bin was the last .bin attempted, and the LOG file shows code 200 was returned, not 404.

This download came from IP 178.62.228.82 and belongs to Digital Ocean in Amsterdam, The Netherlands. I bet it's some kind of spider-bot.


For 2019-03-20, _00003.bin and _00054.bin were the last .bin files downloaded, again, with code 200.

This download came from IP 66.102.6.183 and belongs to Google LLC.


For 2019-03-19, _00001.bin, _00005.bin, _00053.bin and _00054.bin were the last .bin files downloaded, again, all stopping with code 200.

This download came from IP 35.161.55.221 which belongs to Amazon.com Inc (amazonaws.com) and it's listed in abuse and spam databases.

To cut a long story short, all mentioned "downloads" stopped with code 200 because "The Machines" simply terminated (killed) the sandbox executed Web Installations after a specific number of downloaded cluster files. There were no human beings behind the downloads. All Web Installs "stopped/terminated" intentionally.

Friedrich

[instrumentally]

There were no human beings behind the downloads.

Although I do appreciate the labor you've put into solving this puzzle, I don't believe I would conclude that there were no human beings behind the downloads. I did indeed get complaints from a handful of users that they were unsuccessful in downloading the Web Deploy version.

What we are seeing in the LOGs could be a combination of both failed user attempts and anti-virus scanners that are trying to analyze whether the EXE and associated files are trustworthy or not. As I mentioned towards the beginning of this thread, the EXE cannot be accessed through a web page linked to our home page. The EXE link was either in an email that we sent out, or in a HTML file on the server that has no links to any other page. So it cannot be that a standard search engine spider is behind the downloads. Would a search engine spider try to run a Web Deploy stub? That doesn't make sense. I can, however, see virus checkers performing sandbox tests. I can also see Google analyzing any links found in emails to EXEs that arrive in GMail inboxes.

[linder]

Although I do appreciate the labor you've put into solving this puzzle, I don't believe I would conclude that there were no human beings behind the downloads. I did indeed get complaints from a handful of users that they were unsuccessful in downloading the Web Deploy version.

Okay, let's have a look on your server LOG in deep detail. On 19-03-2019 the SetupBuilder Web Installer downloaded cluster files in nine (9) different sessions.

1. IP 207.102.138.40 (Session 3)

From 04:19:58 - 04:21:03 this IP downloaded cluster files in the range of .00001 - .00053.

The IP belongs to Fortinet Technologies, Canada. It has been reported 15+ times for Hacking Brute Force, Web Bot Web activity, Web App Attach, etc.

2. IP 46.246.43.14 (Session 6)

From 05:20:59 - 05:23:14 this IP downloaded cluster files in the range of .00001 - .00053.

The IP reverses to "anon-43-14.vpn.ipredator.se". This should be enough information to guess what is behind this IP. Interesting to see that it downloaded again the same range of cluster files.

3. IP 185.189.94.31 (Session 11)

From 06:01:37 - 06:02:07 this IP downloaded cluster files in the range of .00001 - .00006.

The IP belongs to AVAST Software s.r.o. - Czech Republic. This says it all.

4. IP 67.137.36.66 (Session 35)

From 10:49:29 - 10:50:38 this IP downloaded cluster files in the range of .00001 - .00053.

The IP belongs to Integra Telecom Inc. It has been reported 14+ times for bad traffic, DDoS Attack Hacking, Email Spam Brute-Force, Fraud Orders, etc. And again the same .00001 - .00053 range of cluster files.

5. IP 47.13.117.202 (Session 88)

From 15:53:04 - 15:56:44 this IP executed eight (8) Web Installations to download the same .00001 cluster file eight (8) times.

The IP belongs to spectrum.com. I don't think we need any more background information here.

6. IP 47.13.117.202 (Session 94)

From 16:23:35 - 16:23:50 this IP started again eight (8) Web Installations to download the same .00001 cluster file eight (8) times.

The IP belongs to spectrum.com. See 5. above.

7. IP 24.55.129.30 (Session 96)

From 16:38:09 - 16:57:42 (in 19:33 minutes!) this IP downloaded the .00001 - .00005 cluster files.

As far as I can see, this IP belongs to the "Penn View Bible Institute". This machine had a very slow Internet connection. In 19:33 minutes they downloaded ~25 MB - this translates to 1.3 MB/min. That Internet connection needs 3-4 hours to download all your cluster files. So it's very well possible the session timed-out on your cluster file .00005 (which is 9.88 MB in size). Note: the AVAST IP (see Session 11 above) downloaded cluster files in the range of .00001 - .00006 (30 MB) in 30 seconds.

8. IP 104.242.15.134 (Session 111)

From 18:27:37 - 18:35:03 (in 7:26 minutes) this IP downloaded .00001 - .00005 cluster files.

In 7:36 minutes they downloaded ~25 MB - this translates to 3.4 MB/min. That Internet connection needs 2 hours to download all your cluster files. See 7. above.

9. IP 47.13.117.202 (Session 160)

From 23:56:44 - 23:57:41 this IP started again eight (8) Installations to download .00001 - .00005 cluster files.

This IP belongs to spectrum.com. See 5. + 6. above.

To sum it up: we have analyzed all nine (9) Web Deploy sessions from your 19-03-2019 LOG. Most likely, seven (7) sessions where automatically executed from within sandboxes. Two (2) sessions might have been timed out. Requests sent to the server—and responses from the server—can time out. This occurs when a low-bandwidth connection requires too much time to transmit the data. The default timeout for blocking receive calls in Web Installation HTTP actions is set to 10,000 milliseconds. You can increase this using the HTTP_TIMEOUT #pragma.

We have executed seven (7) of your Web Installations and all seven sessions succeeded without any problem (from different Internet connections). And even from machines thousands of miles away from your server.

Please don't get me wrong, and with all due respect, but I have to stop here. I have put quite a few resources into investigating this case. There is no "Source file not found" issue in Web Deploy. And it's simply not fair to say that your email campaign has turned out to be a disaster because (according to the LOG file) 8 out of 8 different users failed to complete the web deployment.

[linder]

What we are seeing in the LOGs could be a combination of both failed user attempts and anti-virus scanners that are trying to analyze whether the EXE and associated files are trustworthy or not. As I mentioned towards the beginning of this thread, the EXE cannot be accessed through a web page linked to our home page. The EXE link was either in an email that we sent out, or in a HTML file on the server that has no links to any other page. So it cannot be that a standard search engine spider is behind the downloads. Would a search engine spider try to run a Web Deploy stub? That doesn't make sense. I can, however, see virus checkers performing sandbox tests. I can also see Google analyzing any links found in emails to EXEs that arrive in GMail inboxes.

Well, I think this IP address 14.141.60.156 (which belongs to Tata Communications Limited, India) is prepared to handle it. This is from your server LOG. They download the Web Deploy stub and later execute it from another IP.

2019-03-19 04:13:52 192.168.1.15 GET /demo/deployment/inword.exe - 80 - 14.141.60.156 python-requests/2.18.4 - 200 0 0 31
2019-03-19 04:14:00 192.168.1.15 GET /demo/deployment/inword.exe - 80 - 14.141.60.156 python-requests/2.18.4 - 200 0 0 15

[instrumentally]

Again, thank you for the time you've put into researching the issue. I'm impressed. :)

Out of curiosity, what tool did you use to create the reports seen in your screen snapshots?


The IP belongs to Fortinet Technologies, Canada. It has been reported 15+ times for Hacking Brute Force, Web Bot Web activity, Web App Attach, etc.

Also, how are you determining the reputation of an IP address?


The default timeout for blocking receive calls in Web Installation HTTP actions is set to 10,000 milliseconds. You can increase this using the HTTP_TIMEOUT #pragma.

This change is to be made on the server, or within the Setupbuilder project?

[linder]

Again, thank you for the time you've put into researching the issue. I'm impressed. :)

You are very welcome :)


Out of curiosity, what tool did you use to create the reports seen in your screen snapshots?

LogViewPro from Kainet:
https://www.softpedia.com/get/Internet/Servers/Server-Tools/Kainet-LogViewPro.shtml


Also, how are you determining the reputation of an IP address?

I am using https://www.abuseipdb.com


This change is to be made on the server, or within the Setupbuilder project?

This is in the SetupBuilder project. Just use the #pragma item and set the HTTP_TIMEOUT value. Then recompile.

By the way, there are two improvements in SetupBuilder 2019.2 Build 6187 (March 18, 2019). I think you are using a slightly older version. Perhaps this already makes a difference for low-bandwidth connections? Would be interesting to see the results.

NEW : IDE: Add HTTP_RETRY #pragma to set the number of HTTP(s) download retries in case of a failed Web Install download action. The default internal retry value has been increased from 1 to 2.

NEW : Installer: In case of a failed Web Install download action, the installer runtime re-initializes the WinSock component after waiting for 50 milliseconds.

If possible, please keep me posted.

Friedrich

[linder]

Hello again,

we'll set up a VM test environment here to simulate limited incoming or outgoing data transfers (similar to the scenario 1.3 MBytes/min "Session 96" and 3.4 MB/min "Session 111" in your 19-03-2019 LOG). So you'll see some downloads in the range of .00001 - .00010 in your next LOG files. We'll play a bit with timeouts. It's possible that we change "User-Agent: SB8" to "User-Agent: SB10" so you can filter our traffic.

Update 1: for your information. At the moment we are IP 37.81.163.174 in your LOG to simulate low-bandwidth connections and timeouts. You'll see more tests during the next few days in your LOG.

Update 2: I have attached a screenshot. This happens with Internet Explorer when a user tries to download the .00005 cluster file (about 10 MB) from a low-bandwidth connection (we have simulated "Session 96" with 0.17 Mbits/second). It simply times-out.

Friedrich