Desde aproximadamente junio de 2024 vengo sufriendo retrasos en la conexión cuando estoy conectado al router de fibra, tanto por cable como por wifi. Me sucede en juegos online, en la conexión a mi trabajo y en videos en directo o rrss.
Conectado a mi trabajo, tarda unos 5 minutos en cargar el correo electrónico, no llega a visualizar páginas web (siempre da timeout).
En juegos online tengo lag constante, desde medio segundo hasta picos de más de 30 segundos.
He abierto unas 10 incidencias al 1002 y en todas me dicen que todo está ok, cuando no es así, llevo medio año con este problema. Han venido 6 técnicos a casa, han cambiado el router 4 veces y el problema no está ni en el router ni en mi hardware, ya que cuando quito la conexión por cable al router y pongo el móvil como modem todo funciona perfectamente, sin lag ni cortes ni retrasos.
Movistar, y todos los demás ISP, quitando en todo caso algunos locales, tienen subcontratas que van a las casas. Como es natural dichos técnicos se centran exclusivamente en las competencias propias del ISP, nada más. Un técnico o un Instalador no tiene por qué diagnosticarte otro problema. Los que van a casa su funcionamiento en esencia es que la instalación en la casa sea adecuada, incluyendo la CTO a la que te conectas, y en todo caso revisar el Router, velocidad y demás conectando su propio equipo al Router y realizando las pruebas pertinentes. Nada más. Y todo ello lo habrán revisado ya unas cuantas veces y todo es correcto. Obviamente, como "el cliente siempre tiene razón" pues seguirán enviando técnicos o cambiando el Router, lo cual obviamente en muchos casos no solventa el problema... cuando el problema obviamente no es la instalación ni los dispositivos de Movistar.
En cuanto a acciones posibles por remoto, estoy segur que habrán realizado acciones del tipo revisar que la línea es correcta, que no hay problemas ni incidencias en la zona (recordemos que cualquier problema que puedas tener lo tendría igualmente cualquiera conectado a la misma CTO o en la misma zona), y que en su red no se ha identificado igualmente ninguna incidencia.
Respecto a lo que dices del nodo X y que mientras no se demuestre lo contrario. Bueno, te he demostrado y explicado de forma extensa (y te aseguro que ningún técnico de ningún ISP te lo va a explicar ni demostrar mejor de lo que lo he hecho) por qué sucede eso, y no solo eso sino que es total y absolutamente normal. No solo es normal, sino que la propia lógica y como te he demostrado también con diferentes tracert/ping que te he puesto propios, que no existe el menor problema. Incluso aplicando únicamente el sentido común sería suficiente para ver que un nodo que muestre 99% de pérdida no implica absolutamente nada si los datos siguientes son adecuados. Más aun, tb te instado a que busques información al respecto si no quieres creerlo.
Todo ello, no significa por otro lado que no puedas tener cualquier tipo de problema. Por supuesto puedes tener problemas que sean, estas pruebas tan solo demuestran que no existe ningún problema desde que los datos salen de tu Router hasta que llegan al servidor destino. Lo que pase de puertas para dentro en tu red o en el otro lado es ya otra cuestión totalmente diferente que estas pruebas no pueden diagnosticar.
Y lo de aplicar el sentido común, me refiero a que si uno entiende mínimamente como es la latencia o cuando se determina que un paquete se ha perdido, llega a entender de forma sencilla que si un nodo tuviese realmente un 99% de pérdidas, los nodos siguientes no tendrían ningún tipo de pérdida. Del mismo modo que si el destino final dice que llegan 100 de 100, no se ha podido perder NADA por el camino, así como si te dice que la latencia media es de, por poner un ejemplo, 50ms, implica que la latencia media es de 50ms al final. Y todo ello es totalmente consistentes con los datos aportados, y como te he explicado la discriminación de los paquetes ICMP, incluso mostrándote que tu propio Ruter, el mío y el de la mayoría aplica restricciones de ese tipo.
Vamos, que es cuanto menos complicado demostrarlo o explicarlo mejor.
Es lo mismo que cuando aparece alguien y dice que con una VPN el servicio X le funciona mejor que sin la VPN, así que sacan de conclusión que el problema es el ISP. Se te quedan un poco de piedra cuando les explicas que cuando te conectas a la VPN sigues pasando del mismo modo por la red de tu ISP, que si existiese un problema importante con tu ISP, el problema sería el mismo con VPN o sin VPN.
De cualquier modo, me parece adecuado que sigas realizando todas las pruebas que estimes. No solo eso, te animo a hacerlo y a ir actualizando este hilo a medida que vayas teniendo otras lecturas. Quien sabe, a lo mejor en alguna de ellas puede apreciarse cualquier tipo de incidencia en la red de Movistar, lo cual es igualmente positivo para Movistar, porque te aseguro que son los primeros interesados de que si existe algún problema en su red poder subsanarlo. No eres el único cliente de Movistar, somos muchos cientos de miles o incluso millones!! Te aseguro que cada problema o incidencia en la red de Movistar que se soluciona, TODOS nos beneficiamos.
Tanto como pagar un especialista... me extraña mucho que en una compañía tan grande de telecomunicaciones no tenga contratados ya algunos técnicos de redes, vamos si me decís que no es para echarse a temblar. De todas formas, a este respecto, dos cosas:
- Con las 6 visitas de técnicos de hardware/router que sí me ha enviado Movistar, seguro que se podían haber ahorrado 5 de ellas y asignar un especialista de redes. Desde la primera visita, el técnico que vino me confirmó que no era un problema de hardware (ni de router ni de mis equipos) y que era un problema de red.
- No he pedido que enviéis a alguien, pagarle el desplazamiento, etc. sólo he dicho que en remoto, espero que en pleno 2025 esto sea posible, estaré encantado de realizar las pruebas que he venido haciendo para que ese técnico de redes compruebe lo que tenga que comprobar, bien desde Movistar o desde su casa si está tele trabajando. Lo que no va a poder ser es en horario laboral, como ya os he comentado, este problema me impide tele trabajar, por lo que me tengo que desplazar todos los días (con el tiempo y el dinero en combustible que eso conlleva) a mi puesto de trabajo.
Dices que todas mis pruebas mostradas no ilustran ningún tipo de problema... yo ahí no estoy de acuerdo. Mis pruebas demuestran que algún nodo de movistar (los famosos xx.red-yy-yy-yy.customer,static.ccgg.telefonica.net, donde espero que ccgg.telefonica.net sea suficiente para demostrar que es un nodo de Movistar) en las conexiones que me fallan tienen un %Loss de 99 o más y en las conexiones que no fallan tienen un %Loss de 3-5. Esas son mis pruebas y aquí las he expuesto.
He solicitado ya dos veces, con esta tres, que me indiquéis cuales son las pruebas exhaustivas que se han realizado sobre mi línea y nadie dice nada, con lo fácil que sería decir esto esto y esto y aquí no hay problemas, pero no, sigo esperando a ver si alguien me las indica. Lo que me lleva a la sospecha de que o bien esas pruebas sí muestran algún fallo o directamente no se han realizado las pruebas.
No obstante, como parecen ser insuficientes voy a seguir realizando pruebas que aporten datos y resultados, a ver si conseguimos todos ver el problema que llevo sufriendo más de medio año.
En resumen, mis pruebas demuestran los problemas que describo, y aportaré más, y las de Movistar ni están ni se le esperan. No voy a dejar caer este hilo hasta que se demuestre el problema en la red o alguien demuestre lo contrario.
A pesar de que me encantaría que un ISP se pudiese permitir enviar un especialista en redes a la casa de cualquier cliente que lo solicitase, es absolutamente imposible asumir dichos costes. Como cualquier servicio que uno contrata, este llega hasta cierto punto, no va a cubrir nunca cuestiones que exceden obviamente sus competencias o sus propios servicios. El ISP obviamente tiene que asegurar que lo que es el servicio que ellos prestan, y dentro de su "jurisdicción" si lo quieres ver así, es correcto. Y es lo que hacen. Ahora bien, más allá de eso poco pueden hacer, y menos van a pagar a un especialista para que acuda a cada domicilio que lo solicite para solucionar problemas que a todas luces nada tiene que ver con ellos. Sería como pretender que el ISP te mande un ingeniero informático para formatearte un equipo y reinstalarte el sistema operativo, por poner un ejemplo simple.
Te podría hacer una lista de "problemas" habituales que encuentro en mi propia red, y que obviamente si quiero solucionar pues me toca hacerlo a mí, o tendría que contratar un especialista que lo hiciese por mí. Por mucho que quiera Movistar no va a solventar mis problemas con mi red.
Y esto es importante, por como hemos dicho gracias a estas herramientas se pueden diagnosticar todo tipo de problemas, y más importante, donde están. Y todas tus pruebas mostradas, al menos de momento, no ilustran ningún tipo de problema... ya no voy siquiera a la propia red de Movistar que es donde únicamente ellos tienen potestad, sino que no se ve ningún problema en el transporte.
Y creo que lo he dicho también, no tienes ni mucho menos que creer absolutamente nada de esto, te insto a buscar información al respecto, de como funcionan estas discriminaciones ICMP y por que razón... vivimos precisamente en la era de la información, hay montones de foros, de asistentes de IA, la Wikipedia en diferentes idiomas, estudios, pruebas... te aseguro que si viese cualquier tipo de anomalía en tus datos, sería el primero en decírtelo, como he hecho igualmente en otras ocasiones. En este caso, no veo ningún tipo de problema en transporte...
Saludos y suerte, no puedo decirte mucho más por mi lado, espero que puedas encontrar el problema y solucionarlo
Me parece buena idea dejar el hilo abierto, vamos a ver si algún usuario que haya tenido este problema o parecido ha sido capaz de solventarlo por sus medios, porque por lo que estoy viendo el soporte técnico de Movistar no es capaz de hacer nada al respecto.
Después de muchas visitas de técnicos a mi casa, varios cambios de router y demasiadas llamadas al 1002 sin solución a esto, pensé que abriendo un hilo en el Foro de Movistar de Ayuda Técnica podía hacer que algún técnico fuera capaz de interesarse por este problema, pero llevo un tiempo viendo como sólo sois capaces de preguntar si ya está resuelto el problema (resuelto sólo porque nadie ha hecho nada), o de decir que dejáis abierto el hilo para que otro usuario aporte algo.
Pedí hace algunos días si me podíais indicar cuales eran las pruebas exhaustivas que habíais realizado a mi línea para concluir que todo estaba bien y no obtuve respuesta...
Por supuesto que NO se ha resuelto el problema. Si alguno creéis que explicando la teoría de como funcionan las redes y las comunicaciones se va a resolver un problema que no es teórico si no real, creo que estáis muy equivocados.
Podríamos seguir filosofando sobre redes, capas de transporte o lo que queráis, la realidad es que por mucha explicación que aquí se escriba, cuando con unos resultados distintos se obtienen efectos distintos (Gran Loss% problemas en mi conexión y Bajo o poco %Loss todo ok) algo está ocurriendo, y la teoría no lo va a arreglar.
Como dije en unos post más atrás y parece que nadie ha reparado en ello, las clases gratuitas de redes están muy bien, y creedme que algo he aprendido de ello, pero lo que este problema requiere es un técnico de redes (que me cuesta creer que en una empresa tan grande no haya ninguno disponible) analice origen, tránsito y destino para detectar qué puede estar pasando y cómo solucionarlo. Por supuesto me ofrezco a que cuando valoréis esta opción hacer las pruebas con él que sean necesarias.
¿Nos puedes confirmar si la información que te han facilitado ha resulto tu consulta? Si ha sido así, ¿Te podemos ayudar en algo más?
Por otra parte, si consideras que tu consulta está resuelta, te agradeceríamos que en el hilo que has abierto, pulsases en el botón “Aceptar como solución” del post en el que se te ha resuelto tu caso. Es importante para nosotros que vuestras consultas queden resueltas y para otros usuarios es útil utilizar estas respuestas para sus dudas.
Precisamente lo que hacen este tipo de herramientas es medir el retraso que se va acumulando por cada tramo por los que pasan. De existir cualquier acumulación de retraso en cualquier segmento, estas herramientas lo detectan. Expuse el ejemplo de una carrera porque ilustra relativamente bien todo esto.
Tomemos 10 corredores que tienen que pasar por 10 puntos de control antes de llegar a la meta, y van saliendo uno a uno cronometrando el tiempo en cada punto de control y en la llegada. Cuando todos han llegado, se reúnen los 10 que controlaban los tiempos en cada punto.
El que estaba en la meta mide un tiempo medio de 100, y cuenta que han llegado 10 corredores. Este, el de la meta, no está valorando en que tramo han corrido más o menos, su función es simplemente que han llegado todos y el tiempo estimado.
Este es el dato fundamental con independencia de lo que pasase en medio o los datos que tengan recogido sus otros 9 compañeros. Y por física básica sabe igualmente que los 10 corredores han pasado previamente por los 9 puntos de control, o no estarían allí... no se pueden teletransportar.
Si los datos de la meta son correctos, por lo general importa bien poco en que parte del camino han corrido algo más rápido o más lentos... como si se han caído en algún momento en un tramo y han tenido que correr enormemente más rápido en otro. Es decir, si cuenta que han llegado los 10 que salieron, y el tiempo que han tardado es lo razonable.
Entonces para que están los otros puntos de control, o para que importan?? Importan si los resultados no son adecuados.Por qué?? Bueno, es obvio, si en la meta cuentan sólo 9 corredores, gracias a los puntos de control pueden saber desde que tramo dejaron de pasar los 10, y por ende saber el tramo donde uno de ellos abandonó la carrera, por ejemplo. Porque si uno abandona en el segundo tramo, en el primer punto de control seguirán siendo 10, pero ya en el siguiente contarán 9, y en el siguiente obviamente otros 9 si no ha abandonado ningún otro.
Según cuentas, dices que realmente no parece que haya un "abandono", y simplemente es que llegan tarde y luego se apelotonan en la meta. Sí, claro que podría pasar, pero es que ese escenario es precisamente otros de los que se pueden observar, ya que recordemos estamos midiendo el tiempo en la meta y en los puntos anteriores. Pero para que esto ocurra tendrían que darse dos supuestos que en tus pruebas no se dan:
1º. El tiempo medio en la meta tendría que ser mucho más alto, obviamente. Da igual que se apelotonen en el último tramo porque han ido más rápido, el tiempo medido final es el tiempo medido final.
2º. Dado que cada punto de control mide su propio registro, es muy sencillo ver más o menos el tiempo invertido en cada tramo. Si en un tramo empiezan a tropezarse o porque el suelo está enfangado, al pasar por ese punto de control con respecto al anterior o los siguientes, se verá un tiempo mayor. De echo esto es lo normal, siempre hay nodos o puntos en los que la latencia entre ellos es mínima y otros en las que es muy alta. Por eso es tan importante partir del tiempo del destino, de la meta.
Como creo que ya he dicho, no tienes por qué creerlo, simplemente te digo como funciona un Ping/Tracert y como circula el tráfico desde un origen a un destino en Internet. Es más, te invito a que busques información en Internet sobre ello para que veas como funcionan, que implican, el motivo por el cual un nodo puede exhibir un % porcentaje en paquetes perdidos que no son reales... etc etc etc.
Con respecto a nodos que dices que no aparecen en mis tracert, es básicamente por rutas dinámicas y destinos diferentes constantemente, simplemente lancé dos o tres pruebas rápidas a los primeros dominios que se me pasaron, pero eso no significa que gran parte de mi trafico no circule igualmente por dichos nodos... bueno, los mismos mismos probablemente no por geografía, hora, día, destino... te ponía los otros para que vieses que, efectivamente, daba exactamente igual que un nodo pusiese 100%, 50%, 3%... si en el destino final pone 0% son 0%, exactamente por la misma analogía de la carrera anteriormente descrita.
Dicho de otro modo... tenemos la certeza absoluta que salen 10 y llegan 10. Ahora llega el del punto de control 2 y dice que el solo ha contado a 1 por ahí... en el punto de control 2 dice que han llegado 4, el punto de control 6 dice que han pasado por allí los 10, y el punto final dice que son 10. ¿Cual es la verdad? Pues hay cosas que podemos asegurar y otras que no. Sabemos al 100%:
1. Han salido 10. De echo los paquetes los lanza tu propio equipo, el sabe perfectamente que ha lanzado 10, no 9 ni 8, sino 10.
2. Aunque en la analogía anterior hablo de una meta, los tracert/ping realmente la meta es el propio punto de origen... cuenta los paquetes que envía, y las respuesta que obtiene de cada uno de ellos. Si no obtiene respuesta de uno de ellos lo da por perdido. Así que por el mismo punto primero, si cuenta que han llegado 10 respuestas, han llegado 10 respuestas.
3. También podemos asegurar que los paquetes ni se dividen ni se clonan en mitad de camino. Es decir que si quedan 8 siguen quedando 8, no pasan a ser de forma milagrosa 9 o 10.
Si tenemos en cuenta todo ello, asumimos como es lógico que los puntos intermedios, algunos de ellos han contado mal... en la analogía de la carrera.
Dentro de Internet es aun más sencillo, porque los propios protocolos usados y la configuración tanto de Router, nodos intermedios, puntos finales... se suele discriminar el tráfico ICMP, o dicho de otro modo, es como si de antemano supieses que los puntos de control intermedio que pones en la carrera tienen el movil a mano y claro... pueden pillarles haciendo una foto o distraídos en un momento dado, y no contabilizarlo de forma correcta.
------------------------------------
La explicación por la que algunos nodos discriminan el tráfico ICMP o no, creo que ya la he dado. Por lo general es por una cuestión tan sencilla de ahorro de ancho de banda par evitar el uso de estas herramientas. En algunos casos, cuando vemos claramente un 100% en un nodo intermedio, es un bloqueo completo. Bueno, no es un bloqueo realmente porque no se bloquea nada, lo que hacen es no responder simplemente al origen, y al no responder, el origen estima que se ha perdido su paquete. Pero este valor puede ser cualquier otro número arbitrario, puede ser un 1%, un 10%, un 50%, un 99%... la única diferencia es el % de paquetes que discrimina el nodo.
El ejemplo más simple que tienes es tu propio Router. Tu propio Router está configurado para discriminar el tráfico ICMP. Captura del Firewall de un Router, esto es habitual encontrarlo en casi cualquier Router doméstico:
Por ejemplo, en este caso, el último DROP hace que mi Router bloquee el 100% de cualquier PING. Es decir, que si mi equipo hace de destino y alguien intenta hacerle un WinMTR por ejemplo, le dirá que mi equipo/Router está caído y tendrá un 100% de pérdidas. Ahora imaginemos que esa regla los permite y acepta. Vale, miremos la anterior por abajo, que vemos a la derecha "icmptype 8 limit: avg 1/sec burst 5"
Esa instrucción lo que hace es limitar los ping. No hace un bloqueo de 100%, es un bloqueo parcial. Entender como funciona en iptables esto igual sería extenderse bastante más por lo que implica el Burst 5, pero vamos digamos que con esa regla en el Firewall y quitando el DROP mencionado de la última, si alguien intentase usar una herramienta como WinMTR, dependiendo de la velocidad de envío empezaría a bloquear paquetes. El Burst 5 garantizaría los primeros 5, esos llegarían si o sí independientemente del tiempo de espaciado entre ellos. Pero a partir de ahí el sistema tan solo permitiría un ping por segundo, bloqueando cualquier otro. Desde el punto de vista de quien lanza WinMTR, le podría aparecer un % diferente. Repito que lo anterior no es exactamente como funciona Burst, pero par facilitar la lectura digamos que es así.
Bien, esto ocurre constantemente en tu propio Router, en el mío, en el de cualquiera (no es del todo cierto porque realmente no todos aplican estas restricciones básicas, pero es habitual). En un servidor final o un nodo intermedio es en esencia similar... solo que hay una enorme diferencia. En el ejemplo anterior se da por sentado que tan solo hay una persona que está realizando un ping/tracert. Un nodo final o servidor final los recibe constantemente!! Es decir, que dicho límite no solo lo disparas tú, sino que se está activando por cualquiera que en ese momento esté enviando paquetes similares a ese nodo/destino.
Ejemplo de esto... pongamos que un nodo tiene algo similar establecido. Si envías un ping por segundo de media, en principio NUNCA vas a disparar la protección. WinMTR usa por defecto 1 segundo entre cada prueba.... verdad?? FALSO!! Tú lo estás bombardeando solo con 1 por segundo, pero no sabes cuantas otras peticiones más está teniendo. Si en ese momento no existiese nadie mas en toda la red... tendrías 0% paquetes perdido. Si en la red existiese otra persona y con la misma cadencia, probablemente se te iría a un 50% de pérdida de media (si los tiempos fuesen perfectos), porque para el nodo/servidor ha alcanzado el límite de 1/seg.
Así es como funcionan estos "límites". Dependiendo de como configuren su Firewall/reglas para tratar este tráfico, podemos ver cosas tan dispares como un 0%, un 5%, un 50%, un 99% o un 100%. Piensa que además todo el ejemplo anterior es únicamente con una sola regla en iptables y muy concreta, en mi caso es avg 1/sec Burst 5, pero esos valores pueden configurarse como uno quiera, bloqueando más o menos en función. Y por supuesto, podemos quitar dicha regla también. Si la quitamos, el servidor/nodo responderá el 100% de peticiones, es decir, tendremos un 0% siempre de paquetes perdidos.
Todo ello afecta únicamente al tráfico ICMP, no al tráfico real. No podemos saber como se ve afectado el tráfico real en tránsito, porque no podemos inducir a los nodos intermedios a que nos respondan, ni siquiera la servidor final. Por eso estas herramientas son esenciales... pero tan solo para diagnosticar problemas de transmisión, no de procesamiento. Si se sabe usar e interpretar correctamente WinMTR u otro tipo de herramientas similares, podemos saber generalmente si existe cualquier tipo de problema en tránsito, sin importar si algún nodo intermedio bloquea de forma completa o parcial las respuestas ICMP.
-----------
Para terminar, lo que dices de manipulación de tráfico potencial por parte de Movistar, vamos a separar las cosas. LaLiga puede amenazar lo que quiera y con lo que quiera. Pero quien ordena un bloqueo es la justicia. Es más, y es noticia estos días, si queda demostrado que efectivamente el problema de acceso a Cloudflare era por bloqueo, este bloqueo no es porque Movistar lo haya impuesto por que le haya dado la gana, sino porque ha existido una orden judicial a los ISP para bloquear el acceso a ciertos servicios.
Cuestión muy diferente es las medidas que cada ISP aplica para bloquear el acceso a dicho servicios. Según se está viendo, algunos ISP lo han realizado por DNS, otros por IP. El juez es cierto que por lo general no impone como se debe de realizar estos bloqueos, simplemente ordena a los ISP que se bloquee. Ya ha habido muchos problemas al respecto de esto y de como cada uno lo implementa, y es posible incluso que por el modo que Movistar lo ha bloqueado le pueda caer un buen paquete, ya veremos. Ahora bien, lo que decía en el hilo de CloudFlare, no es una conspiración ni gaitas, en caso de que se confirme es un mandato judicial que lo ha ordenado, no que le haya dado la gana a Movistar hacerlo.
Hay varias cosas que no me cuadran. Creo que estás enfocando mi problema a que tengo cortes de red, no es cierto. Lo que tengo son retrasos que en algunos casos (juegos) conlleva un corte con el servidor, por timeout supongo, pero como tal, la red no se corta, se retrasa tanto que en algunos casos te echa de la partida y en otros se queda congelado hasta que "vuelve". De igual modo, y creo que desde el principio, he dicho que conectándome con el móvil como módem todo funcionaba ok. No es movistar la que falla, es el tramo de fibra o lo que sea que haya entre mi pc y el destino final (y sigo insistiendo en ese o esos nodos del tipo xx.red-yy-yy-yy.customer,static.ccgg.telefonica.net), lo que me lleva a otra cosa que me llama la atención. En tus resultados no se encuentra ningún nodo con la tipología que yo "digo" que son los que me crean el problema, cosa que aumenta mi tesis de que está ahí el problema.
Por otro lado, creo que me quieres convencer de que da igual que un nodo tenga un 95% o más de pérdidas de paquetes (o eso es lo que pone en la herramienta y digo yo que por algo estará ahí ese dato aunque tú insistas en que no es relevante) o que tenga alrededor de un 5 % de pérdidas, como ocurre cuando conecto el móvil. Como no me gusta hablar por hablar, acabo de lanzar una nueva consulta a los servidores de steam (de la web) conectado por fibra (la que me falla en juegos) y en ese "nodo problemático" sólo pierde un 3%. Es muy difícil aceptar que da igual un 99% que un 3% cuando la conexión de 99% es la que me genera los problemas y con la de 3% no tengo ninguno... de verdad que lo intento pero voy a necesitar una explicación más convincente o datos que respalden tu afirmación y no simples sentencias. Y aquí están las pruebas realizadas:
El resultado de estas pruebas es muy similar a las tuyas, con un porcentaje muy bajo de Loss%, y los efectos son los mismos, no hay problemas. El problema viene cuando una conexión con Loss% de 99 (la mía) da problemas, y eso no eres, sois, capaces de replicarlo para poder entender lo que me ocurre.
Por otro lado, comentas que "...Es más, por legislación misma, no se puede tratar una conexión de un modo u otro...". Sin embargo, ya comenté varios post más atrás que sospechaba del tratamiento de mi conexión desde que LaLiga "amenazó" a los ISPs y justo esta semana el día 10 de febrero he encontrado una noticia en un medio que no considero de propagación de bulos ni desinformación como es xataka (no la enlazo porque me tiran la respuesta para atrás por SPAM) donde se recoge que Movistar, O2 y algún otro ISP ha cortado o manipulado tráfico de usuarios por sospechas de piratería deportiva... más gasolina a mi hoguera de sospechas de que algo o alguien está, intencionada o no intencionadamente, modificando mi conexión hacia los servidores de destino de juegos. Además de la noticia he encontrado varios "tweets" (no sé cómo se llaman ahora en X) con el mismo tema.
Simplemente necesito un técnico de redes que sea capaz de ver lo que me ocurre y a su vez analizar el tráfico para detectar dónde está el problema y, a poder ser, solucionarlo. Porque salvo que haya explicaciones más convincentes o contundentes, como he dicho antes, es muy difícil aceptar que con resultados diferentes (alto Loss% problemas en juegos y bajo Loss% sin problemas) el Loss% no es un factor que pueda causar estos problemas.
