I'll need to analyze network traffic to find a hostname or IP address of a particular server...

[ylin0811]

i think ubisoft hosts their games on the 216.98.48.0/20 (as 22634) subnet that's announced to tata communications (as 6453). tata communications is well known for causing packet losses across the transit based off my past experience. your best bet is to contact the ubisoft email listed on the peeringdb for engineering folks at ubisoft.

 

[Gryz]

Install the game on a PC (windows, linux or mac, doesn't matter).
Then you can use the "netstat" command to look at the ip-address and portnumbers the PC is trying to connect to. If the list is long, take a snapshot before you start the game, then start the game, try to connect, alt-tab, and look at netstat again.

Different OSes have different versions of netstat, with more or fewer options. On windows7 for instance you can do: "netstat -abn -p tcp". It will show you all open TCP sockets, and the process that has opened them. The -n flag makes sure you see the ipaddresses, and not fqdn or symbolic names.
Small excerpt of my own machine:

TCP 192.168.178.24:49604 173.239.76.148:80 ESTABLISHED
[vlc.exe]
TCP 192.168.178.24:49823 213.239.154.31:443 ESTABLISHED
[palemoon.exe]

From the ip-address (in the 3rd column) you can see to what music I am listening (with vlc) and what website I am reading (with palemoon, my browser).

 

[Ichinisan]

edit: btw, keep us updated. I'm curious what the conclusions are.

Resolved January 3rd with no help from Ubisoft.

I began investigating a different issue that was apparently related. I got a couple reports that Garry's Mod (and probably other Source-engine games) could not reach particular servers. In this case, the game doesn't try to hide details about the server or port number it's failing to connect with. At first, the reports were all different machines with NFO Servers, but I later found that all external hosts were unreachable. Knowing the hostnames and port numbers, I set up connectivity tests to verify that an upstream provider was blocking port 27015 (and possibly other related ports too).

With standard port 27015...
External-to-external: Connects fine
Internal-to-internal: Connects fine
Internal-to-external: Fails
External-to-internal: Fails

With alternate port I chose at random...
External-to-external: Connects fine
Internal-to-internal: Connects fine
Internal-to-external: Connects fine
External-to-internal: Connects fine

We identified the upstream provider that was doing this and notified the operator. With proof, they finally realized their system was doing this after they initially denied blocking any ports.

They fixed it that morning. During lunch, I tested The Division and found it was also working.

Speculating: Probably a junior tech at the upstream network implemented the block to mitigate a DoS attack and left it configured that way indefinitely.

 

[Gryz]

Congrats.
And thanks for telling us how you solved it. Much appreciated.

One question. What do you mean when you say "external-to-external" ? What's external, what's internal ? Internal means inside your AS ? External means you tested via another ISP's AS ?

 

[Ichinisan]

Congrats.
And thanks for telling us how you solved it. Much appreciated.

One question. What do you mean when you say "external-to-external" ? What's external, what's internal ? Internal means inside your AS ? External means you tested via another ISP's AS ?

Yes. My external tests were performed between AT&T, Charter, and SuddenLink.

Internal tests were between 2 different cable modem connections on my ISP.