SiMPLE | Forum

It seems to let me post the link.  The characters that require Unicode encoding are URL-encoded, but I think that's intentional and expected.  i.e. "%E6%88%98%E5%9C%B0" is in the link instead of "战地", but that still means the correct URL.

https://tieba.baidu.com/f?kw=%E6%88%98% … 2&fr=index

Oh, maybe you have a post count or other "new user" designation on the forum which prevents "posting links" (of any kind).  As a way to prevent spam bots from getting past the registration checks and posting junk.  I'm not sure what Tuia might have setup here for that.

We're also assuming you did everything in the post Tuia linked to, which started with applying Tuia's modified BF1942.EXE.  Indeed, "if I press ESC there is a long hang" was a known symptom of the GameSpy shutdown and the original BF1942.EXE code, which we're assuming is eliminated as a possibility for you by having ensured this updated file is applied.

I was wrongly thinking of the scoreboard when you said "in-game browser".  Yes, having such a significant ping difference between the multiplayer server browser and the actual in-game ping is additionally unusual.

One thing I can't rule out from the screen shots is that the in-game ping was actually 450 rather than 45.  The ping being 450ms would be more consistent with the 350 shown prior to connecting, and would also be consistent with "it plays very poorly."  Unfortunately I think the only way to definitely know the actual ping is from server tools.

It definitely can be something in your ISP or further out into the network which is slowing this traffic down.  Ping and traceroute give us a sense of "how fast is the communication to a particular physical box over ICMP ports", but doesn't actually exercise "how fast will communication be over port 23000 or 14568 to those same physical hosts."

Does AX allow VPNs?  Just thinking that could be a an alternative to test and see whether bypassing having port 23000 and 14568 traffic directly to and from your computer (and instead having the firewalls and ISP networks only see VPN traffic instead of port 23000 and 14568 traffic) changes anything about what you're seeing.

https://youtu.be/q7DfQMPmJRI

I've never tried to run the game, just the dedicated server.  But I do have Server 2019 setup to run the dedicated server; I've simply never bothered to attempt launching the full game instead.

Even for running the dedicated server, I enable DirectPlay from the legacy features menu, same as you would on a Windows 10 desktop machine.  (Since that's the platform that Server 2016 and 2019 are based on; Windows 10.)  There may still be some assumption that DirectPlay is present, even though dedicated server probably ultimately doesn't utilize it.

I went ahead and tried launching the full game just now; I was able to launch and join the Team-SiMPLE server just fine.  No exit, no hang.

The XP SP3 compatibility mode is set, but simply as one of multiple things that Tuia's battlefield_1942_gamespy_patch_v1.61.exe installer already does for you; whether you manually tried to make those same configuration changes or not.

You probably already did, but it comes to mind that if you hadn't installed Tuia's update yet, you're also still operating with the old DRM protection that Windows intentionally disables.  So you need the no-CD aspect of Tuia's update as well, to eliminate the DRM dependency.

For what it's worth, I'm installing with real Battlefield 1942 CDs.  (And then the 1.6.19 patch, and then 1.61b patch.)   I suppose another possibility, if you're using some unofficial download source, is that the unofficial installer may or may not have planned on successfully handling the Windows Server platform.

But the first two things I would check are: DirectPlay enabled (Windows programs & features control panel; although for Windows Server, that's actually buried in Server Manager add roles & features wizard), and having Tuia's updated BF1942.EXE installed.

If you try and click on http://94.23.196.155/ in your web browser, do you get to a page that says "It works! This is the default web page for this server."

As opposed to getting a message from your web browser as though the site could not be reached or connection was reset.

Just trying to confirm whether it's truly an IP blocked situation (which I agree with bud it could be), versus some DNS or local HOSTS file issue that is unable to resolve or is taking you to the wrong Ax IP address.

Same as bud observed, here is our server's throughput when 20 players are on:

Sending about 2.5x as compared to receiving, and not even close to taxing the throughput cap.

Jesus.  Sounds like the NSA filed a tracking request with his name on it.... 

It certainly does open up some additional challenges, for seemingly low amounts of benefit in our particular context.  For example, once team-simple.org is being served as HTTPS, now those same user agents like Chrome will decline to show all of the non-HTTPS-linked images and videos that members have included in their messages over the years, because they're being referenced from a "secure" site.

The change would make your username be sent as encrypted from here on out, in addition to the password which was already being weakly encrypted before sending.  And it will make your Private Message content encrypted when posting and reading them.

But "everything else" on the site was already open to the public, and doesn't obviously benefit from "oh good, now prying eyes cannot capture this information unencrypted in transit."  They can simply browse the site as guest to see that same information, encrypted or not.

And to the point and topic of this thread, "Not if it exists in this list."

What would have been a brute force effort will be short-circuited by trying a bunch of real-word, known-compromised passwords.  i.e. You might have thought "maG18w@tm3m3" was the most secure password you've been able to remember.  But if someone else thought so too, and their info got compromised, it's in this list of password hackers may be "trying first" rather than taking the normal amount of time to reach that particular combination.

This is not a list of "weak passwords."  It's a list of compromised passwords, as strong or as weak as they may have been.

Agreed, and every "bad possibility" is contingent upon "because my password actually is in this list."  If someone in a position to see the Cloudflare logs, or pwnedpasswords.com's own Apache logs, or (what we don't think is happening) pwnedpasswords.com itself was malicious, the issue would be "the user at telcomuser3092.vodaphone.es just looked up the hash 4BC4A.  If we know or can figure out who that is and start looking at his accounts, definitely start with the passwords which had generated the 528 SHA-1 hashes represented by https://api.pwnedpasswords.com/range/4BC4A."

In your case, no harm: Because your password isn't actually in that list that generated these 528 SHA-1 hashes.  Someone who's password is in that list just potentially gave away a hint as to which passwords should be attempted against their accounts first.  A set even smaller and more optimal than "the entire list of compromised passwords."

So maybe that's the end-game here: If you do decide to look up your password here -- either on the web site or using the 5-prefix API -- "commit to it."  Meaning if there is a match, don't ignore or rationalize anything trying to keep your favorite password.  Don't wait.  Immediately change every instance where you had used that password.  Meaning, mitigate the small risk of having shown "a hint" to someone, by making sure that hint will be 100% useless going forward.  The risk only exists by not following through.

Whatever small risk might exist in the technology in play here, the real point is "people are entering their current passwords because a web site asked them to."  This is, literally, the only case I'm aware of where such a prompt wasn't malicious.  The alarm bells in everyone's head should have been deafening; and in terms of social engineering, it would be better if the web site didn't exist.

Having to justify "in this case, there actually is a site into which you should enter all your current passwords" is a terrible, terrible precedent that will be exploited later.

In my opinion, that's simply a sponsor who is helping him pay for the site, and not some assertion that "clearly this is the best way to solve password security."  Presumably they would just like the opportunity to keep their hand in your wallet under the pretense of helping you pick better passwords & having a "secure" place to save passwords that are so strong you can't possibly remember them all.

1Password does claim to be providing other services, such as alerting you when Amazon has had a data breach and guiding you to change your saved Amazon password.  Kind of a "credit monitoring, but for passwords" service.

The end-game of searching this haveibeenpwned.com list is to determine "has someone who is using the same password that I am using had their information captured and compromised before."  It's not really any kind of assertion of whether the password itself was "poor" or "strong", because it could have been compromised by a poor system used for storing or verifying the password.  Which has nothing to do with how strong the password itself was, and means an exceedingly strong password can still be present in this list; not just "bad passwords".

You want to pick exceedingly strong passwords.  After picking an exceedingly strong password, the reason you would search this haveibeenpwned.com list is to make sure you didn't pick an exceedingly strong password which just happens to be a password that is known to have been compromised as part of someone else's data.  ...or maybe even as part of your own data! 

I feel like one of those 1960's movie robots with smoke coming out of their ears while repeating "does. not. compute." when trying to reconcile "check whether your current live password has been compromised or not" by asking people to "please enter your password into this web site you've never seen before."

Yes, I have read the process, and understand the math, the API, and how we've been promised that our clear text passwords are "not going to be submitted or logged."  So I should trust what's written on this web site I've never seen before and give it my current passwords?  Cue ear smoke and robotic arm spinning.

So you could download the entire 11GB list from them, generate an SHA1 hash the password yourself (LOCALLY -- not using an online SHA1 hash generator, or else you might as well have gone ahead and entered your password into this site), and search that 11GB list entirely locally without anyone knowing what you did.

If downloading or searching an 11GB list of hashes doesn't sound like fun, the API haveibeenpwned.com provides isn't that bad to use manually, and the k-anonymity approach of sending only a prefix of your SHA1 hash gives "some" sense of not being totally compromised.  You're still providing "an unknown external entity" some hints about what your passwords might be, though.

Regardless of which approach you want to use, the first step is to create an SHA-1 hash of your password, without sending your password to anyone.   If you're on a current version of Windows 10, you can open up a PowerShell command prompt and enter the following two PowerShell commands to generate an SHA1 hash of your password:

[Reflection.Assembly]::LoadWithPartialName("System.Web")
[System.Web.Security.FormsAuthentication]::HashPasswordForStoringInConfigFile("ThisIsMyPassword", "SHA1")

This creates an SHA-1 hash of a UTF-8 representation of your password string.  (Which, troyhunt.com doesn't currently appear to confirm what exact form the passwords were in when he hashed them, but we're assuming UTF-8.)

For example in my case the entry and output of these commands was:

PS C:\Files> [Reflection.Assembly]::LoadWithPartialName("System.Web")

GAC    Version        Location
---    -------        --------
True   v4.0.30319     C:\WINDOWS\Microsoft.Net\assembly\GAC_64\System.Web\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Web.dll

PS C:\Files> [System.Web.Security.FormsAuthentication]::HashPasswordForStoringInConfigFile("ThisIsMyPassword", "SHA1")
30B8BD5829888900D15D2BBE6270D9BC65B0702F

So now you have the SHA1 hash, "30B8BD5829888900D15D2BBE6270D9BC65B0702F", that represents the password, "ThisIsMyPassword".

If you downloaded the 11GB offline file, now you can go search the file for that entire hash.

To instead use the k-anonymity approach to invoking the online API, take the first five characters of that SHA1 hash, and add it to the URL https://api.pwnedpasswords.com/range/.  Such as in the case of the "ThisIsMyPassword" example, this would be 30B8B, and the resulting URL is:

https://api.pwnedpasswords.com/range/30B8B

This returns you a list of 527 password hashes that exist in the list, and share these same first five characters in the SHA1 hash.  By searching for the remaining 35 characters in your SHA-1 hash value, you end up seeing that this password exists in the list and has been encountered in the black market data twenty-seven times:

D5829888900D15D2BBE6270D9BC65B0702F:27

So there, that's one way you could check for your passwords in the list, without "entering your password into an unknown third-party web site."  It's still not 100% safe, since even using this approach, if the haveibeenpwned.com site itself -- or someone in a position to know the URLs you have entered -- was actually malicious, you've now narrowed down the list of passwords they should try for your accounts to a list of only 527.

The only way to prevent that is to download the 11GB list yourself and search 100% locally for your SHA-1 hashes.

Possibly.  But at least according to tuia, that's why I was pointing to the .EXE patcher instead of the individual .ZIP files.  Because the .EXE patcher contains both the logic and the needed files to detect and patch either a retail (CD) installation or an Origin installation.  The caveat being if you have both installed, it's only going to patch retail (CD) and not the Origin install.

I'm not going to get in the way of a good excuse to buy a new system.

But if my network throughput improved so significantly by landing in Safe Mode, I would blame the crush of things I have installed or mis-configured in full mode, and would perform a new bare-metal install.  And see what the throughput is after I've installed nothing except Windows and the required hardware drivers.  (You could also just set aside your current hard drive, and do the bare-metal install on a spare drive to see the results without squashing your current Windows installation.)  Safe Mode back-tracks many performance features of Windows, and things shouldn't be improving dramatically.

Also, something you may have already done, but in the Internet and Network control panel where you can see the Change Adapter Settings, right click on your network card and select "Status" to confirm its actually negotiated 1Gbps to the modem/gateway.  Clearly you have gigabit hardware, but the question is whether that's the mode the hardware is actually operating in / has negotiated with the Ethernet port on the modem/gateway.  This can typically also be configured to simply force a lower negotiation in the network adapter properties; so if you do see it's not 1Gbps, look at whether maybe it's configured not to for whatever reason.

On a desktop machine, swapping in a $15 1000base-TX Ethernet card to make sure it's not the built-in port that's failing is an option.  (Or even on a laptop, if you have a USB3 port to keep up with the transfer rate.)  Or just blow the dead crickets out of your current port, and re-connect the cable and assume its good.