Fwd: [LUGAr-gral] Problemas de conexión con Speedy
Esto parece funcionar, al menos mejorar la navegación. Lo estoy probando, voy a ver si a la larga mejora realmente. ---------- Forwarded message ---------- From: Roby Sottini <[email protected]> ¡Hola! Hace un par de semanas está ocurriendo un problema de conexión con Speedy. Sucede que algunas veces no pueden resolverse las direcciones y aparece la pantalla de "Error de conexión... Try again". Con el siguiente comando se reducen bastante estos cortes: iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state ESTABLISHED --source-port 80 -j DROP Por lo que me han comentado, Telefónica está cambiando un software de QoS (Quality of Service) por uno de Microsoft y prioriza los dispositivos con Windows. -- Pablo Manuel Rizzo ------------------------------- http://pablorizzo.com -------------------------------
On Monday 18 October 2010 14:39:15 Pablo Manuel Rizzo wrote:
Esto parece funcionar, al menos mejorar la navegación. Lo estoy probando, voy a ver si a la larga mejora realmente.
---------- Forwarded message ---------- From: Roby Sottini <[email protected]>
¡Hola!
Hace un par de semanas está ocurriendo un problema de conexión con Speedy. Sucede que algunas veces no pueden resolverse las direcciones y aparece la pantalla de "Error de conexión... Try again".
Con el siguiente comando se reducen bastante estos cortes:
iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state ESTABLISHED --source-port 80 -j DROP
aja ¿pero qué hace ese comando exactamente? o sea ¿qué modificación nueva introduce en tu conexión?
Por lo que me han comentado, Telefónica está cambiando un software de QoS (Quality of Service) por uno de Microsoft y prioriza los dispositivos con Windows.
-- Marcos Guglielmetti ▲ :::::::::::::::::: M U S I X ::::::::::::::::::::: ▼ www.musix.org.ar www.ovejafm.com _______________________________________________ Para encontrarte con activistas del movimiento social del software libre envia un mail a [email protected] y luego respondé el mail de bienvenida. PD: usen dukgo.com en vez de google es genial y va camino a ser totalmente libre ¡y no te espía! :-D ¿Cuáles serían las libertades esenciales en Medios de Comunicación Libres? listas, sitios, etc. 0) La libertad de usar los medios de comunicación con cualquier propósito (uso) 1) La libertad de auditar los medios de comunicación y adaptarlos a tus necesidades. El acceso a los paneles de administración es una condición previa para esto. (estudio) 2) La libertad de crear otros usuarios y medios de comunicación, con lo que puedes ayudar a tu prójimo. (copia) 3) La libertad de modificar en los medios de comunicación y hacer públicas las mejoras a los demás, de modo que toda la comunidad se beneficie. El acceso al panel de administración es un requisito previo para esto. (mejora)
Con el siguiente comando se reducen bastante estos cortes:
iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state ESTABLISHED --source-port 80 -j DROP
aja
¿pero qué hace ese comando exactamente?
o sea ¿qué modificación nueva introduce en tu conexión?
Por lo que me han comentado, Telefónica está cambiando un software de QoS (Quality of Service) por uno de Microsoft y prioriza los dispositivos con Windows.
como sabe que son dispositivos windows? -- Diego Saravia [email protected] NO FUNCIONA->[email protected]
2010/10/18 Diego Saravia <[email protected]>:
Con el siguiente comando se reducen bastante estos cortes:
iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state ESTABLISHED --source-port 80 -j DROP
aja
¿pero qué hace ese comando exactamente?
o sea ¿qué modificación nueva introduce en tu conexión?
Por lo que me han comentado, Telefónica está cambiando un software de QoS (Quality of Service) por uno de Microsoft y prioriza los dispositivos con Windows.
como sabe que son dispositivos windows?
hmmm... mas que saber, debe estar más probado con los parametros de tcp/ip que usa windows por defecto, y no tanto con los que usa gnulinux. Esa instrucción creo que iptables -A INPUT // para los paqutes entrantes -p tcp // del protocolo tcp (no udp) --tcp-flags RST RST // marcados con estos flags (que los desconosco, supongo estarán por ahí documentados) -m state --state ESTABLISHED // que correspondan a conexiones previamente establecidas (no nuevas ni cerrandose etc) --source-port 80 // que provengan del puerto http de la maquina remota -j DROP // eliminarlos inmediatamente Y supongo que al ser eliminados y no llegar la información esa para la conexión establecida, se intentará retrasmitir el paqute, y cuando venga sin el flag RST RST pasará bien. Bueno, no recuerdo de memoria los parametros de iptables, muy acostumbrado a usar herramientas graficas como fwbuilder o webmin, si alguien sabe más, por favor corrija. -- Pablo Manuel Rizzo ------------------------------- http://pablorizzo.com -------------------------------
El 18/10/10 10:50, Pablo Manuel Rizzo dijo:
2010/10/18 Diego Saravia <[email protected]>:
Con el siguiente comando se reducen bastante estos cortes:
iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state ESTABLISHED --source-port 80 -j DROP
aja
¿pero qué hace ese comando exactamente?
o sea ¿qué modificación nueva introduce en tu conexión?
Por lo que me han comentado, Telefónica está cambiando un software de QoS (Quality of Service) por uno de Microsoft y prioriza los dispositivos con Windows.
como sabe que son dispositivos windows?
hmmm... mas que saber, debe estar más probado con los parametros de tcp/ip que usa windows por defecto, y no tanto con los que usa gnulinux.
Esa instrucción creo que
iptables -A INPUT // para los paqutes entrantes
-p tcp // del protocolo tcp (no udp)
--tcp-flags RST RST // marcados con estos flags (que los desconosco, supongo estarán por ahí documentados)
-m state --state ESTABLISHED // que correspondan a conexiones previamente establecidas (no nuevas ni cerrandose etc)
--source-port 80 // que provengan del puerto http de la maquina remota
-j DROP // eliminarlos inmediatamente
Y supongo que al ser eliminados y no llegar la información esa para la conexión establecida, se intentará retrasmitir el paqute, y cuando venga sin el flag RST RST pasará bien.
Bueno, no recuerdo de memoria los parametros de iptables, muy acostumbrado a usar herramientas graficas como fwbuilder o webmin, si alguien sabe más, por favor corrija.
Creo que es la misma que recomendaban para evitar el bloqueo de P2P que hacía Comcast, puede ser? El tema es que vos pedías conectarte a un par y el sistema de ellos te reconocía el tipo de paquete y te respondía con un RST (reset?). Entonces configurabas tu firewall para que no los acepte y listo :P -- Salud! Nicolás Reynolds, xmpp:[email protected] omb:http://identi.ca/fauno blog:http://selfdandi.com.ar/ gnu/linux user #455044 http://librecultivo.org.ar http://parabolagnulinux.org
2010/10/18 Nicolás Reynolds <[email protected]>
El 18/10/10 10:50, Pablo Manuel Rizzo dijo:
2010/10/18 Diego Saravia <[email protected]>:
Con el siguiente comando se reducen bastante estos cortes:
iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state ESTABLISHED --source-port 80 -j DROP
aja
¿pero qué hace ese comando exactamente?
o sea ¿qué modificación nueva introduce en tu conexión?
Por lo que me han comentado, Telefónica está cambiando un software de QoS (Quality of Service) por uno de Microsoft y prioriza los dispositivos con Windows.
como sabe que son dispositivos windows?
hmmm... mas que saber, debe estar más probado con los parametros de tcp/ip que usa windows por defecto, y no tanto con los que usa gnulinux.
Esa instrucción creo que
iptables -A INPUT // para los paqutes entrantes
-p tcp // del protocolo tcp (no udp)
--tcp-flags RST RST // marcados con estos flags (que los desconosco, supongo estarán por ahí documentados)
-m state --state ESTABLISHED // que correspondan a conexiones previamente establecidas (no nuevas ni cerrandose etc)
--source-port 80 // que provengan del puerto http de la maquina remota
-j DROP // eliminarlos inmediatamente
Y supongo que al ser eliminados y no llegar la información esa para la conexión establecida, se intentará retrasmitir el paqute, y cuando venga sin el flag RST RST pasará bien.
Bueno, no recuerdo de memoria los parametros de iptables, muy acostumbrado a usar herramientas graficas como fwbuilder o webmin, si alguien sabe más, por favor corrija.
Creo que es la misma que recomendaban para evitar el bloqueo de P2P que hacía Comcast, puede ser? El tema es que vos pedías conectarte a un par y el sistema de ellos te reconocía el tipo de paquete y te respondía con un RST (reset?).
Entonces configurabas tu firewall para que no los acepte y listo :P
Ahí uno decía esto en otra lista: "Los que analizaron un poco las conexiones, comprobaron que cuando el proxy transparente empieza a fallar (¿cuando está sobrecargado?) responde al SYN con RST (reset) en lugar de un SYN,ACK. ¿Porqué no pasa esto con Windows? Un verdadero misterio, y no creo en conspiraciones: calculo que por casualidad tienen implementado algo distinto en su stack TCP/IP que hace menos evidente el problema, porque un poco les pasa, pero muy poco." Yo tengo todas mis maquinas conectadas a un openvpn en un datacenter, ahora puse allí un squid y estoy navegando por allí, como va todo por vpn es a penas un poquito mas lento pero casi ni se nota y anda bien. -- Pablo Manuel Rizzo ------------------------------- http://pablorizzo.com -------------------------------
Hay una versión mejorada de esas reglas: iptables -A OUTPUT -p tcp --dport 80 -m state --state NEW -m recent --set --name thor --rdest -j ACCEPT iptables -A INPUT -p tcp -m tcp --tcp-flag RST RST -m state --state ESTABLISHED -m recent --name thor --rcheck --rsource --seconds 1 -j DROP El problema con el proxy de $peedy es que contesta con un RST en forma inmediata al SYN. Sospecho que por saturación. Leí, aunque no entiendo aun el porqué, que debido a que hay conexiones que necesitan cerrarse con un RST, no se pueden dropear todos los RST recibidos, sino que se puede considerar que cualquier RST que vuelva a un intento de conexión antes de que pase un segundo puede interpretarse como una "falla" del proxy. Con estas dos reglas se identifican los paquetes salientes y si la respuesta es un RST que llega antes de 1 segundo se dropea y se deja que el propio TCP se ocupe de reintentar. Saludos Javier Un post que hice al respecto: http://blog.salinas.com.ar/2010/10/07/telefonica-y-el-proxy-de-los-misterios... El 18/10/10 22:17, Pablo Manuel Rizzo escribió:
2010/10/18 Nicolás Reynolds <[email protected] <mailto:[email protected]>>
El 18/10/10 10:50, Pablo Manuel Rizzo dijo: > 2010/10/18 Diego Saravia <[email protected] <mailto:[email protected]>>: > >>> Con el siguiente comando se reducen bastante estos cortes: > >>> > >>> iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state ESTABLISHED > >>> --source-port 80 -j DROP > >>> > >> > >> aja > >> > >> ¿pero qué hace ese comando exactamente? > >> > >> o sea ¿qué modificación nueva introduce en tu conexión? > >> > >>> Por lo que me han comentado, Telefónica está cambiando un software de QoS > >>> (Quality of Service) por uno de Microsoft y prioriza los dispositivos con > >>> Windows. > >> > > > > > > como sabe que son dispositivos windows? > > hmmm... mas que saber, debe estar más probado con los parametros de > tcp/ip que usa windows por defecto, y no tanto con los que usa > gnulinux. > > > Esa instrucción creo que > > iptables -A INPUT // para los paqutes entrantes > > -p tcp // del protocolo tcp (no udp) > > --tcp-flags RST RST // marcados con estos flags (que los desconosco, > supongo estarán por ahí documentados) > > -m state --state ESTABLISHED // que correspondan a conexiones > previamente establecidas (no nuevas ni cerrandose etc) > > --source-port 80 // que provengan del puerto http de la maquina remota > > -j DROP // eliminarlos inmediatamente > > > Y supongo que al ser eliminados y no llegar la información esa para la > conexión establecida, se intentará retrasmitir el paqute, y cuando > venga sin el flag RST RST pasará bien. > > Bueno, no recuerdo de memoria los parametros de iptables, muy > acostumbrado a usar herramientas graficas como fwbuilder o webmin, si > alguien sabe más, por favor corrija.
Creo que es la misma que recomendaban para evitar el bloqueo de P2P que hacía Comcast, puede ser? El tema es que vos pedías conectarte a un par y el sistema de ellos te reconocía el tipo de paquete y te respondía con un RST (reset?).
Entonces configurabas tu firewall para que no los acepte y listo :P
Ahí uno decía esto en otra lista:
"Los que analizaron un poco las conexiones, comprobaron que cuando el proxy transparente empieza a fallar (¿cuando está sobrecargado?) responde al SYN con RST (reset) en lugar de un SYN,ACK. ¿Porqué no pasa esto con Windows? Un verdadero misterio, y no creo en conspiraciones: calculo que por casualidad tienen implementado algo distinto en su stack TCP/IP que hace menos evidente el problema, porque un poco les pasa, pero muy poco."
Yo tengo todas mis maquinas conectadas a un openvpn en un datacenter, ahora puse allí un squid y estoy navegando por allí, como va todo por vpn es a penas un poquito mas lento pero casi ni se nota y anda bien.
-- Pablo Manuel Rizzo ------------------------------- http://pablorizzo.com -------------------------------
________________________________________________
Solar-General es una lista abierta a toda la comunidad, sin ninguna moderación, por lo que se apela a la tolerancia y al respeto mutuo. Las opiniones expresadas son responsabilidad exclusiva de sus respectivos/as autores/as. La Asociación Solar no se hace responsable por los mensajes vertidos, ni representan necesariamente el punto de vista de la Asociación Solar.
[email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/solar-general
El 19/10/10 12:33, Javier Salinas dijo:
Hay una versión mejorada de esas reglas:
iptables -A OUTPUT -p tcp --dport 80 -m state --state NEW -m recent --set --name thor --rdest -j ACCEPT
iptables -A INPUT -p tcp -m tcp --tcp-flag RST RST -m state --state ESTABLISHED -m recent --name thor --rcheck --rsource --seconds 1 -j DROP
El problema con el proxy de $peedy es que contesta con un RST en forma inmediata al SYN. Sospecho que por saturación. Leí, aunque no entiendo aun el porqué, que debido a que hay conexiones que necesitan cerrarse con un RST, no se pueden dropear todos los RST recibidos, sino que se puede considerar que cualquier RST que vuelva a un intento de conexión antes de que pase un segundo puede interpretarse como una "falla" del proxy.
Con estas dos reglas se identifican los paquetes salientes y si la respuesta es un RST que llega antes de 1 segundo se dropea y se deja que el propio TCP se ocupe de reintentar.
Saludos
Javier
Un post que hice al respecto: http://blog.salinas.com.ar/2010/10/07/telefonica-y-el-proxy-de-los-misterios...
El 18/10/10 22:17, Pablo Manuel Rizzo escribió:
2010/10/18 Nicolás Reynolds <[email protected] <mailto:[email protected]>>
El 18/10/10 10:50, Pablo Manuel Rizzo dijo: > 2010/10/18 Diego Saravia <[email protected] <mailto:[email protected]>>: > >>> Con el siguiente comando se reducen bastante estos cortes: > >>> > >>> iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state ESTABLISHED > >>> --source-port 80 -j DROP > >>> > >> > >> aja > >> > >> ¿pero qué hace ese comando exactamente? > >> > >> o sea ¿qué modificación nueva introduce en tu conexión? > >> > >>> Por lo que me han comentado, Telefónica está cambiando un software de QoS > >>> (Quality of Service) por uno de Microsoft y prioriza los dispositivos con > >>> Windows. > >> > > > > > > como sabe que son dispositivos windows? > > hmmm... mas que saber, debe estar más probado con los parametros de > tcp/ip que usa windows por defecto, y no tanto con los que usa > gnulinux. > > > Esa instrucción creo que > > iptables -A INPUT // para los paqutes entrantes > > -p tcp // del protocolo tcp (no udp) > > --tcp-flags RST RST // marcados con estos flags (que los desconosco, > supongo estarán por ahí documentados) > > -m state --state ESTABLISHED // que correspondan a conexiones > previamente establecidas (no nuevas ni cerrandose etc) > > --source-port 80 // que provengan del puerto http de la maquina remota > > -j DROP // eliminarlos inmediatamente > > > Y supongo que al ser eliminados y no llegar la información esa para la > conexión establecida, se intentará retrasmitir el paqute, y cuando > venga sin el flag RST RST pasará bien. > > Bueno, no recuerdo de memoria los parametros de iptables, muy > acostumbrado a usar herramientas graficas como fwbuilder o webmin, si > alguien sabe más, por favor corrija.
Creo que es la misma que recomendaban para evitar el bloqueo de P2P que hacía Comcast, puede ser? El tema es que vos pedías conectarte a un par y el sistema de ellos te reconocía el tipo de paquete y te respondía con un RST (reset?).
Entonces configurabas tu firewall para que no los acepte y listo :P
Ahí uno decía esto en otra lista:
"Los que analizaron un poco las conexiones, comprobaron que cuando el proxy transparente empieza a fallar (¿cuando está sobrecargado?) responde al SYN con RST (reset) en lugar de un SYN,ACK. ¿Porqué no pasa esto con Windows? Un verdadero misterio, y no creo en conspiraciones: calculo que por casualidad tienen implementado algo distinto en su stack TCP/IP que hace menos evidente el problema, porque un poco les pasa, pero muy poco."
Yo tengo todas mis maquinas conectadas a un openvpn en un datacenter, ahora puse allí un squid y estoy navegando por allí, como va todo por vpn es a penas un poquito mas lento pero casi ni se nota y anda bien.
che o sea que estamos contribuyendo a que ese proxy se prenda fuego? :P -- Salud! Nicolás Reynolds, xmpp:[email protected] omb:http://identi.ca/fauno blog:http://selfdandi.com.ar/ gnu/linux user #455044 http://librecultivo.org.ar http://parabolagnulinux.org
El 19/10/10 08:45, Nicolás Reynolds escribió:
El 19/10/10 12:33, Javier Salinas dijo:
Hay una versión mejorada de esas reglas:
iptables -A OUTPUT -p tcp --dport 80 -m state --state NEW -m recent --set --name thor --rdest -j ACCEPT
iptables -A INPUT -p tcp -m tcp --tcp-flag RST RST -m state --state ESTABLISHED -m recent --name thor --rcheck --rsource --seconds 1 -j DROP
El problema con el proxy de $peedy es que contesta con un RST en forma inmediata al SYN. Sospecho que por saturación. Leí, aunque no entiendo aun el porqué, que debido a que hay conexiones que necesitan cerrarse con un RST, no se pueden dropear todos los RST recibidos, sino que se puede considerar que cualquier RST que vuelva a un intento de conexión antes de que pase un segundo puede interpretarse como una "falla" del proxy.
Con estas dos reglas se identifican los paquetes salientes y si la respuesta es un RST que llega antes de 1 segundo se dropea y se deja que el propio TCP se ocupe de reintentar.
Saludos
Javier
Un post que hice al respecto: http://blog.salinas.com.ar/2010/10/07/telefonica-y-el-proxy-de-los-misterios...
El 18/10/10 22:17, Pablo Manuel Rizzo escribió:
2010/10/18 Nicolás Reynolds <[email protected] <mailto:[email protected]>>
El 18/10/10 10:50, Pablo Manuel Rizzo dijo: > 2010/10/18 Diego Saravia <[email protected] <mailto:[email protected]>>: > >>> Con el siguiente comando se reducen bastante estos cortes: > >>> > >>> iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state ESTABLISHED > >>> --source-port 80 -j DROP > >>> > >> > >> aja > >> > >> ¿pero qué hace ese comando exactamente? > >> > >> o sea ¿qué modificación nueva introduce en tu conexión? > >> > >>> Por lo que me han comentado, Telefónica está cambiando un software de QoS > >>> (Quality of Service) por uno de Microsoft y prioriza los dispositivos con > >>> Windows. > >> > > > > > > como sabe que son dispositivos windows? > > hmmm... mas que saber, debe estar más probado con los parametros de > tcp/ip que usa windows por defecto, y no tanto con los que usa > gnulinux. > > > Esa instrucción creo que > > iptables -A INPUT // para los paqutes entrantes > > -p tcp // del protocolo tcp (no udp) > > --tcp-flags RST RST // marcados con estos flags (que los desconosco, > supongo estarán por ahí documentados) > > -m state --state ESTABLISHED // que correspondan a conexiones > previamente establecidas (no nuevas ni cerrandose etc) > > --source-port 80 // que provengan del puerto http de la maquina remota > > -j DROP // eliminarlos inmediatamente > > > Y supongo que al ser eliminados y no llegar la información esa para la > conexión establecida, se intentará retrasmitir el paqute, y cuando > venga sin el flag RST RST pasará bien. > > Bueno, no recuerdo de memoria los parametros de iptables, muy > acostumbrado a usar herramientas graficas como fwbuilder o webmin, si > alguien sabe más, por favor corrija.
Creo que es la misma que recomendaban para evitar el bloqueo de P2P que hacía Comcast, puede ser? El tema es que vos pedías conectarte a un par y el sistema de ellos te reconocía el tipo de paquete y te respondía con un RST (reset?).
Entonces configurabas tu firewall para que no los acepte y listo :P
Ahí uno decía esto en otra lista:
"Los que analizaron un poco las conexiones, comprobaron que cuando el proxy transparente empieza a fallar (¿cuando está sobrecargado?) responde al SYN con RST (reset) en lugar de un SYN,ACK. ¿Porqué no pasa esto con Windows? Un verdadero misterio, y no creo en conspiraciones: calculo que por casualidad tienen implementado algo distinto en su stack TCP/IP que hace menos evidente el problema, porque un poco les pasa, pero muy poco."
Yo tengo todas mis maquinas conectadas a un openvpn en un datacenter, ahora puse allí un squid y estoy navegando por allí, como va todo por vpn es a penas un poquito mas lento pero casi ni se nota y anda bien.
che o sea que estamos contribuyendo a que ese proxy se prenda fuego? :P
Y, podría decirse que si, ya que si responde con RST por saturación, el reintento es mucho mas rápido que si el usuario tiene que hacer F5 para recargar. Saludos Javier
________________________________________________
Solar-General es una lista abierta a toda la comunidad, sin ninguna moderación, por lo que se apela a la tolerancia y al respeto mutuo. Las opiniones expresadas son responsabilidad exclusiva de sus respectivos/as autores/as. La Asociación Solar no se hace responsable por los mensajes vertidos, ni representan necesariamente el punto de vista de la Asociación Solar.
[email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/solar-general
--- El mar, 10/19/10, Nicolás Reynolds escribió:
che o sea que estamos contribuyendo a que ese proxy se prenda fuego? :P
Si leyeran un poco acerca de las polìticas de Comcast y Telefónica estarían enterados de que ambas empresas decidieron abandonar la neutralidad de la red, por que dice que ellos pagan la infraestructura y otros hacen negocios a través de esa infraestructura sin pagar un centavo. Y para darle mayor prioridad a otros por los que sì cobran mediante convenios recíprocos. Y prepárense para los efectos técnicos de #ACTA. http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=c... http://bandaancha.eu/articulo/7466/telefonica-pone-limites-descarga-adsl-rei... http://ciberderechos.barrapunto.com/article.pl?sid=10/09/10/1024233 http://ciberderechos.barrapunto.com/article.pl?sid=10/09/10/1024233 http://www.eitb.com/videos/noticias/tecnologia/detalle/349899/alierta-telefo... http://espana.barrapunto.com/article.pl?sid=10/10/12/0134246&from=rss -- Alejandro Rene "El Corrector Empedernido" Fernandez Blanco http://technopolios.blogspot.com/ ¿Conoces algún sitio del gobierno de tu País que no respete los Estándares Web? Reportalo con sus datos (País, Estado / Provincia, Ciudad, Organismo y de quién depende), en http://technopolios.blogspot.com/2008/08/sitios-web-gubernamentales-y-estnda...
El 19/10/10 04:28, Alejandro Fernández Blanco dijo:
--- El mar, 10/19/10, Nicolás Reynolds escribió:
che o sea que estamos contribuyendo a que ese proxy se prenda fuego? :P
Si leyeran un poco acerca de las polìticas de Comcast y Telefónica estarían enterados de que ambas empresas decidieron abandonar la neutralidad de la red, por que dice que ellos pagan la infraestructura y otros hacen negocios a través de esa infraestructura sin pagar un centavo. Y para darle mayor prioridad a otros por los que sì cobran mediante convenios recíprocos. Y prepárense para los efectos técnicos de #ACTA.
http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=c...
http://bandaancha.eu/articulo/7466/telefonica-pone-limites-descarga-adsl-rei...
http://ciberderechos.barrapunto.com/article.pl?sid=10/09/10/1024233
http://ciberderechos.barrapunto.com/article.pl?sid=10/09/10/1024233
http://www.eitb.com/videos/noticias/tecnologia/detalle/349899/alierta-telefo...
http://espana.barrapunto.com/article.pl?sid=10/10/12/0134246&from=rss
hace un par de meses lo comentábamos -- Salud! Nicolás Reynolds, xmpp:[email protected] omb:http://identi.ca/fauno blog:http://selfdandi.com.ar/ gnu/linux user #455044 http://librecultivo.org.ar http://parabolagnulinux.org
participants (6)
-
Alejandro Fernández Blanco -
Diego Saravia -
Javier Salinas -
Marcos Germán Guglielmetti -
Nicolás Reynolds -
Pablo Manuel Rizzo