I would have all of you do a tracert to the patchserver and compared is there is a router (hop) in comman thayt is faling.
Do a nettest and compare results
(post both here also)
then take the info you collected to you ISP to see if they can engineer the cause of the problem.
(this assuming you all are having the same cuase and not one a firewall, another a modem problem etc.)
Tracing route to patchserver.crypticstudios.com [208.95.184.25]
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms wireless.colubris.com [192.168.3.1]
2 4 ms 2 ms 4 ms 12.159.138.1
3 7 ms 4 ms 10 ms 12.119.239.229
4 22 ms 21 ms 27 ms gbr2.cb1ma.ip.att.net [12.123.40.126]
5 77 ms 23 ms 22 ms cr2.cb1ma.ip.att.net [12.122.5.65]
6 25 ms 23 ms 22 ms cr1.phlpa.ip.att.net [12.122.28.114]
7 31 ms 28 ms 22 ms cr1.n54ny.ip.att.net [12.122.5.241]
8 28 ms 36 ms 20 ms n54ny01jt.ip.att.net [12.122.81.57]
9 36 ms 20 ms 20 ms 192.205.36.118
10 37 ms 39 ms 23 ms vb2000d1.rar3.nyc-ny.us.xo.net [207.88.13.38]
11 53 ms 48 ms 27 ms ae0d0.mcr1.cambridge-ma.us.xo.net [216.156.0.26]
12 33 ms 31 ms 30 ms 216.55.4.18
13 3356 ms 3009 ms 2848 ms patchserver.crypticstudios.com [208.95.184.25]
Trace complete.
It was working well last week. We're not sure what has changed.
Your ISP may require data beyond ICMP (tracert and ping). If that is the case you can use Ping Plotter, WinPcap, and traces with TCP 7255 to patchserver.crypticstudios.com.
That information can be found at the bottom of this post.
Tracing route to patchserver.crypticstudios.com [208.95.184.25]
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms wireless.colubris.com [192.168.3.1]
2 4 ms 2 ms 4 ms 12.159.138.1
3 7 ms 4 ms 10 ms 12.119.239.229
4 22 ms 21 ms 27 ms gbr2.cb1ma.ip.att.net [12.123.40.126]
5 77 ms 23 ms 22 ms cr2.cb1ma.ip.att.net [12.122.5.65]
6 25 ms 23 ms 22 ms cr1.phlpa.ip.att.net [12.122.28.114]
7 31 ms 28 ms 22 ms cr1.n54ny.ip.att.net [12.122.5.241]
8 28 ms 36 ms 20 ms n54ny01jt.ip.att.net [12.122.81.57]
9 36 ms 20 ms 20 ms 192.205.36.118
10 37 ms 39 ms 23 ms vb2000d1.rar3.nyc-ny.us.xo.net [207.88.13.38]
11 53 ms 48 ms 27 ms ae0d0.mcr1.cambridge-ma.us.xo.net [216.156.0.26]
12 33 ms 31 ms 30 ms 216.55.4.18
13 3356 ms 3009 ms 2848 ms patchserver.crypticstudios.com [208.95.184.25]
Trace complete.
It was working well last week. We're not sure what has changed.
Take a look at my routing from Dallas on to Cryptic. This is the routing I've seen since beta.
10 42 ms 57 ms 55 ms cr1-tengig0-7-5-0.Dallas.savvis.net [204.70.200.170]
11 80 ms 81 ms 81 ms cr2-pos-0-8-5-3.NewYork.savvis.net [204.70.196.129]
12 90 ms 81 ms 83 ms er1-te-2-0-1.NewYork.savvis.net [204.70.197.9]
13 90 ms 80 ms 79 ms 208.173.129.62
14 295 ms 119 ms 95 ms border2.po1-20g-bbnet1.nym008.pnap.net [216.52.95.3]
15 86 ms 88 ms 101 ms mpr2.te7-3.bsn004-nym008.phi.pnap.net [216.52.93.222]
16 92 ms 85 ms 88 ms border12.te7-1-bbnet1.bsn.pnap.net [63.251.128.42]
17 104 ms 111 ms 86 ms cryptic-1.border12.bsn.pnap.net [63.251.130.10]
18 98 ms 94 ms 87 ms patchserver.crypticstudios.com [208.95.184.25]
Browsing all the information I've seen you post, I recall it being mentioned that these ports and packets of these sizes are commonly used for file sharing via P2P, yes? Is that possibly why they get blocked?
Browsing all the information I've seen you post, I recall it being mentioned that these ports and packets of these sizes are commonly used for file sharing via P2P, yes? Is that possibly why they get blocked?
If you look at a list of registered port numbers you can get an idea of what is in the TCP 7000 - 7500 range
As far as an ISP identifying packet size and port usage, I would think that would be up to each ISP policy.
However it would not be unlikely that an ISP would throttle or give low priority to non HTTP, HTTPS, VoIP traffic, for example. TCP 7000 - 7500 would fit this case, but it depends on the ISP.
Comments
Do a nettest and compare results
(post both here also)
then take the info you collected to you ISP to see if they can engineer the cause of the problem.
(this assuming you all are having the same cuase and not one a firewall, another a modem problem etc.)
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms wireless.colubris.com [192.168.3.1]
2 4 ms 2 ms 4 ms 12.159.138.1
3 7 ms 4 ms 10 ms 12.119.239.229
4 22 ms 21 ms 27 ms gbr2.cb1ma.ip.att.net [12.123.40.126]
5 77 ms 23 ms 22 ms cr2.cb1ma.ip.att.net [12.122.5.65]
6 25 ms 23 ms 22 ms cr1.phlpa.ip.att.net [12.122.28.114]
7 31 ms 28 ms 22 ms cr1.n54ny.ip.att.net [12.122.5.241]
8 28 ms 36 ms 20 ms n54ny01jt.ip.att.net [12.122.81.57]
9 36 ms 20 ms 20 ms 192.205.36.118
10 37 ms 39 ms 23 ms vb2000d1.rar3.nyc-ny.us.xo.net [207.88.13.38]
11 53 ms 48 ms 27 ms ae0d0.mcr1.cambridge-ma.us.xo.net [216.156.0.26]
12 33 ms 31 ms 30 ms 216.55.4.18
13 3356 ms 3009 ms 2848 ms patchserver.crypticstudios.com [208.95.184.25]
Trace complete.
It was working well last week. We're not sure what has changed.
That information can be found at the bottom of this post.
http://forums.startrekonline.com/showthread.php?p=2281229#post2281229
Take a look at my routing from Dallas on to Cryptic. This is the routing I've seen since beta.
I've got patch server IP (208.95.184.25) and nettest IP (208.95.184.10) and I have the ports that the comm traffic travels (80, 443, and 7000-7500.)
Are there any other IPs that actual gameplay traffic travels to/from? And any additional ports the traffic travels on?
Thanks!
If you are NOT using a proxy server, it will be 208.95.18x.TRIBBLE for the IPs (I've seen 208.95.184.10 through 208.95.187.TRIBBLE so far).
TCP 80, 443, and 7000 - 7500
That is for patching and game play.
You might note to them that over 50% of the packets are between 40 and 79 bytes in length, including the header.
If you look at a list of registered port numbers you can get an idea of what is in the TCP 7000 - 7500 range
http://www.iana.org/assignments/port-numbers
As far as an ISP identifying packet size and port usage, I would think that would be up to each ISP policy.
However it would not be unlikely that an ISP would throttle or give low priority to non HTTP, HTTPS, VoIP traffic, for example. TCP 7000 - 7500 would fit this case, but it depends on the ISP.