Can't connect to servers because of router?

Trench · 2018-01-13 19:41:53

ziba128 wrote:

As I understand, this is what is received from BF1942 server through 23000-23009 ports which aren't responsible for "playing" itself. But this is all what is received (I checked the whole list sorting by IP) - no other ports like 14567.

Yes, the 23000 port work is just for server status and information, and we're only seeing the "return" (reply) data in this screen shot, because the view was sorted by source IP address. But there "must" be port 14567 traffic in this LAN trace, because we saw your game connection attempt make it all the way to the server in our server-side LAN trace. So even if the port 14567 connection attempt didn't get a reply, we should still see the outbound attempt in your LAN trace. In theory it's also possible we might see something else in response, such as an ICMP message indicating some declaration of why the traffic failed and/or was dropped.

If you're willing, I'd be happy to take a look at the actual LAN trace. Meaning, if you save the entire trace as native .PCAPNG format, and send that for analysis. I presume the forums don't take an attachment like that, but if you email it to our [email protected] email address, I could get it that way. If you wanted to use Dropbox or something else and PM the link, that's fine too.

It looks like you "did it right". You don't need to define any capture filters or anything complicated like that; just start the capture, which should default to all interfaces or at least the "Ethernet" interface, and then minimize it and go start the game and try to connect. Once the game has failed to connect (or maybe, if you take another LAN trace, keep trying until it happens to succeed once, so we can see that difference too within the same trace) you can just exit the game, stop the LAN trace in Wireshark, and save it to .PCAPNG format.

ziba128 wrote:

No difference between connections, both are Public, and all settings are same.

Too bad. That felt like a difference for "I've changed ISPs and now something doesn't work" that we (or at least I) had been overlooking until now. But another possibility to scratch off the list.

-Trench

ziba128 · 2018-01-13 22:22:02

Trench wrote:

Yes, the 23000 port work is just for server status and information, and we're only seeing the "return" (reply) data in this screen shot, because the view was sorted by source IP address. But there "must" be port 14567 traffic in this LAN trace, because we saw your game connection attempt make it all the way to the server in our server-side LAN trace. So even if the port 14567 connection attempt didn't get a reply, we should still see the outbound attempt in your LAN trace.

Yes, it's there.

Trench wrote:

If you're willing, I'd be happy to take a look at the actual LAN trace.

It'd be great if you did that.
2 unsuccessful attempts (separately) and one successful (with around 10 attempts):
https://yadi.sk/d/pqG8IB_y3RRoDZ
https://yadi.sk/d/SUsXVAi-3RRoDT
https://yadi.sk/d/WyVnfIWO3RRpBs - successful

Trench · 2018-01-13 23:55:20

ziba128 wrote:

2 unsuccessful attempts (separately) and one successful (with around 10 attempts):

Hey, that LAN trace is actually very interesting.

The LAN trace is showing that your local machine does receive responses back, all the way through your ISP and local gateway/router. But the responses look "wrong", meaning corrupted or invalid. My guess at this point in the analysis is that the responses are being intentionally dropped by your local Battlefield 1942 game itself. The question is whether the responses actually are invalid, and/or have been modified in a bad way when coming back through the ISP and/or local router.

Could you do the same LAN trace again, but this time connecting to the EA117 server again? I have to step out of the office for a bit, but I'll leave a LAN trace running there all day, until you say you've attempted to connect. I want to compare what the Battlefield 1942 server's "actual response" was, against the response that we will see in your trace when you capture the exact same conversation locally.

Same as before, don't worry about any "map not found / mod not found" response if you don't have DesertCombat installed; that's a "success" response so far as we're concerned. We're just looking to capture one or more instances of the "simply doesn't connect / does nothing" symptom, when you're attempting to connect to this server, same as any other server.

Once you have it, just save and make that LAN trace available same as you did the others, and I'll stop and compare it to the LAN trace I'm capturing here.

-Trench

Trench · 2018-01-17 18:30:43

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:

When the customer is attempting to connect to Battlefield 1942 game servers through their Sagemcom F@st 3686 cable modem and AKADO-Stolitsa ISP, the attempt usually fails. "Randomly" the connection attempt will work, typically after trying dozens of failed attempts.
With help from one of the public Battlefield 1942 game servers, it has been confirmed that the communication to and from the Battlefield 1942 game server's UDP port 14567 is ALWAYS able to successfully occur between the workstation and the server, but ONLY when the transmitted packet size is "large."
For example, even though numerous 55-byte UDP port 14567 responses were sent from the server back to the workstation, NONE of those responses actually reach the client workstation. But every 556-byte UDP port 14567 response sent from the server back to the workstation ALWAYS reaches the workstation.
But then "randomly", one of the small 55-byte UDP port 14567 responses actually DOES reach the workstation, and it’s in those cases that we see "finally a successful Battlefield 1942 game connection, after dozens of failed attempts."
Therefore it seems like something in the Sagemcom F@st 3686 cable modem configuration, or something the AKADO-Stolitsa ISP is doing, is "usually" preventing "small" replies to UDP port 14567 from being able to pass back in to the customer's workstation. Notwithstanding that "sometimes" it randomly works even for "small" replies, too.

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

Last edited by Trench (2018-01-17 18:32:22)

bud · 2018-01-18 02:36:41

Take one of your computers and start a bf server on it, Lan or Internet doesnt matter, then try connect to it with your other computer (IP and Port if you start server as "Internet").

The port number doesnt seem to matter much, as he already tried another more unconvential port. 37.187.19.136:33333:44444 Jeep race

Can try another port tho if you think that matters, it take less than a minute to change.

seventy · 2018-01-18 03:41:01

sunny, are you still not playing this game or what?

Trench · 2018-01-18 16:38:40

A test to confirm that connecting to a Battlefield 1942 game server between two Windows machines within the local network (i.e. not dependent on going through the router or ISP) certainly doesn't hurt.

Note the fact that the local LAN trace doesn't show the server's replies (which the server-side LAN trace confirms actually are happening) is an indication that the Windows machine's the network interface never saw those replies. As opposed to something locally within the workstation blocking the application from receiving the reply. Meaning, the LAN trace is showing the reply is blocked somewhere before the Windows machine's network interface, which would be the router or the ISP itself.

You're right about there still not appearing to be any consistency or pattern to "which local/ephemeral port numbers fail." When connecting to SiMPLE, 51272, 51273, 56693, 56696, 56698, 55734, 55738, 55740, 55742, 55744, 55746, 55748, 55750, 55752, 55754 and 55756 all failed. Technically a connection from 55736 "worked", although the game ultimately still failed to connect, because the reply that was allowed was delayed longer than the application would wait for it. The successful connection to SiMPLE then happened using port 55758.

Connecting to EA117, 63007, 60122, 60124, 60126, 60128, 60130, 63159, 63161, 63163, 63165, 63169, 54001, 63169, 54003, 54005, 55222, 55224, 52579, 52581, 52583, 52585, 52612, 52614, 52616, 52618, 52620, 62912, 62914, 62916, 62943, 62945, 62947, 49684, 49685, 49687, 49689, 49691, 49693, 49695, 49697, 49699, 49701, 64618, 53818, 53820, 53822, 53824, 53826, 53828, 51442 and 51444 all failed. The successful connection to EA117 then happened on 51446.

So even though 5127x ports failed, 51446 succeeded. And even though 5522x ports failed, 55736 and 55758 succeeded. Just didn't read like "there is a block of ports that always work when the workstation happens to attempt to use them", and seemed more consistent with a dynamic decision to allow the traffic.

-Trench

bud · 2018-01-19 11:01:55

Turns out windows have a set value of dynamic UDP ports. Managed to change these values for testing, dont know if this can help in this particular case, but its easy enough to give it a try.

You can view the dynamic port range on a computer that is running Windows

netsh int ipv4 show dynamicport udp

This command sets the dynamic port range. The start port is number, and the total number of ports is range. The following is sample command:

netsh int ipv4 set dynamicport udp start=10000 num=1000

Playing in BFO server

Trench · 2018-01-19 19:00:09

bud wrote:

Turns out windows have a set value of dynamic UDP ports.
...
This command sets the dynamic port range. The start port is number, and the total number of ports is range. The following is sample command:
netsh int ipv4 set dynamicport udp start=10000 num=1000

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

ziba128 · 2018-06-14 11:35:46

So, a few days ago my laptop got an 1803 update for Windows, and after all was done I decided (just out of interest) to check if something has changed in BF multiplayer. Guess what? It works perfectly. I can connect to any server and play. No changes were done to the router or some settings. Total bullshit

Arkos · 2018-06-14 16:12:49

...

Some malware before? Unusual that Bf1942 is not working like that.

...

Trench · 2018-06-14 17:16:01

ziba128 wrote:

So, a few days ago my laptop got an 1803 update for Windows, and after all was done I decided (just out of interest) to check if something has changed in BF multiplayer. Guess what? It works perfectly. I can connect to any server and play. No changes were done to the router or some settings.

Well regardless of anything else, that's great news.

But I will bet all of Bud's money that it doesn't have anything to do with the Windows 1803 update, based on what we were seeing in the LAN trace from your workstation's perspective. The UDP responses ~500 bytes in size weren't getting to the machine at all, meaning there was no opportunity for Windows to have accepted or rejected due to any local firewall, policy, malware or other reason. Something upstream from your computer was dropping or blocking those.

So my assumption is that the ISP did actually fix / change / improve something, maybe even unintentionally, in the time since. And after the Windows 1803 update was just the opportunity to test and notice the change. There is also the router-based malware that the U.S. FBI has now co-opted the control domains for, but I'm not aware of that malware having the characteristic of intentionally or unintentionally dropping any traffic, if your local modem was even susceptible in the first place.

-Trench

ziba128 · 2018-06-15 17:31:31

Arkos wrote:

...
Some malware before? Unusual that Bf1942 is not working like that.
...

If only some malware blocking BF1942 multiplayer... Everything worked fine except it.

Trench wrote:

Well regardless of anything else, that's great news.
But I will bet all of Bud's money that it doesn't have anything to do with the Windows 1803 update, based on what we were seeing in the LAN trace from your workstation's perspective. The UDP responses ~500 bytes in size weren't getting to the machine at all, meaning there was no opportunity for Windows to have accepted or rejected due to any local firewall, policy, malware or other reason. Something upstream from your computer was dropping or blocking those.
So my assumption is that the ISP did actually fix / change / improve something, maybe even unintentionally, in the time since. And after the Windows 1803 update was just the opportunity to test and notice the change. There is also the router-based malware that the U.S. FBI has now co-opted the control domains for, but I'm not aware of that malware having the characteristic of intentionally or unintentionally dropping any traffic, if your local modem was even susceptible in the first place.
-Trench

You're probably right. There is a way to check if it's 100% not Windows update but I'm too lazy for it

SiMPLE | Forum

Announcement

#31 2018-01-13 19:41:53

Re: Can't connect to servers because of router?

#32 2018-01-13 22:22:02

Re: Can't connect to servers because of router?

#33 2018-01-13 23:55:20

Re: Can't connect to servers because of router?

#34 2018-01-17 18:30:43

Re: Can't connect to servers because of router?

#35 2018-01-18 02:36:41

Re: Can't connect to servers because of router?

#36 2018-01-18 03:41:01

Re: Can't connect to servers because of router?

#37 2018-01-18 16:38:40

Re: Can't connect to servers because of router?

#38 2018-01-19 11:01:55

Re: Can't connect to servers because of router?

#39 2018-01-19 19:00:09

Re: Can't connect to servers because of router?

#40 2018-06-14 11:35:46

Re: Can't connect to servers because of router?

#41 2018-06-14 16:12:49

Re: Can't connect to servers because of router?

#42 2018-06-14 17:16:01

Re: Can't connect to servers because of router?

#43 2018-06-15 17:31:31

Re: Can't connect to servers because of router?

Board footer