BandaAncha

  • 🔍 en 📰 artículos ⏎
  • 🔍 en 💬 foros ⏎
  • 🔍 en 👇 este 💬 foro ⏎
  • 🔍 en 👇 este 💬 tema ⏎
Regístrate Regístrate Identifícate Identifícate
Fijo

Mirad los resultados. ¿Puede ser este el problema de la zona de Torrecediera - VIGO?

1
Sunseeker
⋮

Soy de Vigo, tengo Windows XP y R-300. Desde hace unos 15 dias el emule ha muerto para mi, y se que no es cosa ni de configuraciones mias ni de servidores de emule ni nada que se parezca, ya que tengo amigos en otras zonas de Vigo que siguen bajando sin problemas. El problema esta en la red de R y ellos no nos lo quieren decir. Necesito que alguien interprete estos resultados. He puesto en una ventana de MS-Dos lo siguiente:

C:\>tracert 212.51.32.201

Traza a la dirección calcio.mundo-r.com [212.51.32.201]
sobre un máximo de 30 saltos:

1 * * * Tiempo de espera agotado para esta solicitud.
2 9 ms 10 ms 9 ms 212.51.32.65
3 13 ms * 32 ms 212.51.32.29
4 12 ms 35 ms 11 ms calcio.mundo-r.com [212.51.32.201]

Traza completa.

Se supone que hace un trazado de la ruta que sigue la señal de nodo a nodo y los tiempos entre cada uno de ellos. Y las ip's que aparecen, me imagino que seran las de los respectivos nodos.
Bien; ahi van mis preguntas.

- ¿porque en el nodo que aparece como 1, no aparecen los tiempos? ¿Sera porque no responde?

- Si hago un pin a todas las ip's que aparecen me contestan todas menos la que aparece como numero 3. ¿Es normal? ¿que pasa con R?

¿Puede ser este el problema de la zona de Torrecediera - VIGO?

Si tienes problemas no dudes en QUEJARTE. Llama al 1449 una y otra vez, a ver si se enteran esos cabrones....

Este tema está cerrado a nuevas respuestas. Abre un nuevo tema para retomar la conversación.
Dali
⋮

> Se supone que hace un trazado de la ruta que sigue la
> señal de nodo a nodo y los tiempos entre cada uno de
> ellos. Y las ip's que aparecen, me imagino que seran las
> de los respectivos nodos.

Exactamente.

> - ¿porque en el nodo que aparece como 1, no aparecen los tiempos? ¿Sera porque no responde?

No. Si no respondiera, no se incluiría en la ruta, vaya, no podría pasar al siguiente salto (y sólo aparecerían asteriscos a partir de ahí). Lo que sucede es que ese gateway no ha enviado el paquete de "tiempo excedido", o lo ha enviado con un tiempo de vida demasiado pequeño para llegar de vuelta.

> - Si hago un pin a todas las ip's que aparecen me contestan todas menos la que aparece como numero 3. ¿Es normal?

Sí, es normal. Algunas máquinas no responden a los pings, especialmente si son servidores Windows. Es decir, que no responda a los pings no quiere decir que esté "down", si no que no está escuchándolos.

Viendo además cómo bloquean puertos los de R sin saber muy bien lo que hacen porque son así de negados, es lógico que el resultado sea imprevisible.

> ¿que pasa con R?

Que son una panda de ladrones y de chapuceros sin puta idea de comunicaciones, que bien podrían dedicarse a sexar pollos en lugar de a tocar los huevos timando a la gente. (En mi humilde opinión).

> ¿Puede ser este el problema de la zona de Torrecediera - VIGO?

Sí y no. El problema es que sus routers están mal configurados, que su red es una mierda, o las dos cosas. La verdad, la gente que sabemos un poco ya nos temíamos esto cuando la gente empezó a contratar R en masa: No hay infraestructura para tanto tráfico. Si haces un ping a esa misma máquina a la que has hecho la traza, comprobarás que se pierden paquetes. No sólo desde Vigo, yo estoy en A Coruña y un 30% de los pings se pierden por el camino. Es más, los que vuelven, lo hacen con latencias totalmente heterogéneas, lo cual es alucinante, ya que ni siquiera hemos salido de la red de R. Os aseguro que con ADSL estas cosas no pasan.

🗨️ 6
✖
MainFrame
⋮

Esto es con ADSL 256 de la timo desde cerca de Vigo, (curioso el mundo de las redes, que se tiene que ir hasta la red de retevisión para enrutar el paquete a Galicia 8-) ).

1 3 ms 2 ms 2 ms 172.26.0.1
2 57 ms 59 ms 61 ms 10.1.141.1
3 55 ms 57 ms 56 ms 211.Red-80-58-23.pooles.rima-tde.net[80.58.23.211]
4 74 ms 72 ms 73 ms 153.Red-80-58-79.pooles.rima-tde.net [80.58.79.153]
5 75 ms 76 ms 72 ms 217.Red-80-58-73.pooles.rima-tde.net [80.58.73.217]
6 68 ms 69 ms 72 ms 2.Red-80-58-74.pooles.rima-tde.net [80.58.74.2]
7 68 ms 70 ms 71 ms 110.Red-80-58-72.pooles.rima-tde.net [80.58.72.110]
8 71 ms 71 ms 72 ms 213.0.250.18
9 65 ms 69 ms 69 ms retevision-1.espanix.net [193.149.1.6]
10 70 ms 69 ms 72 ms MADR-R5.red.retevision.es [62.81.4.103]
11 79 ms 79 ms 79 ms rcable-icatm15373-madr.red.retevision.es [62.81.127.194]
12 82 ms * 82 ms 212.51.32.29
13 81 ms 83 ms 79 ms calcio.mundo-r.com [212.51.32.201]

Es curioso que la penúltima máquina NUNCA da el segundo tiempo de respuesta.
Esto son pings (con el parámetro -t para que los haga seguidos) a las máquinas. Como podéis comprobar no hay pérdida de ningún paquete.

Respuesta desde 212.51.32.29: bytes=32 tiempo=77ms TDV=242
Respuesta desde 212.51.32.29: bytes=32 tiempo=74ms TDV=242
Respuesta desde 212.51.32.29: bytes=32 tiempo=73ms TDV=242
Respuesta desde 212.51.32.29: bytes=32 tiempo=75ms TDV=242
Respuesta desde 212.51.32.29: bytes=32 tiempo=74ms TDV=242
Respuesta desde 212.51.32.29: bytes=32 tiempo=76ms TDV=242
Respuesta desde 212.51.32.29: bytes=32 tiempo=76ms TDV=242
Respuesta desde 212.51.32.29: bytes=32 tiempo=75ms TDV=242
Respuesta desde 212.51.32.29: bytes=32 tiempo=77ms TDV=242
Respuesta desde 212.51.32.29: bytes=32 tiempo=76ms TDV=242
Respuesta desde 212.51.32.29: bytes=32 tiempo=75ms TDV=242
Respuesta desde 212.51.32.29: bytes=32 tiempo=77ms TDV=242
Respuesta desde 212.51.32.29: bytes=32 tiempo=75ms TDV=242
Respuesta desde 212.51.32.29: bytes=32 tiempo=78ms TDV=242
Respuesta desde 212.51.32.29: bytes=32 tiempo=77ms TDV=242
Respuesta desde 212.51.32.29: bytes=32 tiempo=75ms TDV=242
Respuesta desde 212.51.32.29: bytes=32 tiempo=77ms TDV=242

Este es el otro:

Respuesta desde 212.51.32.201: bytes=32 tiempo=79ms TDV=241
Respuesta desde 212.51.32.201: bytes=32 tiempo=75ms TDV=241
Respuesta desde 212.51.32.201: bytes=32 tiempo=76ms TDV=241
Respuesta desde 212.51.32.201: bytes=32 tiempo=74ms TDV=241
Respuesta desde 212.51.32.201: bytes=32 tiempo=76ms TDV=241
Respuesta desde 212.51.32.201: bytes=32 tiempo=76ms TDV=241
Respuesta desde 212.51.32.201: bytes=32 tiempo=78ms TDV=241
Respuesta desde 212.51.32.201: bytes=32 tiempo=76ms TDV=241
Respuesta desde 212.51.32.201: bytes=32 tiempo=76ms TDV=241
Respuesta desde 212.51.32.201: bytes=32 tiempo=75ms TDV=241
Respuesta desde 212.51.32.201: bytes=32 tiempo=77ms TDV=241
Respuesta desde 212.51.32.201: bytes=32 tiempo=77ms TDV=241
Respuesta desde 212.51.32.201: bytes=32 tiempo=77ms TDV=241
Respuesta desde 212.51.32.201: bytes=32 tiempo=81ms TDV=241

En cuanto a los asteriscos, como bien dices pueden ser máquinas que no responden a los pings (pero a mí sí me responden). Cuando no responden, es la mayoría de las veces por seguridad. Los pings y los traceroutes son la manera más habitual de comenzar un ataque, ya que dan información sobre el tipo de máquina y el sistema que corre en ella (por el nº de TDV con el que responde), así que no contestan en muchos casos.
La gran pregunta es: ¿por qué a mí me responde y a vosotros no?¿no se fían de sus clientes?¿saturáis las máquinas con los pings? :-P

Salu2.

🗨️ 2
✖
Sunseeker
⋮

Dices en tu ultima "Gran pregunta" que si saturamos la red con los pings. Digo yo, si a ti te deja hacerle un ping, podria todo dios saturar la linea desde fuera de R. Todos podrian hacer ping excepto los de R. ¿? No lo entiendo. Se supone que si no responde a un ping por razones de seguridad, no deberia responderle a nadie. No se, pero esto me huele muy mal. ¿Puede ser una de las razones por las que el emule no va? Es que he pasado de medias de 25, 26 KB/s a medias de 2 o 3 (y poniendo limite de Upload de 2 KB/s). Y todo de un dia para otro. Asi, de golpe. Es que estos la han liado en Vigo de "carallo". Yo me doy de baja como no lo solucionen pronto.

Un Saludo :-)

🗨️ 1
✖
MainFrame
⋮

...pero no entiendo por qué no podeis hacer ping desde dentro. Eso sí, si no contesta es porque ellos lo han configurado así. Que el emule no vaya puede ser por mil cosas que no suelen tener que ver con el ping. Puede que la red esté saturada o mal configurada. Me parece que la única manera de que lo arreglen es que sufran quejas de la gente de la zona muy a menudo, con amenazas de cambiar de operador. Eso suele funcionar para todas las operadoras, pero si protestan uno o dos pasarán del tema. Si la red se les ha quedado pequeña pues tendrán que ponerse las pilas, pero hacérselo saber. Suerte.

Salu2.

Sunseeker
⋮

Muchas gracias por tus aclaraciones, sobre todo, comparto tu opinion sobre R.

Tu eres usuario de R? Aunque no lo seas, prueba hacer un ping a 212.51.32.29 y me comentas los resultados. Porque tengo la impresion que yo no puedo, pero los demas si.

Saludos.. Gracias... :-)

🗨️ 2
✖
BocaDePez
⋮

una pregunta, q parece q controlais del tema. Si se hace un traceroute a una ip como la que ha hecho el compañero... los paketes van recorriendo los nodos y ponen un ping hasta llegar a la ip de destino. mi pregunta es, el ping total, es decir el ping con la ip de destino cual es? la suma de los q da cada nodo? es que en la mayoria de programas de traceroute te da como ping "total" la media de los pings q se obtuvo en cada nodo, y la verdad no lo comprendo.

salu2

🗨️ 1
✖
MainFrame
✎
⋮

Para empezar, me gustaría... pero no, no controlo del tema :-) El tipo de paquete que se usa para ping y traceroute es el mismo (protocolo ICMP), pero con diferentes opciones.
Los tiempos que te pone al lado de cada nodo cuando haces un traceroute son el ping a ese nodo, efectuado tres veces (en el caso del MS-DOS). Bueno, en realidad son un poquito más altos que si haces ping en lugar de traceroute, porque el paquete que envía traceroute necesita un poco más de procesamiento por parte del nodo de destino que el que envía ping.
Puedes probarlo tú mismo con los comandos "ping" y "tracert" del MS-DOS, no hacen falta programas.Otra cosa: el ping no es estático, es decir, depende de tu red, de la hora del día, de si hay problemas, etc... es una herramienta de diagnóstico. Si haces varios pings, unos tardarán más y otros menos, y si hay problemas con tu conexión (nodos caídos, red saturada, configuraciones de red chungas en tu ordenador), pues tardará muchísimo más que en circunstancias normales. Como es un tiempo que varía, la mayoría de programas hacen unos cuantos y te devuelven el resultado medio, que es lo más normal. Pero si haces un tracert a una IP y luego un ping, verás que los resultados en el tracert son un poquito mayores, pero casi iguales. Espero haberte aclarado algo :-P

Salu2.

Editado: joer... si lo llego a saber no me tiro todo este rollo. Imakoki lo tenía ya explicado en este post del foro de Menta, y además con un ejemplo muy ilustrativo:

Post de Imakoki

BocaDePez
⋮

No te mates, es cosa de R. Mi novia vive tambien en torrecedeira tiene winxp y cable 300 y tiene unas medias de mierda con el emule y ya probamos todas las configuraciones, versiones, mods y nada. Y no se porque pero desde hace unos dias va muchisimo peor.

🗨️ 1
✖
Dali
⋮

Según parece, R filtra y altera los paquetes TCP y UDP que circulan por su red, y todo ello según una política de oscurantismo total, con lo cual nos podemos matar a configurar mil cosas pensando que es culpa nuestra, cuando en realidad es suya y sólo suya.

De hecho, más o menos se lo confesaron a un colega que tiene LAN 300 (bueno, tenía, porque visto lo visto la ha dado de baja). El tío pidió que le abrieran todos los puertos y le contestaron que "no podían" porque tenían una limitación en la propia red que se lo impedía. Deben usar algunos bits del campo DPT de los paquetes, o sabe Dios qué otra estupidez, para propósitos tan desconocidos como demenciales. Con un operador así de chapucero vamos mal, amigos. Lo del proxy de (T) por lo menos se publicitó, y es una medida mil veces más aceptable que cualquier cosa de las que hace R, por mucho que nos fastidie.