Signed-off-by: Sven Baars sven.wine@gmail.com --- This happens quite often, see
https://test.winehq.org/data/tests/wininet:ftp.html
Also during bbf74ea22a5310978c9aecbdc648c562c26fa0fb the behavior of this test was changed, so I modified the comments accordingly.
dlls/wininet/tests/ftp.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/dlls/wininet/tests/ftp.c b/dlls/wininet/tests/ftp.c index 317b291495..c6d972a352 100644 --- a/dlls/wininet/tests/ftp.c +++ b/dlls/wininet/tests/ftp.c @@ -63,7 +63,7 @@ static void test_connect(HINTERNET hInternet) HINTERNET hFtp;
/* Try a few username/password combinations: - * anonymous : NULL + * anonymous : IEUser@ * NULL : IEUser@ * NULL : NULL * "" : IEUser@ @@ -72,14 +72,14 @@ static void test_connect(HINTERNET hInternet)
SetLastError(0xdeadbeef); hFtp = InternetConnectA(hInternet, "ftp.winehq.org", INTERNET_DEFAULT_FTP_PORT, "anonymous", "IEUser@", INTERNET_SERVICE_FTP, INTERNET_FLAG_PASSIVE, 0); - if (hFtp) /* some servers accept an empty password */ + if (!hFtp) { - ok ( GetLastError() == ERROR_SUCCESS, "ERROR_SUCCESS, got %d\n", GetLastError()); - InternetCloseHandle(hFtp); + skip("No ftp connection could be made to ftp.winehq.org %u\n", GetLastError()); + return; } - else - ok ( GetLastError() == ERROR_INTERNET_LOGIN_FAILURE, - "Expected ERROR_INTERNET_LOGIN_FAILURE, got %d\n", GetLastError()); + ok(GetLastError() == ERROR_SUCCESS, + "Expected ERROR_SUCCESS, got %d\n", GetLastError()); + InternetCloseHandle(hFtp);
SetLastError(0xdeadbeef); hFtp = InternetConnectA(hInternet, "ftp.winehq.org", INTERNET_DEFAULT_FTP_PORT, NULL, "IEUser@", INTERNET_SERVICE_FTP, INTERNET_FLAG_PASSIVE, 0);
On Thu, 24 Oct 2019, Sven Baars wrote:
Signed-off-by: Sven Baars sven.wine@gmail.com
This happens quite often, see
I suspect this is because the VM is getting banned (fail2ban) after it has made too many failed connection attempts:
while wget -O/dev/null ftp://anonymous:IEUser@ftp.winehq.org/;do wget -O/dev/null ftp://foo:bar@ftp.winehq.org/;done
Probably a single run is fine because it stays under the limit. But when WineTest is run multiple times on the same VM (hence same IP address) in different configurations (particularly w8/w8adm or the various w1064 variants) the failed attempts could add up resulting in a ban.
Furthermore this would be pretty dependent on how much time passed between the wininet:ftp runs. It takes between 18 and 30 minutes to run WineTest so if the failed attempt counter is reset after 20 minutes (or if the ban did not expire yet) we'd see a pretty random behavior.
That may justify skipping but then we should add a comment if this explanation is indeed correct.
Or maybe the ftp.winehq.org configuration should be changed, but only Newman can say if it's ok security-wise.
On 25-10-19 01:15, Francois Gouget wrote:
On Thu, 24 Oct 2019, Sven Baars wrote:
Signed-off-by: Sven Baars sven.wine@gmail.com
This happens quite often, see
I suspect this is because the VM is getting banned (fail2ban) after it has made too many failed connection attempts:
while wget -O/dev/null ftp://anonymous:IEUser@ftp.winehq.org/;do wget -O/dev/null ftp://foo:bar@ftp.winehq.org/;done
Probably a single run is fine because it stays under the limit. But when WineTest is run multiple times on the same VM (hence same IP address) in different configurations (particularly w8/w8adm or the various w1064 variants) the failed attempts could add up resulting in a ban.
Furthermore this would be pretty dependent on how much time passed between the wininet:ftp runs. It takes between 18 and 30 minutes to run WineTest so if the failed attempt counter is reset after 20 minutes (or if the ban did not expire yet) we'd see a pretty random behavior.
That may justify skipping but then we should add a comment if this explanation is indeed correct.
Or maybe the ftp.winehq.org configuration should be changed, but only Newman can say if it's ok security-wise.
I appear to have been perma banned from the ftp server for running that while loop while trying to create a similar workaround for the urlmon:protocol tests (which time out because of this). Isn't it possible to just have a dummy ftp server that doesn't ban anyone?
Best, Sven
On Fri, 8 Nov 2019, Sven Baars wrote: [...]
Probably a single run is fine because it stays under the limit. But when WineTest is run multiple times on the same VM (hence same IP address) in different configurations (particularly w8/w8adm or the various w1064 variants) the failed attempts could add up resulting in a ban.
Furthermore this would be pretty dependent on how much time passed between the wininet:ftp runs. It takes between 18 and 30 minutes to run WineTest so if the failed attempt counter is reset after 20 minutes (or if the ban did not expire yet) we'd see a pretty random behavior.
That may justify skipping but then we should add a comment if this explanation is indeed correct.
Or maybe the ftp.winehq.org configuration should be changed, but only Newman can say if it's ok security-wise.
I appear to have been perma banned from the ftp server for running that while loop while trying to create a similar workaround for the urlmon:protocol tests (which time out because of this). Isn't it possible to just have a dummy ftp server that doesn't ban anyone?
The ban is probably not really permanent, just a few hours. Unless Newman is running a recidive ban to block repeat offenders for days.
Btw, the wininet:ftp results are much better since Oct 27.
Btw, fail2ban's recidive rule is pretty nice. On my box it's currently banning 1115 repeat offenders for the next month for playing the guessing game on my ssh server.
On 08-11-19 12:33, Francois Gouget wrote:
On Fri, 8 Nov 2019, Sven Baars wrote: [...]
Probably a single run is fine because it stays under the limit. But when WineTest is run multiple times on the same VM (hence same IP address) in different configurations (particularly w8/w8adm or the various w1064 variants) the failed attempts could add up resulting in a ban.
Furthermore this would be pretty dependent on how much time passed between the wininet:ftp runs. It takes between 18 and 30 minutes to run WineTest so if the failed attempt counter is reset after 20 minutes (or if the ban did not expire yet) we'd see a pretty random behavior.
That may justify skipping but then we should add a comment if this explanation is indeed correct.
Or maybe the ftp.winehq.org configuration should be changed, but only Newman can say if it's ok security-wise.
I appear to have been perma banned from the ftp server for running that while loop while trying to create a similar workaround for the urlmon:protocol tests (which time out because of this). Isn't it possible to just have a dummy ftp server that doesn't ban anyone?
The ban is probably not really permanent, just a few hours. Unless Newman is running a recidive ban to block repeat offenders for days.
Btw, the wininet:ftp results are much better since Oct 27.
Btw, fail2ban's recidive rule is pretty nice. On my box it's currently banning 1115 repeat offenders for the next month for playing the guessing game on my ssh server.
I've been banned since Sunday(?) I think. And yes, Alexandre committed the patch, so the wininet:ftp tests are much better now, but there are more like urlmon:protocol and urlmon:url. Problem there is that urlmon doesn't know yet that the connection failed, so I'd have to implement that somehow to skip the tests (Windows calls ReportResult with ERROR_FTP_DROPPED, wine doesn't call it at all). But doing that properly became a bit harder when I got banned.
On 11/8/19 6:19 AM, Sven Baars wrote:
On 08-11-19 12:33, Francois Gouget wrote:
On Fri, 8 Nov 2019, Sven Baars wrote:
Or maybe the ftp.winehq.org configuration should be changed, but only Newman can say if it's ok security-wise.
No, I'd prefer not to change the configuration for this box.
Ideally down the road when we migrate WineHQ.org over to VMs we should setup a VM dedicated to hosting services for tests. (ftp/smtp/http/https etc.) This VM could have slightly lax security since it not hosting anything of importance.
The time of hosting nearly everything WineHQ.org related on a single Linux install should end.
The ban is probably not really permanent, just a few hours. Unless Newman is running a recidive ban to block repeat offenders for days.
Bantime is set to 86400 (1 day). So a ban should be removed after 1 day. I was not using recidive YET, but I am considering it.
I should note, the testnet VMs should not be getting banned when traffic is coming from the testnet network. I have a rule in place that ignores the rules for them.
-N
On Fri, 8 Nov 2019, Jeremy Newman wrote: [...]
I should note, the testnet VMs should not be getting banned when traffic is coming from the testnet network. I have a rule in place that ignores the rules for them.
That's worrying because it means the tests are failing for some other unknown reason. So I tested this from vm2 and indeed it looks like there is no banning. But the first wget initially failed a bunch of times:
$ wget -O/dev/null ftp://anonymous:IEUser@ftp.winehq.org/ --2019-11-08 18:29:50-- ftp://anonymous:*password*@ftp.winehq.org/ => ‘.listing’ Resolving ftp.winehq.org (ftp.winehq.org)... 4.15.184.77 Connecting to ftp.winehq.org (ftp.winehq.org)|4.15.184.77|:21... connected. Error in server response. Closing. Retrying.
--2019-11-08 18:29:51-- ftp://anonymous:*password*@ftp.winehq.org/ (try: 2) => ‘.listing’ Connecting to ftp.winehq.org (ftp.winehq.org)|4.15.184.77|:21... connected. Error in server response. Closing. Retrying.
And so on until it magically started working on the 16th try:
--2019-11-08 18:31:35-- ftp://anonymous:*password*@ftp.winehq.org/ (try:16) => ‘.listing’ Connecting to ftp.winehq.org (ftp.winehq.org)|4.15.184.77|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD not needed. ==> PASV ... done. ==> LIST ... done.
.listing [ <=> ] 245 --.-KB/s in 0s
2019-11-08 18:31:35 (9.96 MB/s) - ‘.listing’ saved [245]
Then the subsequent runs worked:
$ wget -O/dev/null ftp://anonymous:IEUser@ftp.winehq.org/ --2019-11-08 18:31:35-- ftp://anonymous:*password*@ftp.winehq.org/ => ‘.listing’ Resolving ftp.winehq.org (ftp.winehq.org)... 4.15.184.77 Connecting to ftp.winehq.org (ftp.winehq.org)|4.15.184.77|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD not needed. ==> PASV ... done. ==> LIST ... done.
.listing [ <=> ] 245 --.-KB/s in 0.001s
2019-11-08 18:31:36 (207 KB/s) - ‘.listing’ saved [245]
Removed ‘.listing’.
Unfortunately I did not get the initial bad server response and when I tried from vm1 wget worked the first time around. I wonder if there is something strange going on with inetd or some equivalent. Unless it's something to do with NATing vs. ftp in active mode(*). Maybe I'll retry tomorrow.
(*) I doubt that one because the tests seem to be good about specifying INTERNET_FLAG_PASSIVE, and I believe that would only be an issue if there was some router-level load balancing going on.
On Sat, 9 Nov 2019, Francois Gouget wrote:
On Fri, 8 Nov 2019, Jeremy Newman wrote: [...]
I should note, the testnet VMs should not be getting banned when traffic is coming from the testnet network. I have a rule in place that ignores the rules for them.
That's worrying because it means the tests are failing for some other unknown reason. So I tested this from vm2 and indeed it looks like there is no banning. But the first wget initially failed a bunch of times:
wget -S -O/dev/null ftp://anonymous:IEUser@ftp.winehq.org/ still worked on the first try on vm2 today.
So I don't know what happened on saturday or whether it could happen again :-(
$ wget -O/dev/null ftp://anonymous:IEUser@ftp.winehq.org/ --2019-11-08 18:29:50-- ftp://anonymous:*password*@ftp.winehq.org/ => ‘.listing’ Resolving ftp.winehq.org (ftp.winehq.org)... 4.15.184.77 Connecting to ftp.winehq.org (ftp.winehq.org)|4.15.184.77|:21... connected. Error in server response. Closing. Retrying.
-
Francois Gouget -
Jeremy Newman -
Sven Baars