Banda Ancha EU

Comunidad de usuarios
de fibra, móvil y ADSL

hosting en interdominios
110 lecturas y 20 respuestas
  • Cerrado

    Checksum error en paquetes UDP con 20Mb

    Bueno, estoy preparando pruebas y demás para postear mi experiencia con los 20Mb que despues de una odisea por fin tengo (1 mes sin teléfono+ 1 semana con otro numero...etc, y era prioritario por una reclamacion que le envié al Pujals con anterioridad por 7 meses de engaño)

    El caso es que en la parte de pruebas que estaba llevando a cabo, el juego que mas uso, Unreal Tournament 99 no me saca lista de servidores.

    Los reconoce pero a la hora de lanzar ping, no responde ni uno (NOTA: a traves de un terminal en modo texto hago ping perfectamente a todas direcciones.)

    Snifé con Ethereal y observo que el checksum de todos los paquetes udp que lanza mi juego hacia los servidores es incorrecto.

    Alguien sabe de que puede ir esto?

    Me suena a capado.

    Saludos.

    Este tema es antiguo y puede contener información obsoleta. Abre un nuevo tema para publicar tu mensaje.
    1
    • Cerrado

      Bueno, pues poniendolo en ppoE va de lujo :D. Me carga todo…

      Bueno, pues poniendolo en ppoE va de lujo :D. Me carga todo como con los 6mb, de pm,ya puedo hacer las pruebas de ping, aunque ya se me ha echo tardísimo.

      Mira que no dan ni una estos de Jazztel, les llame para comprobar los datos de conexion y tanto en la carta como por tfno me dijeron ppoA

      Saludos,

      Ya seguiremos, me voy a la cama , que desknseís :D

      • Cerrado

        Por cierto, mirar que curioso. Arriba tracer con ppoA y abajo…

        Por cierto, mirar que curioso. Arriba tracer con ppoA y abajo con ppoE

        katana@wtc:~$ tracepath 82.133.85.65
        1: 10.0.0.2 (10.0.0.2) 0.339ms pmtu 1500
        1: 10.0.0.254 (10.0.0.254) 0.966ms
        2: 10.0.0.254 (10.0.0.254) asymm 1 0.987ms pmtu 1492
        3: 10.255.0.254 (10.255.0.254) 41.112ms
        4: 82.133.85.65 (82.133.85.65) asymm 27 140.623ms reached
        Resume: pmtu 1492 hops 4 back 27
        katana@wtc:~$ tracepath 82.133.85.65
        1: 10.0.0.2 (10.0.0.2) 0.308ms pmtu 1492
        1: 10.0.0.254 (10.0.0.254) 1.021ms
        2: 87.218.131.1 (87.218.131.1) 36.778ms
        3: 10.255.0.254 (10.255.0.254) 39.646ms
        4?: reply received 8)
        Resume: pmtu 1492
        katana@wtc:~$ tracepath 82.133.85.65

        De todos modos en ppoA cambie el mtu a 1492. Creo que no iba, mañana lo confirmo.

        Saludos.

          • Cerrado

            :) Muchas gracias por la observación, pero Jazztel es mi ISP,…

            :) Muchas gracias por la observación, pero Jazztel es mi ISP, en principio y no bandaancha. (Digo en principio pq desdeluego que es mucho mas fiable la información de aqui que la que ofrece Jazztel)

            El caso esque ayer, despues de 1001 odiseas :D llame a Jazztel para confirmar los datos que me enviaron en la carta, para que luego no hubiera confusiones.

            Me confirmaron ,al igual que la carta que la conexión era ppoA.

            Lo configuré y todo iba de pm.menos lo que comento del juego.

            Ayer a altas horas ya :) me dio por ponerlo en pppoE ( segun tu se ha dicho muchas veces que los 20Mb van por pppoE, lo siento, yo no me enteré o ya tenía los datos en la carta que me envió Jazztel, MI ISP, y no me fijé) y casualemente todo de lujo.

            Hoy llamo a Servicio Técnico de Jazztel y les pido que me pasen con un """""""""""""""""""""""""""""""""""""""""""técnico"""""""""""""""""""""""""""""""""""""""""
            . Le comento el problema de las peticiones UDP con pppoA y despues de 3 minutos con musica me cuelgan.

            Segunda llamada, le advierto que no se le ocurra colgarme que me acaban de colgar y que me pase con un técnico. Me atiende el mismo y me dice que hice lo correcto pq la conexión es pppoE.
            Le informo que tanto por carta como por la noche me aseguraron que era ppoA. Asi que parece un error por parte de Jazztel.

            No se si será algo normal, pero eso deberían rectificarlo. Si la gente usa pppoA con los 20Mb pq Jazztel envie cartas asegurando que es pppoA (espero que mi caso sea aislado)mucha gente puede tener problemas con las peticiones UDP que no son contestadas y afectar a juegos y aplicaciones en tiempo real.

            Muchas gracias a todos por echarme una mano ;)

            Saludos

            • Cerrado

              Enhorabuena por haber resuelto el problema. Lo que el…

              Enhorabuena por haber resuelto el problema.

              Lo que el bocadepez no ha sabido transmitir es el asombro de que los 20 megas te funcionasen en absoluto con PPPoA.

              Por cierto, el cambio de MTU que tienes que hacer no es en el modem (o router) sino en el sistema operativo mismo. Más información en el hilo del RWIN, que mencioné en una intervención anterior.

    • Cerrado

      [Editado 2/12/05 09:30]

      NOTA: Tb probé a poner el pc en el router en modo DMZ para…

      NOTA: Tb probé a poner el pc en el router en modo DMZ para ser totalmente visible a la wan y desactive firewall. Exactamente igual que antes , sin solucción.

      Bueno la chapuza temporal que he encontrado ha sido:

      Usar los 6Mb para sacar la lista de servidores.
      Luego conectar los 20 y jugar.
      Asi si puedo hacerlo

      De momento el problema creo que es que con los 20Mb no puedo recibir las respuestas de mis peticiones por udp.

      Un saludo.

    • Cerrado

      BocaDePez BocaDePez
      6

      NO ES DEL SO. Estoy con Windows y aunque curiosamente aqui el…

      NO ES DEL SO.

      Estoy con Windows y aunque curiosamente aqui el checksum si me da bueno, pero no recoge la lista de serviores. Voy a arrancar linuz y os voy a poner trazas con las 2 conexiones que tengo para que os quedeís alucinados de las trazas de los 20Mb , a ver quien me lo puede explicar :D.

      • Cerrado

        Perdon por no haberme logeado. Hay os pongo las trazas.…

        Perdon por no haberme logeado. Hay os pongo las trazas.

        trazas con ADSL 6Mb Jazztel:

        katana@wtc:~$ tracepath www.jolt.co.uk
        1: 10.0.0.2 (10.0.0.2) 0.307ms pmtu 1500
        1: 10.0.0.1 (10.0.0.1) 4.080ms
        2: madhou.jazztel.es (212.106.217.82) 65.836ms
        3: madhou.jazztel.es (212.106.217.13) 66.873ms
        4: g6-0-1.core01.mad05.atlas.cogentco.com (130.117.23.173) asymm 10 87.656ms
        5: p6-0.core02.par02.atlas.cogentco.com (130.117.0.21) asymm 9 88.110ms
        6: p12-0.core01.par01.atlas.cogentco.com (130.117.1.230) asymm 9 88.307ms
        7: p13-0.core01.lon02.atlas.cogentco.com (130.117.1.121) asymm 10 93.517ms
        8: lon1-9.nildram.net (195.66.224.59) asymm 7 98.489ms
        9: jolt-gw.nildram.net (195.149.20.214) asymm 8 98.211ms
        10: 82.133.85.65 (82.133.85.65) asymm 8 98.859ms reached
        Resume: pmtu 1500 hops 10 back 8

        katana@wtc:~$ tracepath www.bandaancha.st
        1: 10.0.0.2 (10.0.0.2) 0.322ms pmtu 1500
        1: 10.0.0.1 (10.0.0.1) 1.490ms
        2: madhou.jazztel.es (212.106.217.82) 66.456ms
        3: madhou.jazztel.es (212.106.217.43) 66.644ms
        4: 80.91.67.69 (80.91.67.69) asymm 10 88.066ms
        5: 193.149.1.134 (193.149.1.134) asymm 4 67.966ms
        6: 62.100.116.194 (62.100.116.194) 69.306ms
        7: no reply

        katana@wtc:~$ tracepath www.rediris.es
        1: 10.0.0.2 (10.0.0.2) 0.323ms pmtu 1500
        1: 10.0.0.1 (10.0.0.1) 3.089ms
        2: madhou.jazztel.es (212.106.217.82) 65.733ms
        3: madhou.jazztel.es (212.106.217.43) 66.004ms
        4: g6-0-0.core01.mad05.atlas.cogentco.com (130.117.23.45) asymm 10 88.161ms
        5: 193.149.1.26 (193.149.1.26) asymm 16 100.685ms
        6: ESP.SO1-0-0.EB-IRIS2.red.rediris.es (130.206.240.125) asymm 15 100.328ms
        7: 130.206.220.67 (130.206.220.67) asymm 15 100.093ms
        8: sun.rediris.es (130.206.1.2) asymm 16 101.148ms reached
        Resume: pmtu 1500 hops 8 back 16

        katana@wtc:~$ tracepath www.google.com
        1: 10.0.0.2 (10.0.0.2) 0.361ms pmtu 1500
        1: 10.0.0.1 (10.0.0.1) 3.858ms
        2: madhou.jazztel.es (212.106.217.82) 66.364ms
        3: madhou.jazztel.es (212.106.217.4) 67.227ms
        4: g6-0-0.core01.mad05.atlas.cogentco.com (130.117.23.45) asymm 10 115.823ms
        5: p6-0.core02.par02.atlas.cogentco.com (130.117.0.21) asymm 9 87.995ms
        6: p15-0.core01.fra03.atlas.cogentco.com (130.117.0.17) asymm 9 99.101ms
        7: no reply

        trazas con ADSL 20Mb Jazztel:

        katana@wtc:~$ tracepath www.jolt.co.uk
        1: 10.0.0.2 (10.0.0.2) 0.322ms pmtu 1500
        1: 10.0.0.254 (10.0.0.254) 19.996ms
        2: 10.0.0.254 (10.0.0.254) asymm 1 0.918ms pmtu 1492
        3: 10.255.0.254 (10.255.0.254) 47.664ms
        4: 82.133.85.65 (82.133.85.65) asymm 27 141.168ms reached
        Resume: pmtu 1492 hops 4 back 27
        katana@wtc:~$ tracepath www.bandaancha.st
        1: 10.0.0.2 (10.0.0.2) 0.282ms pmtu 1500
        1: 10.0.0.254 (10.0.0.254) 0.921ms
        2: 10.0.0.254 (10.0.0.254) asymm 1 0.990ms pmtu 1492
        3: 10.255.0.254 (10.255.0.254) 43.122ms
        4: no reply

        katana@wtc:~$ tracepath www.rediris.es
        1: 10.0.0.2 (10.0.0.2) 0.287ms pmtu 1500
        1: 10.0.0.254 (10.0.0.254) 0.993ms
        2: 10.0.0.254 (10.0.0.254) asymm 1 0.957ms pmtu 1492
        3: 10.255.0.254 (10.255.0.254) 44.799ms
        4: sun.rediris.es (130.206.1.2) asymm 10 36.575ms reached
        Resume: pmtu 1492 hops 4 back 10
        katana@wtc:~$ tracepath www.google.com
        1: 10.0.0.2 (10.0.0.2) 0.307ms pmtu 1500
        1: 10.0.0.254 (10.0.0.254) 21.502ms
        2: 10.0.0.254 (10.0.0.254) asymm 1 0.913ms pmtu 1492
        3: 10.255.0.254 (10.255.0.254) 54.936ms
        4: no reply
        ¿ Que puede significar todo esto? Tendrá que ver algo con los fracasos en la recepcion de respuesta a mis peticiones UDP??

        • Cerrado

          La única diferencia (aparte de las rutas distintas, normal ya…

          La única diferencia (aparte de las rutas distintas, normal ya que las redes de salida para 6M y 20M son distintas) que veo es que con los 20 megas le MTU es de 1492. Supongo que se debe a que con los 6M te conectas con PPPoA y con los 20M con PPPoE. Ajusta el MTU a 1492 a ver si hay problemas por fragmentación IP. Lo raro es que no recibas respuesta --a nivel del Ethereal--: pedir información suele ser bastante compacto, así que los problemas de fragmentación se deberían dar con las respuestas. Podrías revisar con Ethereal el tamaño de los paquetes UDP de ida y vuelta con los 6 megas, a ver si alguno supera los 1492 y pudiera estar causando el problema.

          • Cerrado

            me gustaria que me explicaras de donde sacas esta…

            me gustaria que me explicaras de donde sacas esta información:

            Supongo que se debe a que con los 6M te conectas con PPPoA y con los 20M con PPPoE

            Mas abajo, en un comentario mio sabrás porque ;)

            Muchas gracias por tu ayuda, a los demás tambien :)

            Un saludo

            • Cerrado

              [Editado 24/11/05 23:00]

              Es curioso que hagas la pregunta, porque el tema surgió…

              Es curioso que hagas la pregunta, porque el tema surgió gracias a que usaste tracepath en vez de traceroute o derivados. Fíjate cómo en la traza de los 20 megas hay siempre una IP duplicada:

              1: 10.0.0.254 (10.0.0.254) 19.996ms
              2: 10.0.0.254 (10.0.0.254) asymm 1 0.918ms pmtu 1492

              ¿Por qué repetir una IP? Pues porque se ha averiguado algo importante (y es una de las razones por las que se puede usar tracepath): que en esa ruta, la máquina 10.0.0.254 saca tramas de un máximo de 1492 octetos (aka bytes).

              Una trama es como un paquete pero a nivel de enlace, es decir, entre una máquina y la siguiente. Ethernet permite tramas con hasta 1500 octetos de datos, pero en el viaje por la red, tu paquete puede encontrarse enlaces más restrictivos. En ese caso IPv4 divide el paquete en 2 y la máquina final (a nivel de red, no de enlace) los une. El programa tracepath detecta qué máquinas realizan fragmentación y te lo indica. En este caso, te dice que en el enlace de salida de 10.0.0.254 la trama está limitada a 1492 octetos de datos.

              A grandes rasgos: 1492 es 1500 - 8. 1500 es el límite de datos de Ethernet; 8 es el tamaño del encabezado PPP (*). Por tanto, si encapsulas los datos mediante PPP y los mandas por Ethernet (PPPoE), 1492 es el límite real de datos si quieres evitar la fragmentación en ese enlace. Puede encontrar más información de cómo optimizar la conexión en base a este número en el hilo acerca del RWIN.

              Editado: (*) Por lo que he leído, quizás el encabezado PPP sea sólo de 6, pero el MTU varía de 8 en 8, así que de 1500 hay que saltar a 1492. Espero no haber metido la pata mucho mas. :-)

              Editado2: Corrijo lo anterior: el MTU puede variar de uno en uno (octetos), con lo que el relleno no puede ser de sólo 6. El número mágico que mencioné se refiere al tamaños de datos de un paquete IPv4 fragmentado (excepto el último fragmento), que ha de ser mútiplo de ocho.

              • Cerrado

                6
                sí son 8, no recuerdo cómo era exactamente.. 2 bytes de PPP y…

                sí son 8, no recuerdo cómo era exactamente.. 2 bytes de PPP y 6 de.. PPPoE :P

                www.speedtouch.com/ST610%5CWhitePapers/WhitePaper_EncapsOverheads.pdf

                eso + ip va dentro de una trama ethernet.. de ahi los 1492..

                El comtrend creo que cuando estás en PPPoE cambia el mtu de los paquetes salientes con una regla en la tabla mangle de iptables.. cuando me funcionaba pppoe lo vi.. :P

      • Cerrado

        xDDDD PErdona que no me fijara antes, no leí el título de tu…

        xDDDD PErdona que no me fijara antes, no leí el título de tu mensaje la primera vez que lo vi xDDDD

        Mu buena esa, sorry por no pasarme a decirtelo,

        Saludos ;)

    • Cerrado

      [Editado 23/11/05 23:56]

      Muchas gracias a todos por contestar. La verdad que es uy…

      Muchas gracias a todos por contestar.

      La verdad que es uy razonable lo que decis.

      Además si hago ping correctamente a traves de un terminal, no me debería dar error en el juego.

      Que cosas :D

      Pero sabeis lo mas curioso

      Tengo ahora mismo 2 lineas

      Esta de 20 Mb y otra de 6Mb tb de Jazztel

      Simplemente cambio de puerta de enlace y uso una u otra segun me conevnga(mas ahora que ando probando)

      Lo realmente ilogico,segun vuestro planteamiento esque solamente poniendo la linea de 6Mb sin tocar nada del juego, carga toda la lista de servers y no me da ningun fallo de checksum el ethereal.

      PD: Voy a poner windows y me quito de dudas... mira que me da perreza hacerlo... pero bueno :D todo por la causa

      Pero pongo los 20 megas y no lista los servidores :S

      Alguna otra posibilidad?

      • Cerrado

        Detectaste que los checksum UDP están corruptos con la…

        Detectaste que los checksum UDP están corruptos con la configuracion 20M (UDP de salida, supongo). ¿Ocurre lo mismo con los 6M?

        Si los 6M no traen error de checksum, sólo se me ocurre que no estés usando Ethernet (estoy suponiendo que el Ethereal puede escuchar en cualquier interfaz de red). En este caso, es posible que haya problema de controladores, por ejemplo por cambiar entre PPPoE y PPPoA (aunque si dices que sólo cambias la puerta de enlace... muy mal programados tienen que estar ;-)).

        Si por contra sí hay error de checksum, parecería que los servidores del Unreal usan este campo de forma poco ortodoxa. En este caso la observación de Luke sobre el cambio de TTL es muy relevante: si en la red de los 20M (y no en la de los 6M) se está cambiando el TTL, también estarán siendo modificados (o más bien corregidos) los checksum, con lo que los servidores de juego se estarán despistando. No sé lo correcto que es que un ISP se dedique a modificar los paquetes, pero usar el checksum para transportar información me parece una barbaridad (idealmente, un router descartaría paquetes así para no saturar la red con información incorrecta).

        A ver si encuentras las razones y una solución y nos cuentas una buena historia.

    • Cerrado

      [Editado 23/11/05 23:33]

      6

      Er.. no es por nada, pero si lo ves con ethereal, y son los…

      Er.. no es por nada, pero si lo ves con ethereal, y son los paquetes salientes, es tu equipo el que provoca el fallo :P lo que ve el ethereal es incluso antes de salir por el cable..

      edito: en la red de madrid modifican el TTL de los paquetes, espero que este fallo no sea por algo parecido..

      • Cerrado

        6

        aunque modifiquen el TTL, el juego debería tener prevista la…

        aunque modifiquen el TTL, el juego debería tener prevista la modificación y actuar en consecuencia.

    • Cerrado

      Buenas. Lo primero comentar que si, el error lo detecta el…

      Buenas.

      Lo primero comentar que si, el error lo detecta el etheral en los paquetes salientes, dichos paquetes aun no han alcanzado tu tarjeta de red o tu modem ADSL, asi que en el caso de que dicho fallo fuera el causante del error en el unreal tournament, no es culpa del ADSL, sino de tu equipo/sistema/etc.

      Se me ocurre que pruebes con otros juegos, incluso con esos programas que hacen ping a una serie de servidores. Quizás sea algun firewall o filtro que tenas como programa; tambien que si usas un chipset nforce 3 o 4, el checksum se lo deje tu sistema al hardware.

      Un saludo.