SiMPLE | Forum

(EDIT: Removed a bunch of unnecessary discussion, now that Bud confirmed DNS should be supported.)

Fair enough.  No new players will be coming from Origin; only returning players who already have and/or re-install Battlefield froim their Origin downloads.

Regarding the .EXE idea, I should have said "consider or propose" making it an .EXE.  If you specifically want a shortcut for this project, clearly it can or must be a shortcut.

I was just thinking in terms of something where the "icon" on the user's desktop could actually be a little smart and keep making the right decision or presenting a useful message if the game disappeared, or maybe use a cached DNS address if the DNS name doesn't resolve.  Again, the list grows and grows....

-Trench

https://youtu.be/7-Y0uLesW6M?t=1300

The game browser traffic is as "normal" as the actual game connection traffic is.  Possibly even "more normal", since status responses tend to be larger packets / larger amounts of data than the game traffic.  (Smaller frames just have a somewhat higher potential for being intentionally or unintentionally dropped.)

Seeing the issue persist even after changing machines and changing routers, and seeing the issue only affect the browser traffic, would make me think the ISP must have changed or is testing something in relation to traffic prioritization.  Which is in intentionally or unintentionally affecting the browser port ranges and not the game traffic itself.

A LAN trace (e.g. Wireshark.org) could confirm for you that the status query response actually did come back delayed or without any response at all, which means the issue is at your router or ISP.  Versus being received quickly as expected but for whatever reason apparently not making it back to the application (because BF1942.EXE shows 9999 or large ping), which means something delays it inside your computer.

-Trench

I assumed it's just addition of the "Score" value logged for the player at the end of each round.  i.e. Their score, versus their kills, versus their deaths.  Each one of those values are being separately added together to create a total core, total kills and total deaths for all of the the rounds that have been logged for this player.

What are you observing that suggests it might be something other than that?

-Trench

EDIT: Clarification of "Are all simply being added together."

Hey Mista.  Follow-up on bud's line of questioning, because "what mod actually requires this" is interesting, and wondering whether it's truly "requires" versus "is recommended."

There isn't anything you're going to do about this within the controls Windows provides end-users for compatibility mode, so long as you continue selecting "Windows 98" compatibility.  Nor is there anything the fixed SiMPLE BF1942.exe is going to be able to do about it, since the widescreen fix is enumerating the resolutions available through Windows.  (And setting Windows 98 compatibility has limited the resolutions available through Windows.)

There is an Application Compatibility Toolkit available for Windows which lets you play with enabling just individual compatibility shims for an application, rather than the pre-packaged sets of compatibility shims that are represented by selecting "Windows 98" compatibility mode, "Windows XP SP3" compatibility mode, etc.  Not exactly fun or obvious stuff, but technically it can be done.

Ostensibly, with that toolkit, you would be able to put together a set of shims that "does everything selecting Windows 98 compatibility does", but without including the change(s) that will effectively limit what video modes the application is allowed to see as selectable.  However, then the question becomes, "is a limit to the resolutions that are available actually required in order for the mod to work."  Meaning once you stop limiting the resolutions, is the mod you were setting "Windows 98" compatibility for going to break due to seeing higher resolutions, and is why they were recommending it in the first place.

-Trench

Hmm.  Line endings certainly would have fit with "it fails on every single line, such that by the end it thinks there were a total of zero valid lines."  So if it's not that, then there "must" be some more obvious difference in the data, such as quotes used in one where quotes weren't used in the other; a different number of total columns; or some other difference that "is true for every single line."

If you wanted to PM your Linux versus Windows examples, I'd be interested to try and identify the difference too.  If the data in the examples you have isn't something you want to disseminate, that's understandable as well.  It would need to be as an attachment or something else that preserves the binary format the files, so maybe admin at ea117.com is the better way to send, if you do.

Yeah, since he had ping and score stats, nothing seems logical about why that one line would have an unknown IP or unknown key hash.  In the short time I've been running CSV logging, there have already been a couple times where at the end of the round it simply says "unable to save CSV stats" instead of appending them as expected.  So could just be buggy.

I haven't run any scores/kills/deaths stats to recommend anything first-hand.

I see https://selectbf.sourceforge.io/ and https://github.com/SiphonSquirrel/jepperscore out there, but they don't appear to be for the faint of heart technical-wise.  (I believe selectbf must have been the one bud was referring to earlier.)  These systems are also for collating BF1942's own more extensive event/XML logging and not the BFServerManager CSV logging.

If you were happy with the data that was promised from just the CSV logging (just maps, players, kills, deaths), the only way I know to collate and put that into human-readable form like BFStats was going to do would be to write something yourself.

The "Java.lang.NullPointerException" is saying that something went critically wrong for the BFStats Java code when attempting to parse the line from the .CSV file.  And so it's ignoring the line as potentially "invalid."  But this happens during the parsing of every single line.  And so with 100% of lines ignored, BFStats declared "the file is empty" because there were no valid lines processed.

No, I've never used BFStats and don't know what it will take to solve this.  My guesses would be that possibly the Java runtime itself has long-since closed some security hole or bad coding that this application used to get away with.  Or that the data being generated into the .CSV doesn't contain data that BFStats always assumed would be there, and doesn't parse correctly without.

The BFStats program appears to have been created before BFServerManager 2.01 was out, so possibly its some difference in the format of the .CSV logging as compared to 2.0 or similar.   Maybe if you can temporarily run with 2.0 and generate a .CSV log from that, to compare against your 2.01 logs.  If there is a specific difference, even though you can't fix the BFStats program, maybe you can manually or via macros edit your 2.01 log files to be consistent with the 2.0 format before presenting them to BFStats.

I don't decompile or write Java code, so that's as far as I can reasonably guess.

FTFY.  "250Mbps" is a measure of throughput, not latency.  When your ISP moves you from 5Mbps to 25Mbps to 50Mbps to 100Mbps to 250Mbps, that doesn't change your latency.  (Not talking about switching ISPs or hardware; just "upgrade to a 10x faster plan.")  Your in-game ping does not "go down" corresponding to your throughput now being 10x higher than it was before, because that's not what higher throughput means.

Your sustained throughput (download a file, concurrent people streaming, etc.) is going to be great by upgrading to 250Mbps.  But your ping is expected to be the same as it was before.

-Trench

You forgot to list "money" as a possible reason.  Its not uncommon for phpBB hosting services to be giving you access to control your application, but not the underlying HTTP server.  And to want to charge you per month for supplying the certificate and configuring the HTTP server to use it, as one of their value-added services.  So "how many $$$ per month is reasonable just to protect already-hashed passwords" might have been weighed.

-Trench

A Bittorrent connection was the only real "practical" use I had thought of right away for what a "private citizen" might do that would approach 10Gbps capacity.  i.e. Where you're not just downloading from a single host and hitting that remote host's own 100Mbps bandwidth; but rather hitting 25 peers and each of their own individual 100Mbps bandwidths concurrently.

Indeed, it can't and won't change anything about your Netflix or gaming experience, etc., because none of those applications are hitting your current 100Mbps bandwidth threshold, either.  Having an awesome connection can't make something that only wants to move 1.5Mbps of data per second go any faster; it can only allow you to do more of those things concurrently.

So instead of "my wife and kids get on Netflix and my game connection goes to shit", now you can have a dozen wives, and a hundred kids, before you would notice that.  So that's who they're marketing 10Gbps at for the home user: polygamists. 

I think last I looked, when we had ~25 people on a Battlefield 1942 server, the server was only sending 2Mbps up and pulling 1Mbps down.  That's the entire server, not just a single player connection.  So yeah, 10Gbps is definitely not changing anything about our Battlefield 1942 lives any time soon.

-Trench

For what it's worth, that's something we pondered in EA117's recent IP address change(s), too.  Let me know if you're seeing results that contradict this, but I feel like the problem with "only worry about name" will be because of how the Battlefield 1942 client treats "Favorite" server entries.

If you tell someone "use the Update button, and then look for the new SiMPLE entries", they will press Update and then say "I see them!  I see the SiMPLE entries!"  But they're seeing the ones for the old IP address that were marked as "Favorite", and don't distinguish that they're truly "new" or for the updated IP address.

Making the person aware of what IP address they're expecting to see on those entries, and to be sure and un-mark the old entries as Favorites and mark the ones with the updated IP address as their new Favorites, seemed necessary.

Like we tried to explain in http://ea117.com/texas.  Please feel free to nuke this line if you'd rather not have the link here.

-Trench

That definitely sounds like a great idea for trying to side-step the problem, either while the ISP is trying to find the actual root cause, or in case they never identify or resolve the root cause.  Pondering all the steps to include for ziba128 to turn this into a full-fledged test, what I came up with was the following.  Let us know if you see something different you had in mind:

1. First, let's simply determine whether opening a rule to any set of local UDP ports even side-steps the problem.  Meaning, when we have a Port Forwarding rule allowing unsolicited inbound communication to the ephemeral ports (whatever range they might be in), does that truly avoid the "small 55-byte UDP replies appear to be dropped" issue behavior?

2. So without even using NETSH to try and override any of the existing Windows TCPIP stack parameters yet, simply go to the router management and create a Port Forwarding rule with a start port of 40000 and an end port of 65535 for UDP only, and to be forwarded to those same ports on 192.168.1.10 or whatever the Battlefield 1942 machine is now.  Note you specifically want "UDP only", and not "Both" (meaning TCP and UDP), in order not to interfere with TCP communication.

3. Restart the router just for good measure, and confirm the new Port Forwarding rule still exists.  Then attempt to play Battlefield 1942 and see if the success rate is now 100%, or substantially changed in any way.

4. If that test WORKS, then bud's approach of actually changing which local ports the Windows machine will use for UDP is probably best, or even necessary, if you intend to share this Sagemcom router's Internet connection with other devices besides the Battlefield 1942 machine.  i.e. We can't just hijack "all 40000-65535 UDP traffic" and always send it to 192.168.1.10, because it might have been a conversation initiated by some other device you're sharing your Internet connection with.  So we'll want to move to a range that doesn't fall within default local port usage, giving us less chance of hijacking some other device's communication and causing it to fail.

5. On the Windows machine with Battlefield 1942, in an Administrator Command Prompt issue the command "netsh int ipv4 set dynamicport udp start=28000 num=1000" so that local UDP ports 28000 through 29000 will be used.  Arbitrarily picking a value a bit higher than 10000, just because the lower port ranges (typically less than 10000 though) are where well-known services live or create their listening ports.

6. Now delete the previous Port Forwarding test rule from the router, and create create a Port Forwarding rule with a start port of 28000 and an end port of 29000 for UDP only, and to be forwarded to those same ports on 192.168.1.10 or whatever the Battlefield 1942 machine is now.  Note you specifically want "UDP only", and not "Both" (meaning TCP and UDP), in order not to interfere with TCP communication.

7. Restart the router and the workstation.  Make sure the new Port Forwarding rule still shows on the router.  In a Command Prompt on the workstation, use the command line bud provided of "netsh int ipv4 show dynamicport udp" to confirm whether the UDP port change actually persists.  (The change should persist across reboots.)

8. Test whether running the Battlefield 1942 game now remains successful.

The main "bad thing" about this approach is that we're having to create a Port Forwarding rule that allows "all unsolicited inbound communication" on these UDP ports, regardless of whether that was a range starting at 10000, 28000 or even the default 40000 through 65535 range.  Meaning these ports are now "open" to anything attempting to reach your machine on those ports, 24/7, due to the new Port Forwarding rule.

The ongoing root cause, and actual problem, is that the router and/or ISP does not seem to be correctly dealing with "there is a UDP conversation established" when the server sends "small" replies.  That reply should have been allowed through automatically, because of the outbound communication the workstation had just performed.  Without having to establish any Port Forwarding rule, and without having to leave the port open 24/7.

However, "force my Windows machine to a non-default UDP port range, and then explicitly allow any inbound communication to those UDP ports though the router" might end up being the best workaround we have -- if that approach actually works -- in absence of a solution or identification of the true root cause.

We had also mentioned in PM earlier that using a VPN service (e.g. privateinternetaccess.com, or one of the many others) could potentially bypass whatever issue is occurring too, provided that your router and ISP actually allow the VPN service to be used successfully.  However, the potential issue then is that some Battlefield 1942 servers are going to frown upon seeing a VPN address attempting to connect to their server, because that's the approach many bad actors use to mask their identity and intention to exploit the server.

-Trench

The best conclusion I can make out of the LAN traces provided is that there is an issue, either at your router or at the ISP, which tends to block the UDP port 14567 replies "unless those replies are large."  Meaning, 556-byte replies always get through successfully, but smaller 55-byte replies rarely get though.  The "random" occasions in which you can successfully connect are occurring when "randomly" a small 55-byte reply actually is allowed through back to your workstation.  Once one of the small replies is allowed, all of the small replies are allowed, for the duration of that connection.

For your email description to the ISP of what the issue is, I would suggest a summary along the lines of:

I'm also sending you an isolated failure & success LAN trace example by PM, along with detailed notes on that LAN trace.  But I would not try and start your conversation with the ISP with that LAN trace.  Letting them know you do have a LAN trace if they want to see it is fine, but its better to wait and send it once they say they do want to see it, and/or have a network engineer they can pass it to.  It can be information overload to try and dump that onto a front line phone representative, and may slow down or confuse the issue.

Too bad there isn't a clearer answer, or obvious setting you could change to resolve the issue.  This feels like it would probably be an issue of the NAT inside the Sagemcom router itself, which is one obvious place where "automatic decisions of what to forward and what not to forward" are happening.  Despite the issue seeming to be related to "packet size", it doesn't seem like any "minimum MTU" (packet size) configuration of the router is in play here, else it would be failing 100% of the time, and not "randomly working."

But it still could be something at the ISP itself too, and not the router's fault.  For example, some kind of automatic "denial of service" protection heuristics the ISP employs, that defaults to believing these "small" packets aren't valid replies, except in some non-obvious case where it "randomly" allows them.

Since we haven't been looking at LAN traces of the other games that succeed, we can't say whether this issue description "makes sense" for them too.  Meaning, if we LAN traced your Counter-Strike connection attempt, would we see that all the packets are "larger" than what Battlefield 1942 tries to use in its initial connection negotiation.  Which is why they're not being subjected to the same failure.

-Trench