Pérdida de paquetes jugando a Overwatch

yandrako
Más integrado que la RDSI
Pérdida de paquetes jugando a Overwatch

Buenas a todos.

Tengo un problema bastante específico que en el 1002 no me han sabido resolver y que me recomendaron que escribiera por aquí para ver si alguien tenía alguna solución.

El problema en cuestión es cuando juego al juego de Blizzard Overwatch. Llevo un año jugando sin problemas hasta que desde hace un par de semanas pierde la conexión con sus servidores al poco de empezar a jugar. Tras hablar con tres técnicos de Blizzard y hacer innumerables pruebas (actualización drives, reseteo de ip, dns y router repetidas veces, y muchas pruebas más) terminamos con una prueba de análisis de paquetes con el programa WinMTR. La conclusión que sacaron sus técnicos y es que hay algún problema entre movistar y sus servidores que hace que se produzcan pérdidas de paquetes que provocan las desconexiónes (a tener en cuenta que se pierde la conexión con blizzard pero no a internet, que funciona perfectamente).

Sé que es un problema muy específico pero si alguien se le ocurre alguna posible solución que no haya probado se lo agradeceré eternamente porque ahora mismo no puedo jugar en absoluto.

Mensaje 1 de 6
1.060 Visitas
5 RESPUESTAS 5
Theliel
Yo probé el VDSL

Buenas @yandrako

 

Pueden ser mil cosas, pero como siempre, mucho más importante que todo eso es ver esas pruebas que dicen unos u otros de pérdida de paquetes. Digo esto porque es extremadamente habitual que se hable de pérdida de paquetes simplemente porque un tracert o un ping arrojen en sus estadísticas lo que ellos llaman "pérdida de paquetes", que no son tales.

 

Haz un tracert a sus servidores, pon los resultados y a ver que pasa.



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 2 de 6
1.023 Visitas
yandrako
Más integrado que la RDSI

Buenas, gracias por contestar. Los resultados del tracking the paquetes son estos, pero al margen de que se vé pérdida yo no alcanzo a entender más:
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 1533 | 1533 | 0 | 0 | 11 | 0 |
| 192.168.144.1 - 0 | 1533 | 1533 | 2 | 5 | 67 | 3 |
| 109.red-80-58-82.staticip.rima-tde.net - 4 | 1346 | 1299 | 3 | 5 | 70 | 5 |
|90.red-81-46-8.customer.static.ccgg.telefonica.net - 0 | 1533 | 1533 | 3 | 5 | 16 | 5 |
|et-15-0-0-0-400-grtmadde2.net.telefonicaglobalsolutions.com - 0 | 1533 | 1533 | 3 | 6 | 119 | 4 |
| 84.16.15.120 - 1 | 1482 | 1469 | 3 | 4 | 34 | 3 |
| lag-13.ear1.Madrid2.Level3.net - 95 | 320 | 16 | 0 | 342 | 1902 | 23 |
| No response from host - 100 | 307 | 0 | 0 | 0 | 0 | 0 |
| BLIZZARD-EN.ear2.Paris1.Level3.net - 3 | 1402 | 1369 | 22 | 22 | 31 | 22 |
| 37.244.9.33 - 8 | 1178 | 1089 | 22 | 23 | 47 | 23 |
| 37.244.9.101 - 5 | 1295 | 1235 | 25 | 26 | 32 | 26 |
| 185.60.115.149 - 9 | 1142 | 1044 | 21 | 23 | 449 | 22 |
| No response from host - 100 | 307 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 307 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 307 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 307 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 307 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 307 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 307 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 307 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 307 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 307 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 307 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 307 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 307 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 307 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 307 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 307 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 307 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 307 | 0 | 0 | 0 | 0 | 0 |
|________________________________________________|______|______|______|______|______|______|

Mensaje 3 de 6
1.014 Visitas
Theliel
Yo probé el VDSL

Buenas @yandrako

 

A eso me refería, que la nomenclatura que se usa hay que saber interpretarla. Cuando un tracert/ping habla de paquetes pertidos, lo que se refiere es que no se obtuvo respuesta de los paquetes enviados por estas pruebas. El problema es que estas pruebas hacen uso del protocolo ICMP para para ello, y cada vez más nodos/servidores bloquean parcialmente/completamente su uso, o lo priorizan, o... dicho de otro modo...

 

Un ping funciona porque el origen envía un paquete especial llamado Echo Request a un destino, y el mismo protocolo está diseñado para que el destino responda a ese Request con un Echo Reply. El origen por tanto puede contar el tiempo que pasa desde que él envía el Request hasta que llega el Reply, y a eso lo llamamos latencia. Pero el destino puede estar configurado para no responder a esos Request, o responder de forma selectiva, o... este tipo de tráfico se usa sólo para fines de diagnóstico, con lo que bloquearlo o priorizarlo es legítimo. El problema es que si el servidor destino te responde por ejemplo 5 de 10, la herramienta te dirá a ti que ha perdido el 50% de paquetes, y en este caso no es que haya perdido el 50%, sino que no ha respondido a un 50% de esos Request porque está configurado de dicho modo.

 

La pérdida de paquete al igual que la latencia es acumulativa. Si por ejemplo en el primer salto tenemos una pérdida de un 5% por ejemplo, es esperable que en el salto siguiente sea de al menos ese % (+- una desviación asumible estadísticamente). En el salto 3 la cosa sería igual o peor... etc etc etc. Bien, dicho esto analicemos WinMTR que has lanzado:

 

Salto 1-6: Todo está bien. Fíjate que supusetamente en el salto 3 dice que hay 4 pérdidas, pero en el  5 no hay ninguna... esto es un ejemplo de lo explicado anteriormente. Para poder llegar al salto 4 los paquetes han pasado antes por el 3, si realmente en el 3  hay 4 pérdidas, es esperable que en el 4 haya una pérdida similar, puesto que se habrían perdido al pasar por el salto 3 y quedaría reflejado en el 4.

 

Al salto 6 llega con una latencia media de 4ms, lo cual es un valor más que bueno, y es importante porque hasta este punto, con IP 84.16.15.120, estamos aun dentro de la red de Movistar, es más... será el último nodo que pertenezca a Movistar.

 

Salto 7: Vemos que de forma abrupta aparece 95 paquetes perdidos y latencias disparadas de 342ms. Si tan solo viésemos el salto 7 de forma aislada podríamos interpretar muchas cosas diferentes, el problema es que el salto 9 nos cuenta otra realidad, en el salto 9 (luego te explico el salto 😎 vemos que tan solo hay 3 paquetes perdidos  y una latencia media de 22ms. Si en el salto 9 que está por encima tenemos una latencia de 22ms y 3 paquetes perdidos tan solo, se llega a la conclusión rápida de que en este salto el nodo pertinente está priorizando o bloqueando parcialmente el tráfico ICMP. Dado este comportamiento, directamente la lectura que tenemos de latencia también deja de tener importancia para nosotros. Sí, dice que el peor resultado fue de 1902ms, una barbaridad!! pero es que está priorizando este tráfico e incluso descartándolo. Si fuese una pérdida real o con esa latencia, los datos de los consiguientes saltos serían coherentes con estos datos.

 

A todo eso ahora tienes que sumar que dicho nodo ya pertenece a la red de Level3, con lo que todo lo que pase a partir del nodo 6 (Red de Movistar) en adelante, Movistar no podría hacer nada, la responsabilidad será a quien pertenezca la red donde esté el problema. En este caso sería de Level3, pero por ahora no vemos ningún problema.

 

Salto 8: Es muy habitual este tipo de resultado, y lo vemos por ejemplo también a partir del salto 13. En este caso el bloqueo ICMP es total. El nodo intermedio no responde ni a un paquete con TTL 0 (usado para descubrir nodos) ni a los Echo Request, con lo que sí, sabemos que en ese punto hay un nodo intermedio cuya IP y operador desconocemos, y no podemos saber nada de él. Vemos que pone un 100% de paquetes perdidos, cuando realmente de  nuevo no hay una pérdida de paquetes, simplemente es un nodo que no responde a nada.

 

Salto 9: El salto 9, por el nombre, es el peering entre Level3 y Blizzard. Aquí si tenemos datos consistentes, 3% de pérdida (supuestamente) y una latencia media de 22ms, un buen resultado. Si los datos de los nodos anteriores fueran reales en tanto latencias o % de paquetes perdidos, aquí tendría que reflejarse también, pero en cambio estos datos son igualmente consistentes con el salto 6. Nos dice que hasta este punto por tanto todo es correcto, y dado que ese 3% es mínimo podemos tomar por bueno los vlaores de latencia, sin importar en principio si ese 3% es real o no.

 

A partir de aquí, ojo, ya dejamos la red de Level3, y pasamos a la red de Blizzard. Es decir, todo lo que pase a partir de ahora ya no es responsabilidad ni de Movistar ni de Level3, sino de  la propia Blizzard.

 

Salto 10-12: Los datos siguen siendo más o menos consistentes, vemos un incremento en paquetes perdidos que podría ser real, pero de nuevo vamos de 3  del  salto 9, a 8, luego a 5, luego a 9... estadísticamente podría variar un poco, pero te aseguro que no varían un 4% entre dos nodos, luego me dice que dichos saltos están priorizando igualmente el tráfico ICMP. Pese a ello, pese a no priorizarlo de todos modos, como te digo estaríamos ya en la red de Blizzard, con lo que el  único responsable serían ellos mismos. La latencia en cambio es consistente, llegamos a una media de unos 23-26ms, que no está nada mal, por no decir que es un resultado muy bueno.

 

Salto 13+: Por último, pasa lo mismo que en un salto anterior... pero en este caso dado que a partir delsalto 12 ya no existe ningún nodo o servidor final que responda, no podemos saber cuantos nodos más había después... puede que el nodo 13 fuese el servidor final (posiblemente), o puede que fuese el 14... pero no podemos saberlo, lo que está claro es que sea el servidor final uno u otro, este está configurado para no responder a pruebas de este tipo. No nos importa demasiado realmente, porque ya estamos en la red  de blizzard y muy posiblemente el servidor final sea el 13 o 14, y con los datos que tenemos de los anteriores solo caben dos conclusiones:

 

a) el servidor final tiene un problema serio -> Culpa de Blizzard
b) El problema que puedas tener, si es que existe, no queda reflejado en este tipo de herramientas -> Culpa de ¿?

 

 

-------------

 

No, no hay pérdida de paquetes, al menos hasta el punto que podemos ver, que sería justo antes del servidor final de Blizzard.

 

Para nada digo que las desconexiones no sean reales, pero al menos a tenor de los datos que traes, el problema lo tienen los amigos de Blizzard en su lado, tus paquetes llegan bien a  su red. Otra cosa muy diferente es que la desconexión sea debido a tu extremo, es decir, tu equipo/red, pero entonces tendríamos que ver si te conectas por cable o WIFI, si tienes instalado cualquier tipo de antvirus o suite de seguridad que esté afectando a la conexión... etc etc etc. Pero ya te digo que el problema está en uno de los dos extremos, o dentro de tu casa (y tu eres el responsable) o en el servidor final (Blizzard).

 

No puedes hacer nada por parte del lado de Blizzard, así que sí te aconsejo revisar tu red, asegurarte a usar siempre cable y no WIFI, no usar nunca antivirus y otras suites de seguridad que por lo general hacen mucho más daño que bien... probar con otro PC para descartar otros problemas... etc etc etc.



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 4 de 6
991 Visitas
yandrako
Más integrado que la RDSI

En primer lugar te agradezco mucho la extensa explicación que me has dado. Me has aclarado y enseñado muchas cosas que no tenía ni idea.

En las posibles soluciones que comentas siempre he usado cable en la conexión y no tengo antivirus precisamente porque me ha dado más problemas que otra cosa. A mi me extraña que sea el problema mi lado porque llevo jugando un año sin ningún problema y desde el nuevo parche es cuando he tenido problemas, yo no he cambiado nada en el pc (que yo sepa al menos) para que haya cambiado nada por mi parte, pero claro nunca se sabe. Intentaré buscar un PC para confirmar el problema o tratar de formatear (cosa que quería evitar y más sabiendo que es probable que no solucione tampoco nada).

En cualquier caso muchas gracias por la respuesta.

Mensaje 5 de 6
986 Visitas
Theliel
Yo probé el VDSL

Buenas @yandrako

 

Si me estás diciendo que desde una actualización del juego el problema ha aparecido... casi que sería mejor ahorrarte el probar en otro PC, y es problema evidente de Blizzard :). No es algo nuevo, hace ya unos meses tuvieron problemas similares con los usuarios de ONO por problemas varios, y tardaron meses en solucionarlo, y el problema estaba en su lado.

 

Ya te digo que la han liado con algo :), puede ser algo que les afecte específicamente a los usuarios que le entran por el peer de Level3 citado o a nivel más general, pero por lo que nos indicas... bastante claro.



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 6 de 6
980 Visitas