Quería bajar una imagen iso de DVD de Centos 5.1. Sin embargo, noté que la descarga terminaba bastante rápido. Algo extraño estaba pasando, teniendo en cuenta que se trata de un archivo de 4,1 G. Pensé que se trataba de un problema del mirror. Pero luego probando con otros mirrors, e inclusive probando con ISOs de DVD de otras distribuciones, advertí que el problema se repetía.
$ wget http://linux.cucea.udg.mx/espejo/Mandriva/2008.0/mandriva-linux-2008.0-free-dvd-i586.iso –07:49:15– http://linux.cucea.udg.mx/espejo/Mandriva/2008.0/mandriva-linux-2008.0-free-dvd-i586.iso=>`mandriva-linux-2008.0-free-dvd-i586.iso’ Resolving linux.cucea.udg.mx… 148.202.23.6 Connecting to linux.cucea.udg.mx|148.202.23.6|:80… connected. HTTP request sent, awaiting response… 200 OK Length: 269,768,704 (257M) [application/octet-stream
En la lista de correo Centos-mirror, John Lauro me dio una sencilla pero ingeniosa idea: comprobar si el sistema de archivos que estaba utilizando tenía un límite para crear archivos grandes. La primera prueba se puede hacer así:
$ dd if=/dev/zero of=5GB-file bs=1M count=5000
Entonces, obtuve un archivo llamado 5GB-file de 4,9 GB, lo cual era un primer indicio de que el sistema de archivos no era el problema. Tengo un wireless router que se conecta a Internet, que sirve como intermediario para una PC y una notebook. Creí por un momento que el Linksys WRT54G era el problema. Pero no, ya que conectándo la PC directamente al cablemodem tenía el mismo problema. La sospecha entonces comenzaba a apuntar fuertemente en dirección a Fib3rtel.
Luego, hice la siguiente prueba sugerida por John, hacer una descarga de un archivo grande desde un servidor web local. Así que eso hice, inicié Apache (de la PC con Mandriva 2008), puse un archivo de 4,9 GB e intenté bajarlo desde la notebook (con Fedora 8). Este fue el resultado:
$ wget http://192.168.1.2//5GB-file --19:35:19-- http://192.168.1.2//5GB-file=> `5GB-file' Connecting to 192.168.1.2:80... connected. HTTP request sent, awaiting response... 200 OK Length: 5,242,880,000 (4.9G) [text/plain]0% [] 2,078,996 1.10M/s
Este resultado, sumado a las pruebas con tcptraceroute (idea leída del blog de Javier Smaldone) entre información recolectada, dieron el veredicto: No sólo Fib3rtel interpone a sus clientes un proxy transparente, sino que además impone un límite al tamaño de los archivos que se descargan. La pregunta (ingenua) es ¿Por qué la empresa no lo dice?
En lugar de llamar a Fib3rtel, y estar lidiando con la gente apenas capacitada del soporte técnico (y esperar los típicos diálogos del tipo: “Haga doble clic en Mi PC” – “Eh… uso Linux” o “Desconecte y reconecte su modem”, o , etc) encontré una solución al problema: usar Tor + Privoxy, los cuales me permiten esquivar el proxy transparente de Fib3rtel.
Descarga limitada por el proxy transparente de Fib3rtel:
$ wget http://holmes.umflint.edu/centos/5.1/isos/x86_64/CentOS-5.1-x86_64-bin-DVD.iso –13:25:01– http://holmes.umflint.edu/centos/5.1/isos/x86_64/CentOS-5.1-x86_64-bin-DVD.iso => `CentOS-5.1-x86_64-bin-DVD.iso’ Resolving holmes.umflint.edu… 141.216.3.72 Connecting to holmes.umflint.edu|141.216.3.72|:80… connected. HTTP request sent, awaiting response… 200 OK Length: 147,687,424 (141M) [application/octet-stream] $ export http_proxy=127.0.0.1:8118 $ wget http://holmes.umflint.edu/centos/5.1/isos/x86_64/CentOS-5.1-x86_64-bin-DVD.iso –13:25:19– http://holmes.umflint.edu/centos/5.1/isos/x86_64/CentOS-5.1-x86_64-bin-DVD.iso=> `CentOS-5.1-x86_64-bin-DVD.iso.1′ Connecting to 127.0.0.1:8118… connected. Proxy request sent, awaiting response… 200 OK Length: 4,442,654,720 (4.1G) [application/octet-stream]
Hasta la próxima.
