Problema al inicio de VRC 1.0

[Eugenio Grigorjev 816591]

Muchos de ustedes están comenzando a usar el nuevo software VRC 1.0, y aprovechando sus nuevas virtudes.

 

Es importante en este punto poner sobre aviso a todos los que no dominan bien el idioma inglés, y que están teniendo un problema recurrente, que según mis investigaciones en Argentina es un problema ampliamente difundido, y que no está al alcance de ningún usuario resolverlo.

 

¿Cuántos de ustedes reciben el siguiente mensaje de error al iniciar VRC?:

 

ERROR:

Could not retrieve server list from network. Using the cached server list and user-defined servers.

 

Este mensaje de error recurrente me llevó a plantear el tema en los foros de VRC, sin mucho éxito al principio, ya que sólo recibí por respuesta que seguramente debía trat[Mod - Happy Thoughts] de:

 

a) Un problema de configuración de mi ordenador o mis sistemas operativos.

b) Un problema de configuración o instalación de mi programa antivirus.

c) Un problema de configuración o instalación de mi firewall.

d) Una combinación de todos los anteriores.

 

Para hacer el diagnóstico, se me pidió que me conectara a internet con el antivirus y el firewall deshabilitados, opción que no consideré segura bajo ningún punto de vista, y me negué rotundamente a hacerlo.

 

Me dediqué a partir de ello a buscar una forma de determinar qué es lo que ocurría, por lo tanto me puse a analizar las comunicaciones entre VRC y VATSIM, para ver por qué motivo ASRC funciona correctamente y por qué VRC no funcionaba en mi caso.

 

Analizando las comunicaciones, encontre como primera diferencia el hecho de que mientras ASRC realiza sólo una interrogación a VATSIM de la que obtiene todos los servidores que están en línea, VRC realiza TRES interrogaciones:

 

a) En la primera interrogación obtiene qué URLs están en línea con la información actualizada de los servidores.

b) En la segunda interrogación obtiene de una de esas URL previas qué servidores están en línea.

c) En la tercera interrogación obtiene cuál es la última versión del software, para actualizarlo.

 

Así las cosas, descubrí que mientras ASRC directamente busca la información del URL que tiene dentro del código, VRC obitene la información de un URL que descarga primero de internet.

 

Algo debía ocurrir relacionado con ese procedimiento, pero no entendía bien por qué.

 

Analicé la respuesta que obtenía en la segunda interrogación, y descubrí que esa respuesta era un error 404.

 

Hice la misma interrogación que el programa hace en forma manual, y sin embargo recibí la información correcta. Por lo tanto determiné que había un error en la construcción de la consulta.

 

En efecto, por algún motivo, la interrogación se realizaba en dos partes (con un salto de campo en el medio).

 

Sucede que existe una diferencia entre los servidores bajo Linux y los servidores bajo Windows:

 

Mientras en los sistemas Windows cada renglón se termina con un carácter "CR" (Carriage Return), en los sistemas Unix/Linux incluyen dos caracteres de control: "CR" y "LF" (Line Feed).

 

De este modo, el contenido de la respuesta (texto) que recibe el programa, termina con un carácter de control (CR) dado que es un servidor apache (Linux).

 

El programa simplemente ignora el último carácter, y construye la siguiente interrogación con la URL obtenida, más el protocolo que va en la sentencia de la interrogación:

 

GET (URL) HTTP/1.1

 

Pero existe un PROXY que casi todos los proveedores de internet (ISP) en Argentina usan, (de una breve encuesta descubrí que los operadores más grandes de Argentina lo usan: Fibertel, Telefónica de Argentina, Telecom, Ciudad Digital... y faltaría investigar Tutopía, Alternativa Gratis, Full Zero, etc.) este tipo de PROXY se llaman PROXYS TRANSPARENTES, y consisten en un intermediario que nadie sabe que tiene, pero que genera algunos cambios indeseados:

 

El PROXY TRANSPARENTE (transparent proxy) agrega al final de cada transacción un carácter (LF) de modo que SIEMPRE la respuesta va a contener un LF al final de una transacción, haciéndola diferente de la que VRC espera, y por lo tanto provoca que la interrogación planteada más arriba se convierta en:

 

GET (URL) (LF) HTTP/1.1

 

Esto en una línea de programación se convierte en:

 

GET (URL)

HTTP/1.1

 

Obviamente, cuando el programa busca "HTTP/1.1" como nombre de una página, esta no existe, y retorna error 404.

 

Mientras yo realizaba toda esta investigación, paralelamente el propio desarrollador arribaba más o menos a la misma conclusión.

 

La solución a este problema es ridículamente sencilla, y consiste en reformular el "p[Mod - Happy Thoughts]o" del programa, haciendolo "transparente" a los proxies transparentes (valga la rebuznancia).

 

No obstante, esto requiere sí o sí una modificación del código de programación en la fuente misma del programa. Y por lo tanto no hay más remedio que esperar al lanzamiento de la revisión 1.1 de VRC.

 

Ross ya está en conocimiento, y está trabajando sobre la reparación de este inconveniente, y esperamos que pronto estará disponible para la actualización.

 

Me gustaría (ya que estamos) saber desde el resto de latinoamérica, quiénes más han tenido este mismo inconveniente.

 

Aquellos que al iniciar VRC reciban el mensaje de error que figura al comienzo, por favor indíquenlo a continuación, señalando:

 

- De qué país son, y

- Qué proveedor de internet tienen (ISP).

 

Esto busca determinar:

 

1) Impacto aproximado en este programa de una falla en la programación de VRC que no es más que unos pocos caracteres en una sentencia de programa.

2) Qué tan extendido en toda sudamérica está el uso de los PROXIES TRANSPARENTES (ya obsoletos en los países desarrollados).

 

Gracias por su paciencia y por su comprensión.

 

Seguramente pronto tendremos una solución.

 

Saludos,

[Javier Larroulet]

Hola Eugenio

Gracias por la muy detallada explicacion de la genesis del problema. (no quiero saber como lo hiciste, jejeje, pero me imagino que tiene algo que ver con un poco de ingenieria reversa?)

 

En fin, aca tengo el mismo problema. Se de varios usuarios de aca de Chile que tienen el mismo problema, aunque no sabria decirte que ISP tienen. Sin embargo, me atrevo a decir que al menos Terra (O Telefonica, que es lo mismo) y VTR Internet tienen ese problema.

 

Quizas lo del transparent proxy no sea algo que los ISP hagan deliberadamente. Quizas tenga algo que ver con los enlaces submarinos de fibra optica, que los proveedores de conectividad en todo el continente comparten para mont[Mod - Happy Thoughts] al backbone de internet.

 

Bueno, esa es la informacion que puedo ofrecerte... voy a ver si logro hacer algo de ingenieria social con mi proveedor de internet (aunque, con su habitual eficiencia, es poco probable que los telefonistas entiendan de lo que les este hablando... en fin no pierdo nada con tratar)

 

saludos!

[Eugenio Grigorjev 816591]

Hola Javier:

 

No hace falta hacer ingeniería inversa en este caso (además de ser -cuanto menos- políticamente incorrecto) sólo supervisé un poco de lo que entra y sale de mi computadora justo cuando el programa se inicia, algo absolutamente lícito.

 

La verdad es que a mí no me queda del todo claro el motivo por el que algunos proveedores usan transparent proxies, pero aquí en Argentina está muy difundido. Elucubro cosas como enmascaramientos de IPs, bloqueo de tráfico no deseado, o simplemente ocultar los verdaderos IPs sobre los que están trabajando... vé tu a saber.

 

La cuestión importante aquí es que el problema se detecto, y es (hasta cierto punto) un bug de VRC. Digo "hasta cierto punto" porque VRC funciona perfectamente bien siempre y cuando el proveedor no use un proxy de este tipo, mi discusión con Ross (el desarrollador de este software) es que si la rutina que hace el "parsing" del string que contiene el URL estuviera bien hecha (fail safe) esto no debería haber ocurrido.

 

La realidad es que él no previó la existencia de estos proxies, y eso hizo que cierto numero de usuarios encontraran este problema. Según Ross, es menos que el 1% de los casos... yo creo que un poco más.

[Javier Larroulet]

Entiendo (la verdad lo de la ingenieria reversa entiendo que es bastante ilegal, pero la verdad no se me ocurrio anoche una forma mas facil de hacerlo, pero tienes toda la razon)

 

Vaya uno a saber que motivo hay para tener un transparent proxy por estos lados. De mi proveedor, en todo caso, no me extraña porque son los campeones del mundo en ponerle mugre a la conexion (desde traffic shaping, bloqueo de puertos, etc). El verdadero motivo no lo he podido averiguar, pero voy a ver que puedo hacer con un par de llamadas por telefono.

 

Nota aparte, creo que en Peru tambien tienen el problema. Me han contactado un par de usuarios peruanos desde que salio VRC y ambos me han preguntado por el mismo problema.

 

Finalmente, concuerdo con el tema de programar "en fail safe". Ahora bien, quizas Ross ni siquiera se imagino que algo asi pudiera existir

 

saludos

[Nicolás Sebastían Colanero]

Eugenio, EXCELENTE ANALISIS Y CONCLUSIÓN!!! me impresionó el nivel de detalle.

 

Te cuento, yo estudio Ing. en Sistemas en Argentina y hacer reverse engineering es totalmente licito si la información obtenida no se utiliza con intenciones de perjudicar a alguien. Por lo menos en Argentina, mucha legislación tampoco hay.

 

El tema del Transparent Proxy es bien sencillo, los proveedores de Internet necesitan ahorrar ancho de banda, por ende instalan Caches que guardan todo lo que la gente navega por períodos de tiempo según la cantidad de veces que se requieren esos datos, ahorrando así la conexión que va del cliente al recurso en simplemente conexiones locales (cliente - ISP), para simplificarla bastante, es como el Cache del explorer, es más barato tomar un contenido en la esquina de tu casa (tu ISP) que en el Congo Belga donde esta basado ese contenido. Lo hacen transparente por una cuestión de practicidad para el usuario, sino cada uno debería configurar su navegador para tal caso y sería "molesto" para los usuarios menos informados del tema.

 

Saludos. Nicolás Colanero.-

[Nicolás Sebastían Colanero]

Bajo el enfoque que se menciona, haciendo un sniffing encontré esto cuando se hace el GET para vatsim.net en este orden:

 

1 - malformed = [Dissector bug, protocol HTTP: "Request URI" - "http.request.uri" invalid length: -5 (proto.c:2104)]

 

2 - malformed = [Dissector bug, protocol HTTP: "Request Version" - "http.request.version" invalid length: -22 (proto.c:2104)]

 

3 - malformed = [Dissector bug, protocol HTTP: "Request URI" - "http.request.uri" invalid length: -5 (proto.c:2104)]

 

Espero tal vez ayude al programador.

[Renzo Llamosas 978403]

Hola a todos les escribo desde Peru y que suerte que haya encontrado el problema que tengo en este foro,pues mi problema es el mismo que uds detallan con el mismo mensaje de error pero para ser sincero tengo un buen tiempo en vatsim como piloto y hace poco me anime a ser controlador entonces el programa vrc es totalmente nuevo y ademas creo yo que no estoy al nivel informatico en el cual uds hablan almenos yo entiendo como si hablaran en chino y les pido disculpas por eso, aqui uso itp telefonica y tambien sospeche que era mi cortafuegos ya que uso el antivirus panda, pero lo he bloqueado momentaneamente y el problema persiste y ya no se que hacer con este problema, solo el vrc ah podido conect[Mod - Happy Thoughts] con los servidores en dos ocasiones pues he intentado otros dias y no se puede.

 

Eugenio te pediria si fueras tan amable como solucionar directamente el problema se que dominas este tema pero la verdad no me encuentro a tu nivel por eso te pido que lo detalles un poco mas.

les agradesco su pronta respuesta muchas gracias.

 

saludos,renzo llamosas consiglieri