Esto ya es archiconocido en el foro. El año pasado apelé una resolución en la que Claro se hacía el sueco con las restricciones de puertos y limitaciones de tráfico al Bittorrent en su red móvil. Luego, ellos lo admiten y "justifican" sus acciones amparándose en una ley española (si, no es broma) que ni siquiera era aprobada en ese momento, que debía usar una VPN si quería saltearme ese problema (cosa que luego negarían cuando comienzan a sabotear las VPN) y cita especificaciones técnicas o de seguridad que nunca mostraton en el contrato. Para qué lo hicieron. Casi 3 meses después, OSIPTEL emite una resolución fallando a mi favor sobre estas limitaciones, pero no da ni siquiera un llamado de atención a Claro, pese a que esta empresa incumplió descaradamente el reglamento de OSIPTEL. Hoy, un año después, doy un episodio más de esta odisea y Claro lejos de aprender de ello ha tomado una posición más matonesca de la que dio el año pasado. Ya di un adelanto de esta situación aquí (¿Tu navegación segura lo es realmente?) y lo que observé la semana pasada es la generalización de ese problema. Ya no solo es el https, sino todo el protocolo HTTP (con o sin cifrado). Esta es la última prueba Glasnost que logré hacer con éxito, puesto que Claro está trabando el acceso a la prueba. Y efectivamente, en uno de esos intentos logré ver la causa, Claro está restringiendo de una forma brutal los puertos usados por la prueba Glasnost (en este caso, el 8080). http://es.scribd.com/doc/91667533/Clarogate-2-1-un-ano-despues Gráficamente, sería lo que ven en este vídeo. Los primeros cinco minutos muestran justamente el momento en el que la prueba es saboteada (en coincidencia con lo que pueden leer en el reporte), luego de cerrar rápidamente el navegador (como pueden ver, hay tráfico todavía, es un rezago del firefox) y correrla. La prueba se queda congelada hasta el final en el vídeo. Sobre las limitaciones de tráfico, acá se puede notar con más cuidado. Aun sobreexigiendo la línea, la gráfica no levanta. Esto se da al pasar cierto tiempo en Youtube (con o sin cifrado, esto me preocupa) o en ciertos foros como BZ. Y ojo, esta captura fue de madrugada. La semana antepasada mandé un recurso de queja por esta acción (puesto que es el mismo caso del expediente de OSIPTEL), no quiero pensar que esto fue una represalia. Y no sé qué tanto ganan con ponerse matones cuando tienen anticuchos expuestos por la prensa en un lado y estén por revivir este expediente en otro. Eso es lo malo de aislar a la asistencia tecnológica y cubrir las irregularidades de redes con marketing, como si la publicidad de boca en boca no significara nada.
buena información, y pensar que la propaganda de ellos dice otra cosa, le preguntare eso al pata que me llama a cada rato a insistirme me cambie a claro
Un detalle más (Si no lo han visto): La prueba Glasnost ya no la aplico a Bittorrent, sino al HTTP, porque el problema como pudieron ver es en la páginas. Vamos a ver qué respuesta recibo en el CAC, porque se viene una guerra de trincheras XD
Tantos fallos de conexiòn reportados a M-Lab y el mismo instituto que se dieron cuenta de la trampa: Claro està cambiando los puertos usados por la prueba a fin de decir "aquì no pasò nada" (¿Recuerdan el vìdeo de la entrada a interbank?). Esta captura reciente lo confirma (no pude imprimirlo, CUPS tiene problemas en puppy) La prueba sale "OK", pero la advertencia (escrita con un color amarillento en la pàgina) desenmascara todo.
Este será el último post sobre el tema. Tras esto ya puedo mandar a la ****** a OSIPTEL y a Claro. Explico. Este problema ocurrió ayer cuando detecté limitaciones de tráfico mientras veía un vídeo de Youtube en un foro. Observen como va la línea en el administrador de tareas (linea amarilla, descarga), con un curioso tope de 16KBps si ven las cifras. Luego de esto viene lo sospechoso. Cierro la página y corro la prueba Glasnost por unos segundos. Vaya sorpresa cuando la cierro, la línea va "normal" al cargar el vídeo nuevamente (el tope sube a 32). Ese tope inicial (en escalerita, por el poco tiempo del vídeo apenas se nota) lo había visto antes, cuando Claro dio un singular regalo a los planes móviles en Diciembre pasado. Poco después llamé al 123 para advertir sobre esta práctica (prohibida por la resolución N° 040-2005-CD/OSIPTEL http://ow.ly/aPu8V ) Pero esto no sería lo más escandaloso, sino luego de la llamada (pasando las 14:00h), tratando a lo largo de la tarde de subir este vídeo, sin éxito. ¿Represalia? Aquí viene lo más polémico. Tanto Facebook como Google(Youtube) están bajo conexiones cifradas en el vídeo. Pruebo primero subiendo el vídeo anterior a Facebook (observen el ancho de banda en el administrador de tareas, el rojo por deducción representa la carga). Comparenlo con el extraño tope que ponen al ancho de banda para subir ese vídeo en Youtube con cifrado y todo. El año pasado esto ya me había pasado con Scribd y Mediafire (hasta lo comenté en el foro), pero a diferencia de estos casos, se está interfiriendo en una conexión cifrada, algo que supuestamente el proveedor de internet no debería ver. Esto ya es grave, porque se está metiendo mano a una comunicación supuestamente privada. Y eso tiene nombre en el perú, violación de intimidad, cosa que es un delito. Que todavía no se cierre el tópico, queda una cosa más por ver.
Yo tambien voy a ver si hago esta prueba, hace unso dias notaba que los videos de baja calidad de YT no cargaban rapido (linea fija vomistar), a pesar que en speedtest la velo se encontraba normal, aunque talves sea que YT tenga scripts que limiten, aunque no lo creo, bueno hace 2 dias se normalizo la situacion, pero si ocurre de nuevo tendre que testear nomas, saludos
Lo que estaba pendiente de mostrar. Algo que noté ese día fue lo siguiente. Parte de la conexión (particularmente el envío del vídeo a Youtube) estaba sin cifrar, por lo que Claro sabía qué IP estaba recibiendo el vídeo. La comparación corresponde a los últimos paquetes antes que se cortara el envío, se trata del intento anterior al registrado en vídeo (grabé otro como pueden ver, menos mal porque no guardé el .cap que generó el monitor)y para mi sorpresa, los datos enviados a Google (ip 173.194.37.46) no esban encriptados, cosa que si ocurría con la recepción. Esto me recordó mucho el caso de espionaje de Carrier IQ. EDIT: hablando de espionaje... http://www.adslzone.net/article8570...radores-por-vender-datos-de-los-usuarios.html
Pensaba no referirme más al caso, pero esta madrudaga noté el corte a Youtube de la vez pasada en más sitios (sobre todo p0rn0 y algunos de los sitios mencionados). Es decir, cuando se da el capado de tráfico se mantiene así más o menos por 20-30 segundos (a veces hasta por 2 minutos) hasta causar un corte, sea cual fuere el sitio que estuvieran viendo al terminar el capado. ¿Ahora los de Claro quieren hacer de niñera y atacar lo que ellos no quieren que vea? Leyendo un poco sobre los puertos TCP, el 8080 puede llevar un conjunto de reglas que el proveedor configura para manejar el tráfico web. Eso significa que puede ser configurado para restringir el tráfico cada cierto tiempo y al parecer Claro está buscando la forma de que esto parezca "natural", propio de la línea y no de una paranoia por restringir todo (Y de pasada, disimular algún intento de interceptación). Por obvias razones no grabé en vídeo el asunto (era la hora del fap XD), pero ni bien pueda registrar ese fenómeno en páginas "aptas para todo público" lo pongo. Y aquí no termina la sorpresa. Con la prueba Glasnost de hoy (la tomé esta madrugada) noté algo raro. La prueba Glasnost reporta la manipulación al puerto 8080 durante la prueba, pero a diferencia de antes corre tráfico en la prueba, aunque no sin dar cuenta de un error, no da cifras promedio del puerto 40077 en la primera pantalla (en la prueba detallada si sale). Debido a este incidente subo la hoja de resultados y la prueba detallada para que noten las inconsistencias. http://es.scribd.com/doc/94204386/Prueba-Glasnost-20-05-2012 Parece que Claro está empeñándose en maquillar la prueba a como dé lugar. Envié un mensaje de alerta al Instituto Max Planck sobre esto ni bien ocurrió, como ya se dieron cuenta de la pendejada esto será pan comido para ellos. Finalmente, como el 8080 también ha tenido mala fama por ser usado por "troyanos", puede que Claro se excuse en la "seguridad" para justificar esta fechoría. Una seguridad que no existe en su red y que más bien esas restricciones que hace ponen en riesgo a sus clientes. Lo dije en el tema del HTTPS y lo vuelvo a decir. Y muy aparte de eso, esa medida es arbitraria (siempre lo fue), no figura en el contrato (ni siquiera el actual) de internet móvil. Y aun si quisieran hacerlo, OSIPTEL no les dejaría porque ataca directamente a la Resolución Nº 040-2005-CD/OSIPTEL (calidad de servicio). Y según Blawyer, van cuatro años en que los mexicanos están obsesionados por controlar al usuario. EDIT: Para los usuarios de inter fijo de Claro. ¿Pueden intentar hacer la prueba Glasnost y publicar resultados para comparar?
El recurso de queja es un fiasco. La resolución del año pasado era una trampa, OSIPTEL solo acepta la baja del servicio en la resolución anterior, pero en esta resolución actual (infundada), basándose en esa mariconada que hizo ese vocal de no dar ningun llamado de atención a Claro (pese a todo lo que estoy mostrando) hay algo que llama mucho la atención. Y no está mencionado en la resolución anterior. EDIT: http://es.scribd.com/doc/95463788 Lo señalado en negrita es cuestionable, puesto que leyendo la resolución anterior no encuentro nada al respecto. Es más, con esto se demuestra que OSIPTEL no tuvo voluntad de revisar las irregularidades de Claro cuando se dio el expediente. Este organismo va a tener que dar explicaciones al respecto, ¿Por Qué no hizo esto en su momento y por qué recién ahora se acuerdan que no se hizo? Y ahora hay más agravantes con este tema.
Este tema se hace grande con un monólogo que no esperaba seguir. ¿Recuerdan las mediciones de la prueba Glasnost que hice antes? ¿Recuerdan que el puerto 8080 estaba siendo "atacado"? Parece que no es precisamente un ataque. <No me pregunten por el spoiler> Spoiler Hoy recibí una prueba "limpia" (sin advertencias), pero me di una sorpresa que debí darme cuenta antes: el puerto 8080 ni es tocado, Claro hace un cambiazo a quienes piden ese puerto y lo redireccionan a otro. En realidad, el mismo instituto Max Planck lo advirtió en una captura previa. Aunque me preocupa que ya estén logrando su objetivo, la farsa es fácil de mostrar con el MS Network Monitor. Como la prueba Glasnost está basada en Java, se me dio por examinar bien los paquetes que viajaban por ahí. Aunque Firefox todavía apunta al puerto 80 (en estas capturas), Java mira hacia otro puerto, el 19981, lo mismo que advirtió el instituto Max Planck. Como referencia uso el tráfico de salida (como pueden ver, el tráfico de mi PC sale por los puertos 1215-1216), el que salía como atacado en las pruebas exitosas. ¿Qué ganan con esto? Ni idea. Esta prueba la hice con el módem de un familiar, ya que el mío está sin pagar de momento (por eso no me van tan jodido como antes). En prepago he notado el mismo fenómeno, usando mi módem y comparándolo con otro, así que no es un tema personal como pensaba. Luego corro el vídeo del caso para que se entienda mejor.
Muestra gráfica del asunto. https://www.youtube.com/watch?v=jAXbKw1Y7Wg Hasta que al fin me queda claro cómo Claro gestiona los puertos TCP, muchas veces los redirecciona a otros puertos (el motivo no lo sé, pero no creo que solo sea una represalia), cosa que también vi con el 443 en su momento o el 3074 (XBOX Live). El problema con esto es obvio, ralentiza el servicio (en algunos juegos se sienten como flashbacks, te mueves y te regresan), además que esta forma de envenenar el tráfico (no se distancia mucho del trabajo de Pirate Pay) causa confusión y desconexiones (de ahí que la prueba Glasnost fallaba). Anteriormente lo había visto pero al fin comprendo qué tan importante era esto para el caso.
Después de tiempo pude hacer esta prueba pendiente. Miren cómo anda la prueba Glasnost bajo el internet móvil de Claro (sin adornos) y mediante la VPN Spotflux (antes RaptorVPN). Esto muestra que Claro ha puesto esos cambiazos de puertos a propósito para joder la prueba (y con Spotflux me pasé por los eggs esa restricción). http://youtu.be/velV9572eZM Para variar, fui víctima de las restricciones de tráfico mientras subía el vídeo. http://imageshack.us/photo/my-images/268/sabotaje1.png/ http://imageshack.us/photo/my-images/696/sabotaje2.png/
... y también después de tiempo, al fin logro completar una prueba Glasnost. Parece que los pendeivis bloqueaban la carga/descarga del archivo Glasnostreplayer.jar encargado de hacer las mediciones (ver último vídeo, como se recuerda la prueba Glasnost está basada en Java). Y tras esto la cosa se volvió demasiado rochosa. La prueba de hoy. http://es.scribd.com/doc/99723232
Hoy recibí la prueba Glasnost en cifras verdes, aparentemente sin el cambiazo de puertos (el 8080 iba limpio). Sin embargo, noté un tope bastante extraño en la prueba de FlashVideo (la que busca inconsistencias en el streaming). He aquí las capturas, la gráfica roja corresponde a subida y miren dónde se estanca. Pero parece que el encanto duró poco, tratando de correr la prueba una vez más por si acaso la bloquearon nuevamente, siendo más o menos las 13:40. Y esa prueba de subida luce bastante sospechosa. ¿Están experimentando de nuevo? ¿Habrá influido el puteo que di a Asistencia Tecnológica ayer?
