Re: [OT] Instalar debian en un movil
El Tue, 12 May 2015 19:53:28 -0300, Lacho escribió: Encontré un viejo móvil (motorola milestone 2) en casa que pensé que había perdido y tengo ganas de instalarle debian si es posible. Alguien ha hecho esta practica alguna vez? Pues parece que sí: https://www.google.es/search?q=Motorola+MILESTONE+2ie=utf-8oe=utf-8gws_rd=crei=vVBTVdiEBsOuUYWjgaAB#q=Motorola+MILESTONE+2+debian Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.05.13.13.26...@gmail.com
Shorewall
En la reorganización que estoy acometiendo en mi servidores (a proxmox) uno de los contenedores en el que estoy instalando el gateway de la institución no me permite instalar shorewall y me indica el siguiente error May 13 14:17:07 Processing /etc/shorewall/params ... May 13 14:17:07 Processing /etc/shorewall/shorewall.conf... May 13 14:17:07ERROR: Your kernel/iptables do not include state match support. No version of Shorewall will run on this system no cuento con acceso a internet puro solo algunos accesos que me permite mi isp aparte que con el shorewall gestiono el pop3 y smtp de isp This message was sent using IMP, the Internet Messaging Program. -- Este mensaje le ha llegado mediante el servicio de correo electronico que ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema Nacional de Salud. La persona que envia este correo asume el compromiso de usar el servicio a tales fines y cumplir con las regulaciones establecidas Infomed: http://www.sld.cu/ -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513084112.887472vyiwhd4...@webmail.sld.cu
Re: Instalacion de Jessi
El Tue, 12 May 2015 20:01:34 +, Romero, Fernando escribió: (arrg, ese html...) Hola buenas tardes, subí un manual con los pasos y las pantallas de instalación a YouTube. El que quiera puede suscribirse al canal, hay varios manuales más y todas las semanas voy a seguir subiendo, si quieren me envían un mail y les paso el que necesiten en pdf. Les dejo el link. https://youtu.be/ZoV5H9Yo7p8 Gracias, pero si corriges el nombre de la versión de Debian, mejor (Jessie) ;-) Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.05.13.13.08...@gmail.com
Re: [OT] ¿Cambian los ISP el ToS?
El Tue, 12 May 2015 22:43:52 +0200, José Miguel (sio2) escribió: Un saludo a la lista: ¿Sabe alguno algo al respecto? Si te refieres a priorizar algún tipo de tráfico, yo te diría que no, salvo lo que contratas sobre el papel (cuando hay TV de por medio). Tengo un par de pequeños servidores con conexión con Telefónica (de España) y he comprobado que el tráfico SSH interactivo sale de cliente y servidor con el byte a 0x10, pero llega al destino con el byte a 0x0. Así que, o es cosa del camino o de mis router, pero a estos router no les he configurado nada en especial y me pasa entre los dos servidores entre sí, entre los servidores y mi casa y entre los servidores y un VPN virtual baratujo con IP compartida que tengo contratado para hacer pruebecillas. Muchos routers cambiando ToS me parece a mí. He dejado una pregunta en los foros de Telefónica (en el que suelen responder trabajadores de la propia compañía), pero no he obtenido respuesta. Estoy cacharreando con el QoS y si me cambian el ToS me es imposible distinguir entre la sesión de ssh y el scp, por ejemplo. Ni idea... no he tenido ningún problema con Movistar ni con ninguno de los routers que suministra ni cuando usaba rfc 1483 ni cuando nos han pasado a los direccionamientos pseudo-estáticos. En cuanto al cambio que notas, yo buscaría una posible causa por otro lado: https://www.google.es/webhp?q=ssh+tos+changes Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.05.13.13.18...@gmail.com
[OT-Proxmox] Re: Shorewall
El Wed, 13 May 2015 08:41:12 -0400, alfredop escribió: En la reorganización que estoy acometiendo en mi servidores (a proxmox) uno de los contenedores en el que estoy instalando el gateway de la institución no me permite instalar shorewall y me indica el siguiente error May 13 14:17:07 Processing /etc/shorewall/params ... May 13 14:17:07 Processing /etc/shorewall/shorewall.conf... May 13 14:17:07ERROR: Your kernel/iptables do not include state match support. No version of Shorewall will run on this system no cuento con acceso a internet puro solo algunos accesos que me permite mi isp aparte que con el shorewall gestiono el pop3 y smtp de isp Esto es lo que dicen en Google: *** http://forum.proxmox.com/threads/1936-Shorewall-on-OpenVZ-containers Default Shorewall on OpenVZ containers Hi. I need to install Shorewall on a OpenVZ virtual machine running on Proxmox, but I receive this error: ERROR: Your kernel/iptables do not include state match support. No version of Shorewall will run on this system How I can enable the support on the kernel to let me use Shorewall without problems? Thank you very much! Bye. *** you have to add in /etc/vz/vz.conf in the IPTABLES variables (at very end of the vz.conf) ipt_state *** Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.05.13.13.33...@gmail.com
Re: CORTE de conexión red al ingresar a Facebook (CASO RARO)
El Tue, 12 May 2015 14:37:56 -0700, Eduardo Gil escribió: El mar 12-may-15, Camaleón noela...@gmail.com escribió: (...) Si no haces las pruebas que te pedimos no vamos a avanzar ;-( Los adjetivos como eficiente o raro no sirven de mucho para diagnosticar un problema. Saludos, -- Camaleón Gracias por contestar. ¿Qué pruebas quiere que haga? (...) Cuando notes que has perdido la conectividad, desde una terminal ejecuta los siguientes comandos y manda el resultado: - ping 192.168.0.1 (donde 192.168.01 es la IP del router) - ping -c5 8.8.8.8 - host google.es - dig facebook.com - ip ro - /sbin/ifconfig -a - wget www.google.es - cat /etc/resolv.conf Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.05.13.13.23...@gmail.com
Re: Fwd: En una PC se apaga/suspende/hiberna; pero... [SE SOLUCIONO!]
El Tue, 12 May 2015 18:46:44 -0430, Miguel Matos escribió: Vale, muchas gracias por su apoyo. ¿Cómo es eso de que 'alt' lo muestra? ¡Lo tenían bien guardado! Es más viejo que la panela :-) *** https://wiki.gnome.org/Projects/GnomeShell/CheatSheet#On_the_desktop The Power Off... menu entry is hidden by default. You can make it visible by pressing the Alt key in the user menu. *** Y respecto a las extensiones, les no las habías visto, y eso que me instalé muchas. Mi barra superior está full No todas las extensiones son visibles ni ocupan espacio. Algunas sólo restauran funcionalidades sencillas que simplemente se han ido. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.05.13.13.30...@gmail.com
Publicá en suplemento Casa Nueva, de la casa que tenés a la casa que querés
Suplemento Clarn Casa Nueva, de la casa que tens a la casa que quers. Durante el prximo 6 de Junio,saldr por primera vezel suplemento especial de Diario Clarn,Casa Nueva ,Dela Casaque tens ala Casaque quers . Ser un suplemento mensual que saldr en da sbado, con una salida aproximada de 387.000 ejemplares en todo el pas. Se trataranproductos y servicios, destinados a remodelar las viviendas, difundiendo el mismo, incentivando a la decisin de compra y mostrando los distintos beneficios al renovar los ambientes del hogar. Las Empresas participantes, figuraran mediante unagacetilla, como referentes en las notas periodsticas, comunicando las novedades que deseen difundir, mediante el contacto que le hacemos con el Periodista del Diario. Esperando que sea de vuestro inters participar en esta importante edicin, nos mantenemos en contacto al efecto de encontrar juntos la manera de concretar su mejor participacin. PARA RECORDAR Salida Suplemento: 6 de Junio de 2015 Fecha tope de Contratacin: 2 de Junio de 2015 Si usted desea pautar en este suplemento, comunquese con nosotros, al telfono (011) 4567-0515 o enve un e-mail i...@grupovapa.com.ar
Re: CORTE de conexión red al ingresar a Facebook (CASO RARO)
El Wed, 13 May 2015 07:19:51 -0700, Eduardo Gil escribió: El mié 13-may-15, Camaleón noela...@gmail.com escribió: Gracias por contestar. ¿Qué pruebas quiere que haga? (...) Cuando notes que has perdido la conectividad, desde una terminal ejecuta los siguientes comandos y manda el resultado: - ping 192.168.0.1 (donde 192.168.01 es la IP del router) - ping -c5 8.8.8.8 - host google.es - dig facebook.com - ip ro - /sbin/ifconfig -a - wget www.google.es - cat /etc/resolv.conf Saludos, GRACIAS por contestar. Aquí van las respuestas a estos comandos. (...) Bien, veo que sí llegas al router local lo cual es más normal. Ahora haz lo mismo pero con la interfaz de red cableada (evita el uso del wifi porque si lo usas añadimos varias capas de problemas más adicionales). Manda los resultados y seguimos. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.05.13.14.39...@gmail.com
Re: CORTE de conexión red al ingresar a Facebook (CASO RARO)
El mié 13-may-15, Carlos Manuel Escalona Villeda cescal...@corplogistica.com escribió: Asunto: Re: CORTE de conexión red al ingresar a Facebook (CASO RARO) Para: Eduardo Gil egis_e...@yahoo.com.ar, debian-user-spanish@lists.debian.org Fecha: miércoles, 13 de mayo de 2015, 11:29 Según esto lo que muere no es tu conexión de red sino tu gateway. podrías poner el comando route -n antes y después de la conexión para ver si no cambia la ruta por defecto. Igualmente ayudaría un tracepath 8.8.8.8 antes y después del error para saber en que punto exáctamente está muriendo. Gracias. Al pie le envio respuesta a estos comandos. De todas maneras le comento que el GATEWAY sigue funcionando bien con OTRAS PC en el mismo momento en que se corta la comunicación con la PC problemática. OK. Gracias por responder. Aquí van las respuestas ANTES del corte: - route -n Tabla de rutas IP del núcleo Destino PasarelaGenmask Indic Métric RefUso Interfaz 0.0.0.0 192.168.100.1 0.0.0.0 UG0 00 wlan0 192.168.100.0 0.0.0.0 255.255.255.0 U 9 00 wlan0 - tracepath 8.8.8.8 1?: [LOCALHOST] pmtu 1500 1: 192.168.100.110.488ms 1: 192.168.100.1 2.192ms 2: 186.182.228.1 6.562ms 3: 10.2.14.1 7.159ms 4: 10.2.11.225 9.832ms asymm 5 5: 10.2.11.225 9.136ms 6: no reply . 24: no reply Aquí van las respuestas DESPUES del corte: - route -n Tabla de rutas IP del núcleo Destino PasarelaGenmask Indic Métric RefUso Interfaz 0.0.0.0 192.168.100.1 0.0.0.0 UG0 00 wlan0 192.168.100.0 0.0.0.0 255.255.255.0 U 9 00 wlan0 tracepath 8.8.8.8 1?: [LOCALHOST] pmtu 1500 1: no reply 2: no reply 24: no reply -- Gracias por colaborar. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1431528311.27742.yahoomailba...@web140604.mail.bf1.yahoo.com
Re: [OT] ¿Cambian los ISP el ToS?
El Wed, 13 de May de 2015, a las 04:21:50PM +0200, Raúl Alexis Betancor Santana dijo: Hola José Miguel, Hola, Raúl. Tu error está en suponer que porque tu pongas esos valores ... se van a respetar en la WAN, ningún operador los respecta, ya que ellos los sobreescriben según les convenga. En temas de QoS, solo puedes controlar lo que entra o sale de tu LAN ... no lo que viaja por la WAN. Más que error, lo que quiero saber es si esto es así o no. Me fastidia porque me impide reconocer a la entrada el tráfico ssh interactivo del que no lo es (scp). Saludos. -- Femmina è cosa mobil per natura. --- Francisco Petrarca --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513144807.ga7...@cubo.casa
Re: CORTE de conexión red al ingresar a Facebook (CASO RARO)
El mié 13-may-15, Carlos Manuel Escalona Villeda cescal...@corplogistica.com escribió: Asunto: Re: CORTE de conexión red al ingresar a Facebook (CASO RARO) Para: A MI NO, ENVIA A LA LISTA noelamac+a_mi_no_envia_a_la_li...@gmail.com, debian-user-spanish@lists.debian.org Fecha: miércoles, 13 de mayo de 2015, 11:46 Ojo la IP 192.168.100.100 no corresponde al router sino a la interfaz wlan0, el ping debe hacerse al router. --- SI... ya me avisó del error José Luis Triviño. Ya mandé recién las pruebas a la IP correcta. Disculpas. SAluidos -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1431529706.32348.yahoomailba...@web140602.mail.bf1.yahoo.com
Re: CORTE de conexión red al ingresar a Facebook (CASO RARO)
El mié 13-may-15, José Luis Triviño triv...@lcc.uma.es escribió: Hola, No te resulta extraño que la dirección de tu router sea la misma que la de tu interface wlan0? ¡!GRACIASS! Fue error mío. La IP del router es 192.168.100.1 Aquí van entonces las PRUEBAS ANTES del CORTE -$ ping 192.168.100.1 PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data. 64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=2.09 ms 64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=1.84 ms 64 bytes from 192.168.100.1: icmp_seq=3 ttl=64 time=2.06 ms 64 bytes from 192.168.100.1: icmp_seq=4 ttl=64 time=2.45 ms 64 bytes from 192.168.100.1: icmp_seq=5 ttl=64 time=1.45 ms 64 bytes from 192.168.100.1: icmp_seq=6 ttl=64 time=1.45 ms 64 bytes from 192.168.100.1: icmp_seq=7 ttl=64 time=1.87 ms ^C --- 192.168.100.1 ping statistics --- 7 packets transmitted, 7 received, 0% packet loss, time 6009ms rtt min/avg/max/mdev = 1.454/1.891/2.453/0.332 ms Y AHORA LUEGO DEL CORTE -$ ping 192.168.100.1 PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data. ping: sendmsg: No buffer space available ping: sendmsg: No buffer space available ping: sendmsg: No buffer space available ping: sendmsg: No buffer space available ping: sendmsg: No buffer space available ping: sendmsg: No buffer space available ping: sendmsg: No buffer space available ping: sendmsg: No buffer space available ping: sendmsg: No buffer space available ping: sendmsg: No buffer space available ping: sendmsg: No buffer space available ^C --- 192.168.100.1 ping statistics --- 19 packets transmitted, 0 received, 100% packet loss, time 37021ms -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1431529547.95195.yahoomailba...@web140605.mail.bf1.yahoo.com
Re: CORTE de conexión red al ingresar a Facebook (CASO RARO)
El Wed, 13 May 2015 14:46:46 +, Carlos Manuel Escalona Villeda escribió: El mié., 13 de may. de 2015 a la(s) 9:39 a. m., Camaleón noela...@gmail.com escribió: El Wed, 13 May 2015 07:19:51 -0700, Eduardo Gil escribió: (...) GRACIAS por contestar. Aquí van las respuestas a estos comandos. (...) Bien, veo que sí llegas al router local lo cual es más normal. Ahora haz lo mismo pero con la interfaz de red cableada (evita el uso del wifi porque si lo usas añadimos varias capas de problemas más adicionales). Manda los resultados y seguimos. Ojo la IP 192.168.100.100 no corresponde al router sino a la interfaz wlan0, el ping debe hacerse al router. Cierto, la IP del router es la 192.168.100.1. @Eduardo, tienes que ser MUY cuidadoso con las pruebas que haces. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.05.13.15.13...@gmail.com
Re: CORTE de conexión red al ingresar a Facebook (CASO RARO)
El mié 13-may-15, Camaleón noela...@gmail.com escribió: Gracias por contestar. ¿Qué pruebas quiere que haga? (...) Cuando notes que has perdido la conectividad, desde una terminal ejecuta los siguientes comandos y manda el resultado: - ping 192.168.0.1 (donde 192.168.01 es la IP del router) - ping -c5 8.8.8.8 - host google.es - dig facebook.com - ip ro - /sbin/ifconfig -a - wget www.google.es - cat /etc/resolv.conf Saludos, GRACIAS por contestar. Aquí van las respuestas a estos comandos. - ping 192.168.100.100 (la IP del router) PING 192.168.100.100 (192.168.100.100) 56(84) bytes of data. 64 bytes from 192.168.100.100: icmp_seq=1 ttl=64 time=0.038 ms 64 bytes from 192.168.100.100: icmp_seq=2 ttl=64 time=0.049 ms 64 bytes from 192.168.100.100: icmp_seq=3 ttl=64 time=0.040 ms 64 bytes from 192.168.100.100: icmp_seq=4 ttl=64 time=0.049 ms 64 bytes from 192.168.100.100: icmp_seq=5 ttl=64 time=0.049 ms 64 bytes from 192.168.100.100: icmp_seq=6 ttl=64 time=0.039 ms 64 bytes from 192.168.100.100: icmp_seq=7 ttl=64 time=0.046 ms 64 bytes from 192.168.100.100: icmp_seq=8 ttl=64 time=0.041 ms ^C --- 192.168.100.100 ping statistics --- 8 packets transmitted, 8 received, 0% packet loss, time 6999ms rtt min/avg/max/mdev = 0.038/0.043/0.049/0.009 ms (Aunque otras veces ni siquiera puede alcanzar el router) - ping -c5 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. From 192.168.100.100 icmp_seq=1 Destination Host Unreachable From 192.168.100.100 icmp_seq=2 Destination Host Unreachable From 192.168.100.100 icmp_seq=3 Destination Host Unreachable From 192.168.100.100 icmp_seq=4 Destination Host Unreachable From 192.168.100.100 icmp_seq=5 Destination Host Unreachable --- 8.8.8.8 ping statistics --- 5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4001ms pipe 4 - host google.es ;; connection timed out; no servers could be reached - dig facebook.com ;; global options: +cmd ;; connection timed out; no servers could be reached - ip ro default via 192.168.100.1 dev wlan0 proto static 192.168.100.0/24 dev wlan0 proto kernel scope link src 192.168.100.100 metric 9 - /sbin/ifconfig -a eth0 Link encap:Ethernet direcciónHW f4:6d:04:ef:b8:91 ACTIVO DIFUSIÓN MULTICAST MTU:1500 Métrica:1 Paquetes RX:0 errores:0 perdidos:0 overruns:0 frame:0 Paquetes TX:0 errores:0 perdidos:0 overruns:0 carrier:0 colisiones:0 long.colaTX:1000 Bytes RX:0 (0.0 B) TX bytes:0 (0.0 B) loLink encap:Bucle local Direc. inet:127.0.0.1 Másc:255.0.0.0 Dirección inet6: ::1/128 Alcance:Anfitrión ACTIVO BUCLE FUNCIONANDO MTU:65536 Métrica:1 Paquetes RX:1812 errores:0 perdidos:0 overruns:0 frame:0 Paquetes TX:1812 errores:0 perdidos:0 overruns:0 carrier:0 colisiones:0 long.colaTX:0 Bytes RX:211906 (211.9 KB) TX bytes:211906 (211.9 KB) wlan0 Link encap:Ethernet direcciónHW 00:08:54:88:67:ac Direc. inet:192.168.100.100 Difus.:192.168.100.255 Másc:255.255.255.0 Dirección inet6: fe80::208:54ff:fe88:67ac/64 Alcance:Enlace ACTIVO DIFUSIÓN FUNCIONANDO MULTICAST MTU:1500 Métrica:1 Paquetes RX:9391 errores:0 perdidos:0 overruns:0 frame:0 Paquetes TX:7544 errores:0 perdidos:0 overruns:0 carrier:0 colisiones:0 long.colaTX:1000 Bytes RX:11043422 (11.0 MB) TX bytes:1237425 (1.2 MB) - wget www.google.es --2015-05-13 11:12:11-- http://www.google.es/ Resolviendo www.google.es (www.google.es)... falló: Nombre o servicio desconocido. wget: no se pudo resolver la dirección del equipo “www.google.es” - cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.1.1 -- Gracias por su colaboración. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1431526791.57178.yahoomailba...@web140603.mail.bf1.yahoo.com
Re: [OT] ¿Cambian los ISP el ToS?
El Wed, 13 May 2015 16:23:26 +0200, José Miguel (sio2) escribió: Hola, Camaleón. ¿Sabe alguno algo al respecto? Si te refieres a priorizar algún tipo de tráfico, yo te diría que no, salvo lo que contratas sobre el papel (cuando hay TV de por medio). A lo que me refiero es que a un paquete que sale de mi máquina con valor 0x10 (mínimo retardo) en su segundo byte de la cabecera IP (o sea, el byte ToS), le cambien ese valor; y le pongan 0x0 (tráfico normal). Ni idea... no he tenido ningún problema con Movistar ¿Has probado a hacer lo que yo he hecho? Es por curiosidad. ¿Acceder en remoto a un equipo mediante ssh? Sí. ni con ninguno de los routers que suministra ni cuando usaba rfc 1483 ni cuando nos han pasado a los direccionamientos pseudo-estáticos. En cuanto al cambio que notas, yo buscaría una posible causa por otro lado: https://www.google.es/webhp?q=ssh+tos+changes ¿Te refieres al bug del cliente openSSH? No es eso. (...) No, me refiero a que el cambio de ToS puede ser normal, que no lo sé, por eso te lo comento. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.05.13.14.42...@gmail.com
Re: [OT] ¿Cambian los ISP el ToS?
Hola, Camaleón. ¿Sabe alguno algo al respecto? Si te refieres a priorizar algún tipo de tráfico, yo te diría que no, salvo lo que contratas sobre el papel (cuando hay TV de por medio). A lo que me refiero es que a un paquete que sale de mi máquina con valor 0x10 (mínimo retardo) en su segundo byte de la cabecera IP (o sea, el byte ToS), le cambien ese valor; y le pongan 0x0 (tráfico normal). Ni idea... no he tenido ningún problema con Movistar ¿Has probado a hacer lo que yo he hecho? Es por curiosidad. ni con ninguno de los routers que suministra ni cuando usaba rfc 1483 ni cuando nos han pasado a los direccionamientos pseudo-estáticos. En cuanto al cambio que notas, yo buscaría una posible causa por otro lado: https://www.google.es/webhp?q=ssh+tos+changes ¿Te refieres al bug del cliente openSSH? No es eso. He hecho lo siguiente: Máquinas A1 (Cliente) y A2 (Servidor) en la misma red local (en realidad, A2 es máquina virtual). Genero tráfico ssh interactivo y me pogno a escuchar con tcpdump en ambas máquinas. Tanto en A1 como en A2, observo que los paquetes salientes tienen el ToS a 0x10 y los entrantes también. Lo esperable, por otro lado. Ahora tomo una máquina B, que es un servidor externo y hago la misma prueba. En ambas máquinas observo que los paquetes salientes tiene el byte con valor 0x10 y los entrantes como 0x0. Como los paquetes salientes de una máquina son los entrantes de la otra, está claro que algo ha tenido que cambiarles el valor del byte durante el camino. Además, el servidor A2 y el servidor B tienen exactamente la misma configuración y el mismo software. Un saludo. -- ¿No ha de haber un espíritu valiente? ¿Siempre se ha de sentir lo que se dice? ¿Nunca se ha de decir lo que se siente? --- Francisco de Quevedo --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513142326.ga4...@cubo.casa
Re: [OT] ¿Cambian los ISP el ToS?
Hola José Miguel, Tu error está en suponer que porque tu pongas esos valores ... se van a respetar en la WAN, ningún operador los respecta, ya que ellos los sobreescriben según les convenga. En temas de QoS, solo puedes controlar lo que entra o sale de tu LAN ... no lo que viaja por la WAN. - Mensaje original - De: José Miguel (sio2) sio2.sio2+lista.deb...@gmail.com Para: debian-user-spanish@lists.debian.org Enviados: Miércoles, 13 de Mayo 2015 15:23:26 Asunto: Re: [OT] ¿Cambian los ISP el ToS? Hola, Camaleón. ¿Sabe alguno algo al respecto? Si te refieres a priorizar algún tipo de tráfico, yo te diría que no, salvo lo que contratas sobre el papel (cuando hay TV de por medio). A lo que me refiero es que a un paquete que sale de mi máquina con valor 0x10 (mínimo retardo) en su segundo byte de la cabecera IP (o sea, el byte ToS), le cambien ese valor; y le pongan 0x0 (tráfico normal). Ni idea... no he tenido ningún problema con Movistar ¿Has probado a hacer lo que yo he hecho? Es por curiosidad. ni con ninguno de los routers que suministra ni cuando usaba rfc 1483 ni cuando nos han pasado a los direccionamientos pseudo-estáticos. En cuanto al cambio que notas, yo buscaría una posible causa por otro lado: https://www.google.es/webhp?q=ssh+tos+changes ¿Te refieres al bug del cliente openSSH? No es eso. He hecho lo siguiente: Máquinas A1 (Cliente) y A2 (Servidor) en la misma red local (en realidad, A2 es máquina virtual). Genero tráfico ssh interactivo y me pogno a escuchar con tcpdump en ambas máquinas. Tanto en A1 como en A2, observo que los paquetes salientes tienen el ToS a 0x10 y los entrantes también. Lo esperable, por otro lado. Ahora tomo una máquina B, que es un servidor externo y hago la misma prueba. En ambas máquinas observo que los paquetes salientes tiene el byte con valor 0x10 y los entrantes como 0x0. Como los paquetes salientes de una máquina son los entrantes de la otra, está claro que algo ha tenido que cambiarles el valor del byte durante el camino. Además, el servidor A2 y el servidor B tienen exactamente la misma configuración y el mismo software. Un saludo. -- ¿No ha de haber un espíritu valiente? ¿Siempre se ha de sentir lo que se dice? ¿Nunca se ha de decir lo que se siente? --- Francisco de Quevedo --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513142326.ga4...@cubo.casa -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1785210950.341030.1431526910671.javamail.zim...@dimension-virtual.com
Re: [OT] ¿Cambian los ISP el ToS?
El Wed, 13 de May de 2015, a las 02:42:26PM +, Camaleón dijo: ¿Has probado a hacer lo que yo he hecho? Es por curiosidad. ¿Acceder en remoto a un equipo mediante ssh? Sí. Eso doy por su puesto que lo haces, si no todos los días, casi todos. Me refiero a abrir una sesión SSH y ver cuál es el ToS de los paquetes generados y recibidos. Un saludo. -- En la vida humana sólo unos pocos sueños se cumplen, la mayoría se roncan. --- Enrique Jardiel Poncela --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513145231.gb7...@cubo.casa
Re: CORTE de conexión red al ingresar a Facebook (CASO RARO)
El mié 13-may-15, Camaleón noela...@gmail.com escribió: (...) Bien, veo que sí llegas al router local lo cual es más normal. Ahora haz lo mismo pero con la interfaz de red cableada (evita el uso del wifi porque si lo usas añadimos varias capas de problemas más adicionales). Manda los resultados y seguimos. - OK. AHORA estoy llegando al router pero... no siempre pasa esto. Muchas veces (en forma aleatoria) el PEN del WI-FI empieza a mandar paquetes erroneos en forma masiva y otras veces ni siquiera se llega al router (supongo que es porque el router bloquea esa tormenta de broadcast) Ahora NO puedo hace las pruebas por cable porque tengo las bocas ocupadas y trabajando (se están transfiriendo archivos de video) así que más tarde (cuando terminen las transferencias) mando las pruebas con cable. SAludos. Y Gracias. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1431528832.27768.yahoomailba...@web140603.mail.bf1.yahoo.com
Re: CORTE de conexión red al ingresar a Facebook (CASO RARO)
Según esto lo que muere no es tu conexión de red sino tu gateway. podrías poner el comando route -n antes y después de la conexión para ver si no cambia la ruta por defecto. Igualmente ayudaría un tracepath 8.8.8.8 antes y después del error para saber en que punto exáctamente está muriendo. El mié., 13 de may. de 2015 a la(s) 9:23 a. m., Eduardo Gil egis_e...@yahoo.com.ar escribió: El mié 13-may-15, Camaleón noela...@gmail.com escribió: Gracias por contestar. ¿Qué pruebas quiere que haga? (...) Cuando notes que has perdido la conectividad, desde una terminal ejecuta los siguientes comandos y manda el resultado: - ping 192.168.0.1 (donde 192.168.01 es la IP del router) - ping -c5 8.8.8.8 - host google.es - dig facebook.com - ip ro - /sbin/ifconfig -a - wget www.google.es - cat /etc/resolv.conf Saludos, GRACIAS por contestar. Aquí van las respuestas a estos comandos. - ping 192.168.100.100 (la IP del router) PING 192.168.100.100 (192.168.100.100) 56(84) bytes of data. 64 bytes from 192.168.100.100: icmp_seq=1 ttl=64 time=0.038 ms 64 bytes from 192.168.100.100: icmp_seq=2 ttl=64 time=0.049 ms 64 bytes from 192.168.100.100: icmp_seq=3 ttl=64 time=0.040 ms 64 bytes from 192.168.100.100: icmp_seq=4 ttl=64 time=0.049 ms 64 bytes from 192.168.100.100: icmp_seq=5 ttl=64 time=0.049 ms 64 bytes from 192.168.100.100: icmp_seq=6 ttl=64 time=0.039 ms 64 bytes from 192.168.100.100: icmp_seq=7 ttl=64 time=0.046 ms 64 bytes from 192.168.100.100: icmp_seq=8 ttl=64 time=0.041 ms ^C --- 192.168.100.100 ping statistics --- 8 packets transmitted, 8 received, 0% packet loss, time 6999ms rtt min/avg/max/mdev = 0.038/0.043/0.049/0.009 ms (Aunque otras veces ni siquiera puede alcanzar el router) - ping -c5 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. From 192.168.100.100 icmp_seq=1 Destination Host Unreachable From 192.168.100.100 icmp_seq=2 Destination Host Unreachable From 192.168.100.100 icmp_seq=3 Destination Host Unreachable From 192.168.100.100 icmp_seq=4 Destination Host Unreachable From 192.168.100.100 icmp_seq=5 Destination Host Unreachable --- 8.8.8.8 ping statistics --- 5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4001ms pipe 4 - host google.es ;; connection timed out; no servers could be reached - dig facebook.com ;; global options: +cmd ;; connection timed out; no servers could be reached - ip ro default via 192.168.100.1 dev wlan0 proto static 192.168.100.0/24 dev wlan0 proto kernel scope link src 192.168.100.100 metric 9 - /sbin/ifconfig -a eth0 Link encap:Ethernet direcciónHW f4:6d:04:ef:b8:91 ACTIVO DIFUSIÓN MULTICAST MTU:1500 Métrica:1 Paquetes RX:0 errores:0 perdidos:0 overruns:0 frame:0 Paquetes TX:0 errores:0 perdidos:0 overruns:0 carrier:0 colisiones:0 long.colaTX:1000 Bytes RX:0 (0.0 B) TX bytes:0 (0.0 B) loLink encap:Bucle local Direc. inet:127.0.0.1 Másc:255.0.0.0 Dirección inet6: ::1/128 Alcance:Anfitrión ACTIVO BUCLE FUNCIONANDO MTU:65536 Métrica:1 Paquetes RX:1812 errores:0 perdidos:0 overruns:0 frame:0 Paquetes TX:1812 errores:0 perdidos:0 overruns:0 carrier:0 colisiones:0 long.colaTX:0 Bytes RX:211906 (211.9 KB) TX bytes:211906 (211.9 KB) wlan0 Link encap:Ethernet direcciónHW 00:08:54:88:67:ac Direc. inet:192.168.100.100 Difus.:192.168.100.255 Másc:255.255.255.0 Dirección inet6: fe80::208:54ff:fe88:67ac/64 Alcance:Enlace ACTIVO DIFUSIÓN FUNCIONANDO MULTICAST MTU:1500 Métrica:1 Paquetes RX:9391 errores:0 perdidos:0 overruns:0 frame:0 Paquetes TX:7544 errores:0 perdidos:0 overruns:0 carrier:0 colisiones:0 long.colaTX:1000 Bytes RX:11043422 (11.0 MB) TX bytes:1237425 (1.2 MB) - wget www.google.es --2015-05-13 11:12:11-- http://www.google.es/ Resolviendo www.google.es (www.google.es)... falló: Nombre o servicio desconocido. wget: no se pudo resolver la dirección del equipo “www.google.es” - cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.1.1 -- Gracias por su colaboración. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1431526791.57178.yahoomailba...@web140603.mail.bf1.yahoo.com
Re: CORTE de conexión red al ingresar a Facebook (CASO RARO)
On 13/05/15 16:19, Eduardo Gil wrote: El mié 13-may-15, Camaleón noela...@gmail.com escribió: Gracias por contestar. ¿Qué pruebas quiere que haga? (...) Cuando notes que has perdido la conectividad, desde una terminal ejecuta los siguientes comandos y manda el resultado: - ping 192.168.0.1 (donde 192.168.01 es la IP del router) - ping -c5 8.8.8.8 - host google.es - dig facebook.com - ip ro - /sbin/ifconfig -a - wget www.google.es - cat /etc/resolv.conf Saludos, GRACIAS por contestar. Aquí van las respuestas a estos comandos. - ping 192.168.100.100 (la IP del router) - /sbin/ifconfig -a wlan0 Link encap:Ethernet direcciónHW 00:08:54:88:67:ac Direc. inet:192.168.100.100 Difus.:192.168.100.255 Másc:255.255.255.0 Dirección inet6: fe80::208:54ff:fe88:67ac/64 Alcance:Enlace ACTIVO DIFUSIÓN FUNCIONANDO MULTICAST MTU:1500 Métrica:1 Paquetes RX:9391 errores:0 perdidos:0 overruns:0 frame:0 Paquetes TX:7544 errores:0 perdidos:0 overruns:0 carrier:0 colisiones:0 long.colaTX:1000 Bytes RX:11043422 (11.0 MB) TX bytes:1237425 (1.2 MB) Hola, No te resulta extraño que la dirección de tu router sea la misma que la de tu interface wlan0? Saludos, -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55535fae.90...@lcc.uma.es
Re: [OT] ¿Cambian los ISP el ToS?
El Wed, 13 May 2015 16:52:31 +0200, José Miguel (sio2) escribió: El Wed, 13 de May de 2015, a las 02:42:26PM +, Camaleón dijo: ¿Has probado a hacer lo que yo he hecho? Es por curiosidad. ¿Acceder en remoto a un equipo mediante ssh? Sí. Eso doy por su puesto que lo haces, si no todos los días, casi todos. Lo menos posible, la verdad. Me refiero a abrir una sesión SSH y ver cuál es el ToS de los paquetes generados y recibidos. No, no analizo los paquetes salvo que detecte algún problema. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.05.13.15.02...@gmail.com
Re: CORTE de conexión red al ingresar a Facebook (CASO RARO)
El Wed, 13 May 2015 07:53:52 -0700, Eduardo Gil escribió: El mié 13-may-15, Camaleón noela...@gmail.com escribió: (...) Bien, veo que sí llegas al router local lo cual es más normal. Ahora haz lo mismo pero con la interfaz de red cableada (evita el uso del wifi porque si lo usas añadimos varias capas de problemas más adicionales). Manda los resultados y seguimos. OK. AHORA estoy llegando al router pero... no siempre pasa esto. Muchas veces (en forma aleatoria) el PEN del WI-FI empieza a mandar paquetes erroneos en forma masiva y otras veces ni siquiera se llega al router (supongo que es porque el router bloquea esa tormenta de broadcast) Por eso para hacer pruebas y diagnosticar problemas siempre es recomendable usar la conexión cableada. Ahora NO puedo hace las pruebas por cable porque tengo las bocas ocupadas y trabajando (se están transfiriendo archivos de video) así que más tarde (cuando terminen las transferencias) mando las pruebas con cable. Perfecto, es importante ver los resultados que obtienes. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.05.13.15.05...@gmail.com
Re: CORTE de conexión red al ingresar a Facebook (CASO RARO)
El miércoles, 13 may 2015, a las 16:19 UTC+2 horas, Eduardo Gil escribió: - ping 192.168.100.100 (la IP del router) PING 192.168.100.100 (192.168.100.100) 56(84) bytes of data. 64 bytes from 192.168.100.100: icmp_seq=1 ttl=64 time=0.038 ms ¿La misma IP? Estarás haciendo esas pruebas desde el enrutador, supongo. -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513163234.62367...@gmail.com
Re: CORTE de conexión red al ingresar a Facebook (CASO RARO)
Ojo la IP 192.168.100.100 no corresponde al router sino a la interfaz wlan0, el ping debe hacerse al router. El mié., 13 de may. de 2015 a la(s) 9:39 a. m., Camaleón noela...@gmail.com escribió: El Wed, 13 May 2015 07:19:51 -0700, Eduardo Gil escribió: El mié 13-may-15, Camaleón noela...@gmail.com escribió: Gracias por contestar. ¿Qué pruebas quiere que haga? (...) Cuando notes que has perdido la conectividad, desde una terminal ejecuta los siguientes comandos y manda el resultado: - ping 192.168.0.1 (donde 192.168.01 es la IP del router) - ping -c5 8.8.8.8 - host google.es - dig facebook.com - ip ro - /sbin/ifconfig -a - wget www.google.es - cat /etc/resolv.conf Saludos, GRACIAS por contestar. Aquí van las respuestas a estos comandos. (...) Bien, veo que sí llegas al router local lo cual es más normal. Ahora haz lo mismo pero con la interfaz de red cableada (evita el uso del wifi porque si lo usas añadimos varias capas de problemas más adicionales). Manda los resultados y seguimos. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.05.13.14.39...@gmail.com
Re: [OT] ¿Cambian los ISP el ToS?
El Wed, 13 de May de 2015, a las 07:56:42PM +0200, Raúl Alexis Betancor Santana dijo: Es que estás cometiendo varios errores de base ... A ver. 1- En el router que te hace NAT (porque supongo que lo tienes en multipuesto y el router te hace NAT), es el propio router quien SEGÚN su politica de QoS ... cambiará los valores que envía a la WAN, esto es lo más normal del mundo. Bueno, he dicho que esa es una posibilidad y por eso pregunto. Lo que ocurre es que he hecho pruebas con cuatro sitios distintos: 1. Dos cuyos router tendría que ver si realmente modifican el byte, porque disponen de sistemas de estos de administración por web y una interfaz telnet. 2. Otro que es un VPN con IP compartida. Ahí, obviamente no controlo más allá de la propia máquina virtual. 3. Otro que es el de mi casa y tiene instalado openWRT. Aquí se fehacientemente que no hay aplicada ninguna política. El problema es que no tengo contratado con Telefónica sino con otro operador (Vodafone). Pues bien escoja el origen y el destino que sea, siempre se produce el mismo resultado. Si los ISP no hicieran ninguna modificación en el camino y todo fuera culpa de mis routers, como sé que el que lleva openwrt no hace ningún tipo de modificación, en caso de que comunicara éste con cualquiera de las máquinas que hay detrás de los otros tres, en estas máquinas vería llegar el paquete con el DSCP original. Pero eso no ocurre. 2- Los operados NO RESPETAN, los valores de QoS que tu utilices ..., no tienen porque hacerlo y de hecho, no lo hacen, ya que aplican sus propias políticas. Desde mi más completa ignorancia de los protocolos de enrutamiento que usan en sus routers. ¿Forzosamente lo tienen que hacer a través del byte ToS de la cabecera IP? Sí, ya sé que está para eso. 3- Sigue el consejo que te puse en el otro correo ... preocupate de clasificar, prioritizar y limitar LO QUE ENVIAS, lo que recibes ... no lo puedes controlar, en todo caso ... no en la eth0 ... sino en la eth1, osea ... dale la vuelta a la 'tortilla'. Eso no es cierto, lo que recibo lo puedo clasificar perfectamente, no ciertamente en la planificación ingress de eth0, sino en la salida de una interfaz virtual ifb a la que puedo redirigir los paquetes. La única limitación que hay es que no puedo hacer una clasificación stateful (pues para eso necesito netfilter) En eth1 es bastante inútil hacerlo, porque hay tráfico que se queda en el servidor y porque en mi caso hay muchas interfaces internas. Un saludo. -- Todo es vana arquitectura, porque dijo un sabio un día que a los sastres se debía la mitad de su hermosura. --- Lope de Vega -- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513183701.gb17...@cubo.casa
Re: [OT] ¿Cambian los ISP el ToS?
Vamos por partes porque veo que no me estás entendiendo ... - Mensaje original - De: José Miguel (sio2) sio2.sio2+lista.deb...@gmail.com Para: debian-user-spanish@lists.debian.org Enviados: Miércoles, 13 de Mayo 2015 19:37:01 Asunto: Re: [OT] ¿Cambian los ISP el ToS? El Wed, 13 de May de 2015, a las 07:56:42PM +0200, Raúl Alexis Betancor Santana dijo: Es que estás cometiendo varios errores de base ... A ver. 1- En el router que te hace NAT (porque supongo que lo tienes en multipuesto y el router te hace NAT), es el propio router quien SEGÚN su politica de QoS ... cambiará los valores que envía a la WAN, esto es lo más normal del mundo. Bueno, he dicho que esa es una posibilidad y por eso pregunto. Lo que ocurre es que he hecho pruebas con cuatro sitios distintos: 1. Dos cuyos router tendría que ver si realmente modifican el byte, porque disponen de sistemas de estos de administración por web y una interfaz telnet. 2. Otro que es un VPN con IP compartida. Ahí, obviamente no controlo más allá de la propia máquina virtual. 3. Otro que es el de mi casa y tiene instalado openWRT. Aquí se fehacientemente que no hay aplicada ninguna política. El problema es que no tengo contratado con Telefónica sino con otro operador (Vodafone). Pues bien escoja el origen y el destino que sea, siempre se produce el mismo resultado. Si los ISP no hicieran ninguna modificación en el camino y todo fuera culpa de mis routers, como sé que el que lleva openwrt no hace ningún tipo de modificación, en caso de que comunicara éste con cualquiera de las máquinas que hay detrás de los otros tres, en estas máquinas vería llegar el paquete con el DSCP original. Pero eso no ocurre. Que da igual si es tu router, o el del operador .. TU no puedes controlar por donde va a pasar ese paquete ... y entre todos los routers/switches por los que pase, UNO habrá que borrarrá los campos, es que no hay ningún RFC que diga que esos campos se tengan que respetar extremo a extremo ... y como tál NADIE los respeta. 2- Los operados NO RESPETAN, los valores de QoS que tu utilices ..., no tienen porque hacerlo y de hecho, no lo hacen, ya que aplican sus propias políticas. Desde mi más completa ignorancia de los protocolos de enrutamiento que usan en sus routers. ¿Forzosamente lo tienen que hacer a través del byte ToS de la cabecera IP? Sí, ya sé que está para eso. Lo puedes hacer, y lo hacen, por cuarentamil parámetros diferentes, eso es política del operador, política que puede variar interfaz a interfaz, de router en router, conclusión = no te bases en eso. 3- Sigue el consejo que te puse en el otro correo ... preocupate de clasificar, prioritizar y limitar LO QUE ENVIAS, lo que recibes ... no lo puedes controlar, en todo caso ... no en la eth0 ... sino en la eth1, osea ... dale la vuelta a la 'tortilla'. Eso no es cierto, lo que recibo lo puedo clasificar perfectamente, no ciertamente en la planificación ingress de eth0, sino en la salida de una interfaz virtual ifb a la que puedo redirigir los paquetes. La única limitación que hay es que no puedo hacer una clasificación stateful (pues para eso necesito netfilter) Te demuestro cuando quieras, que TU no puedes controlar lo que te entra, ni puedes clasificarlo. Clasificas lo que tu entrégas, no lo que recibes. Yo ahora cojo tu IP, y me meto un flood de 4Gb/s ... y te dejo frito, por mucha regla de iptables o de tc que pongas para clasificar o descartar ese tráfico. TU no controlas lo que te llega a tu interfaz WAN, lo controla TU OPERADOR. En eth1 es bastante inútil hacerlo, porque hay tráfico que se queda en el servidor y porque en mi caso hay muchas interfaces internas. No lo has entendido ... los protocolos de control de flujo de TCP, están diseñados para eso ..., como no puedes CONTROLAR lo que te entra por el eth0 ... pero SI lo que tu entregas (proveniente del eth0) al eth1 ... si limitas el tráfico que le entregas a los servidores internos ... AUTOMAGICAMENTE, verás como se empieza a estabilizar el tráfico que te llega al eth0 desde la WAN. De hecho es el típico ejemplo de porque en la mayoría de los casos, no se puede aprovechar al 100% el ancho de banda de bajada de una ADSL/FTTH, porque sino eres capaz de enviar los ACK's de salida ... el servidor remoto irá reduciendo la tasa a la que te manda tráfico de entrada, hasta llegar a un equilibrio. El script de QoS que yo uso .. genera clasificadores y colas para la interfaz WAN, de forma que NO permito que SALGA más tráfico de los equipos de LAN, del que yo establezca ... AUNQUE ME ESTE LLEGANDO MAS, lo encolo .. o lo descarto, de esa manera ... fuerzo a los protocolos de control de flujo a hacer su trabajo ... Lás únicas reglas que tengo para el downlink .. en todo el script ... son: ## downlink # # s1ow downloads down to somewhat less than the real speed to prevent # queuing at our ISP. Tune to see how high you
Re: Fwd: En una PC se apaga/suspende/hiberna; pero... [SE SOLUCIONO!]
On 12/05/15 21:33, Juan Lavieri wrote: Lo que sucede es que pareces venezolano :-) Si ¿en serio?. Tremenda metida de pata e ida de jeta que te has dado. Si abres la ayuda (en el panel izquierdo el icono que parece un salvavidas), el primer enlace dice Cerrar sesión, apagar o cambiar de usuario; si vamos a ese enlace, el tercer sub-tema es precisamente Suspender. Allí está. En realidad te sugiero que busques las notas de publicación de tu versión de gnome. (las del mio son estas) https://help.gnome.org/misc/release-notes/3.14/ Si no estás muy habituado a gnome shell comienza por la versión 3.8 (cambia el 3.14). Si quieres ver todas las versiones quita todo lo que viene después de notes y listo. Para conocer tu versión de gnome, usa el comando: $gnome-shell --version Y respecto a las extensiones, les no las habías visto, y eso que me instalé muchas. Mi barra superior está full Saludos. Le recomendaría que se abstuviera de sus comentarios de mal gustos para su persona, recuerde que esta es una lista pública y libre, lo que no significa, pública y liberta donde puedes dar muestras de plena xeonfobia como lo has hecho. Att. un venezolano. -- Dios en su Cielo, todo bien en la Tierra - -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55539af5.1080...@gmail.com
Re: [OT] ¿Cambian los ISP el ToS?
El Wed, 13 de May de 2015, a las 09:56:29PM +0200, Raúl Alexis Betancor Santana dijo: Que da igual si es tu router, o el del operador .. TU no puedes controlar por donde va a pasar ese paquete ... y entre todos los routers/switches por los que pase, UNO habrá que borrarrá los campos, es que no hay ningún RFC que diga que esos campos se tengan que respetar extremo a extremo ... y como tál NADIE los respeta. Vale. Zanjada la cuestión entonces. Paso de esos campos. TU no controlas lo que te llega a tu interfaz WAN, lo controla TU OPERADOR. Sí, lo he pillado ahora: como los paquetes me han llegado ya a la interfaz, ya no me sirve de mucho clasificarlo escrupulosamente. Es más eficiente intentar evitar que me lleguen en demasía a ella actuando sobre la salida gracias a... No lo has entendido ... los protocolos de control de flujo de TCP, De todos modos, por redundar en esto, aunque vea la eficacía de clasificar a la salida y ya está. Si a la entrada, jamás acepto más de 1Mbit/s de tráfico HTTP, precisamente por el control de flujo de TCP, el envío acabará ralentizándose también ¿no?: acepto menos, eso acabará suponiendo que reciba menos, que envíe menos paquete ACK de confirmación y, por lo tanto, que los servidore web a los que pido me acaben enviando a menor ritmo. Lo que sí puede resultar absurdo es intentar montar una planificación HTB. De hecho es el típico ejemplo de porque en la mayoría de los casos, no se puede aprovechar al 100% el ancho de banda de bajada de una ADSL/FTTH, porque sino eres capaz de enviar los ACK's de salida ... el servidor remoto irá reduciendo la tasa a la que te manda tráfico de entrada, hasta llegar a un equilibrio. Pues me interesaría poder hacer una estimación a priori de qué tráfico ACK de confirmación debo dejar salir, si quiero que me acabe llegando X tráfico de entrada. Y sobre esta estimación, pulir un poco, probado en la realidad. A ver si voy desencaminado (suponiendo que el grueso mayor del tráfico de salida es HTTP): Un paquete ACK tiene unos 60-70 bytes de longitud, creo recordar. Los paquetes de entrada, sin embargo serán bastante mayores, puesto que contienen la información que he pedido (una página, una foto, un archivo de vaya usted a saber qué. etc...). O sea, que habrá muchos que ronden los 1400 bytes y algunos que sean algo más pequeños. Estimemos que su tamaño medio es de 1300 bytes. Así pues, 65/1300 da el 5%. O sea que el tráfico de salida ACK está sobre el 5% del tráfico que recibiré. Por tanto, si tengo 10 Mb/s de ancho de banda de bajada, 500Kbit/s de tráfico ACK de confirmación podrían consumirme todo ese ancho. Así pues, tendré que asegurarme de que el tráfico de paquetes ACK sea menor para que no se llegue a ese extremo, al menos cuando haya otro tráfico que necesite hacer uso también de ese ancho de bajada. ¿Es así el cálculo, más o menos? Lás únicas reglas que tengo para el downlink .. en todo el script ... son: ## downlink # # s1ow downloads down to somewhat less than the real speed to prevent # queuing at our ISP. Tune to see how high you can set it. # ISPs tend to have *huge* queues to make sure big downloads are fast Vale, y he visto que después tienes limitado el tráfico al 70% del ancho de bajada. El hecho de que las colas de paquetes en el ISP sean grandes, ¿qué supone? ¿Mayor lantencia? ¿No acabo desaprovechando al final un 30% del ancho haciendo esto? Muchas gracias. Creo que voy aclarando conceptos.. -- La juventud es un defecto que se cura con el tiempo --- Enrique Jardiel Poncela --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513232358.ga28...@cubo.casa
Re: [OT] ¿Cambian los ISP el ToS?
El Wed, 13 May 2015 17:46:09 +0200, José Miguel (sio2) escribió: El Wed, 13 de May de 2015, a las 03:02:21PM +, Camaleón dijo: No, no analizo los paquetes salvo que detecte algún problema. Entonces, simplemente, no puedes contestar a mi pregunta. ¿Has detectado algún problema o se trata sólo de simple curiosidad? No te lo tomes a mal: no es una respuesta desabrida. No, hombre, si ya te he dicho antes que no sabía si el cambio de ToS era normal o no por eso te dije que investigaras por otro lado más allá de pensar que los ISP no tienen nada mejor que hacer que alterar el tráfico SSH :-) Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.05.13.15.55...@gmail.com
Re: [OT] ¿Cambian los ISP el ToS?
El Wed, 13 de May de 2015, a las 03:02:21PM +, Camaleón dijo: No, no analizo los paquetes salvo que detecte algún problema. Entonces, simplemente, no puedes contestar a mi pregunta. No te lo tomes a mal: no es una respuesta desabrida. Un saludo y gracias. -- Hay dos sistemas de conseguir la felicidad: uno, hacerse el idiota; otro, serlo. --- Enrique Jardiel Poncela. -- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513154609.ga10...@cubo.casa
Re: CORTE de conexión red al ingresar a Facebook (CASO RARO)
El Wed, 13 May 2015 08:25:24 -0700, Eduardo Gil escribió: El mié 13-may-15, Camaleón noela...@gmail.com escribió: Cierto, la IP del router es la 192.168.100.1. @Eduardo, tienes que ser MUY cuidadoso con las pruebas que haces. Saludos, Camaleón Si. Mis disculpas. Ya envié recién las pruebas con la IP del router 192.168.100.1 Allí se nota que se pierde la conexión. Bien, pero me sigue interesando las pruebas con la interfaz de red cableada. Sigo sosteniendo (sospechando) que el problema es del software de la PC. Supongo que por JScripts que cuando NO se hace uso de ellos el problema NO ocurre. (...) El mensaje de error del ping (sendmsg: No buffer space available) apunta a un problema con el driver de la tarjeta wifi que podemos tratar más adelante por eso me interesa comprobar si recibes el mismo el error con la tarjeta ethernet. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.05.13.15.44...@gmail.com
Re: [OT] ¿Cambian los ISP el ToS?
El Wed, 13 de May de 2015, a las 03:55:10PM +, Camaleón dijo: ¿Has detectado algún problema o se trata sólo de simple curiosidad? Estoy investigando la calidad de servicio y voy haciendo pruebas según voy aprendiendo. De hecho, una de las cosas para las que me interesa es para que la sesiones SSH vayan fluidas a todas horas. Cuando he ido a fijar una política para los paquetes que entran en la máquina, he pensado que sería buena idea reservar un mínimo ancho de banda de bajada para el tráfico SSH interactivo y no para el que se genera con scp (que a fin de cuentas es descargar o subir fichero y no me importa si va más o menos fluido). Pero he detectado que el tráfico, aunque sale bien del cliente, siempre llega al servidor con DSCP 0x0 cuando debería llegar con DSCP 0x4 el interactivo y con DSCP 0x2 el no interactivo. Y eso me impide distinguir uno y otro tráfico. En local todo funciona bien. Con FTP pasa lo mismo, aunque eso ya me importa menos. No, hombre, si ya te he dicho antes que no sabía si el cambio de ToS era normal o no por eso te dije que investigaras por otro lado más allá de pensar que los ISP no tienen nada mejor que hacer que alterar el tráfico SSH :-) Pero me dejaste una búsqueda en google en la que ningún enlace hablaba de lo que yo preguntaba o al menos así lo vi yo. Excepto el del foro de ubuntu que trataba de un bug del cliente ssh de openSSH que no le ponía el ToS correcto a los paquetes que generaba. Saludos. -- La virtud, como el arte, hallarse suele cerca de lo difícil [...] --- Lope de Vega --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513163424.ga12...@cubo.casa
Re: CORTE de conexión red al ingresar a Facebook (CASO RARO)
El mié 13-may-15, Camaleón noela...@gmail.com escribió: Cierto, la IP del router es la 192.168.100.1. @Eduardo, tienes que ser MUY cuidadoso con las pruebas que haces. Saludos, Camaleón Si. Mis disculpas. Ya envié recién las pruebas con la IP del router 192.168.100.1 Allí se nota que se pierde la conexión. Sigo sosteniendo (sospechando) que el problema es del software de la PC. Supongo que por JScripts que cuando NO se hace uso de ellos el problema NO ocurre. Tendría que PROBAR RE-instalando toda máquina JAVA - JScripts y limpiar todo rastro de los Scripts viejos. Este problema me está volviendo loco. Y para colmo ahora que cuento con una máquina menos (la del problema) el transtorno es grande. Me parece que si no lo resuelvo rápido voy a ahorrar tiempo si reinstalo todo desde cero aunque me quedará la duda sobre el origen del problema. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1431530724.5479.yahoomailba...@web140601.mail.bf1.yahoo.com
Re: Fwd: En una PC se apaga/suspende/hiberna; pero... [SE SOLUCIONO!]
Hola. El 13 de mayo de 2015, 14:11, Jose Maldonado josemal...@gmail.com escribió: On 12/05/15 21:33, Juan Lavieri wrote: Lo que sucede es que pareces venezolano :-) Si ¿en serio?. Tremenda metida de pata e ida de jeta que te has dado. Si abres la ayuda (en el panel izquierdo el icono que parece un salvavidas), el primer enlace dice Cerrar sesión, apagar o cambiar de usuario; si vamos a ese enlace, el tercer sub-tema es precisamente Suspender. Allí está. En realidad te sugiero que busques las notas de publicación de tu versión de gnome. (las del mio son estas) https://help.gnome.org/misc/release-notes/3.14/ Si no estás muy habituado a gnome shell comienza por la versión 3.8 (cambia el 3.14). Si quieres ver todas las versiones quita todo lo que viene después de notes y listo. Para conocer tu versión de gnome, usa el comando: $gnome-shell --version Y respecto a las extensiones, les no las habías visto, y eso que me instalé muchas. Mi barra superior está full Saludos. Le recomendaría que se abstuviera de sus comentarios de mal gustos para su persona, recuerde que esta es una lista pública y libre, lo que no significa, pública y liberta donde puedes dar muestras de plena xeonfobia como lo has hecho. Por favor, ¿podrías indicarme cuál es la muestra de xenofobia en la que he incurrido? Por lo que he visto o mejor dicho leído, Miguel ni se ha inmutado por lo que escribí ¿por qué lo haces tu? ¿Qué fue lo que te molesto? ¿Acaso lees pensamientos? Aún así, para tu información nací en Villa de Cura, Estado Aragua (si acaso sabes donde queda eso) y por cierto, posiblemente mucho antes que tus padren pensaran en engendrarte. La próxima vez que te vayas a ofender por algo, asegúrate de averiguar qué fue lo que intentó expresar el que te ofendió, así nunca quedarás mal. Saludos paisano. PD. Si lo deseas puedo explicarte qué quise decir con la frase pareces venezolano, tiene que ver con aquello de la diferencia entre un venezolano y .. No, mejor déjalo así. Att. un venezolano. -- Dios en su Cielo, todo bien en la Tierra - -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55539af5.1080...@gmail.com -- Juan Lavieri Errar es de humanos, pero es mas humano culpar a los demás.
Re: CORTE de conexión red al ingresar a Facebook (CASO RARO)
El mié 13-may-15, Camaleón noela...@gmail.com escribió: El mensaje de error del ping (sendmsg: No buffer space available) apunta a un problema con el driver de la tarjeta wifi que podemos tratar más adelante por eso me interesa comprobar si recibes el mismo el error con la tarjeta ethernet. --- Aquí van las pruebas con tarjeta de RED: ~$ ping -c5 yahoo.com.ar PING yahoo.com.ar (98.137.236.24) 56(84) bytes of data. 64 bytes from w2.src1.vip.gq1.yahoo.com (98.137.236.24): icmp_seq=1 ttl=49 time=200 ms 64 bytes from w2.src1.vip.gq1.yahoo.com (98.137.236.24): icmp_seq=2 ttl=49 time=199 ms 64 bytes from w2.src1.vip.gq1.yahoo.com (98.137.236.24): icmp_seq=3 ttl=49 time=200 ms 64 bytes from w2.src1.vip.gq1.yahoo.com (98.137.236.24): icmp_seq=4 ttl=49 time=199 ms 64 bytes from w2.src1.vip.gq1.yahoo.com (98.137.236.24): icmp_seq=5 ttl=49 time=199 ms --- yahoo.com.ar ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 199.428/199.895/200.294/0.646 ms ~$ ping -c5 192.168.100.1 PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data. 64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=0.836 ms 64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.713 ms 64 bytes from 192.168.100.1: icmp_seq=3 ttl=64 time=0.788 ms 64 bytes from 192.168.100.1: icmp_seq=4 ttl=64 time=1.19 ms 64 bytes from 192.168.100.1: icmp_seq=5 ttl=64 time=0.823 ms --- 192.168.100.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 3998ms rtt min/avg/max/mdev = 0.713/0.870/1.190/0.165 ms ~$ ping -c5 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=3.20 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=2.65 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=3.14 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=2.89 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=2.21 ms --- 8.8.8.8 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4000ms rtt min/avg/max/mdev = 2.219/2.824/3.207/0.362 ms AHORA con CORTE de RED... (gracias FB y sus Jscripts) ~$ ping -c5 yahoo.com.ar ping: unknown host yahoo.com.ar ~$ ping -c5 192.168.100.1 connect: Network is unreachable ~$ ping -c5 192.168.100.1 connect: Network is unreachable Ahora bien... si desconecto el cable espero unos segundos y reconecto la comunicación sale andando (siempre que no se use FB) lo mismo pasa cuando desconecto el pen de WI-FI espero unos segundos y reconecto Para mi que son los Jscrips... que deben interferir de alguna manera en el transporte de datos Bueno... eso... ¿Cómo LIMPIO completamente los JS y JAVA? O sea... desinstalo todo y LIMPIO TODO rastro Luego instalaría de nuevo... Para ver que pasa. SIno tendría que reinstalar TODO el SO y todos los aplicativos. :-( Y GRACIAS POR LA AYUDA. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1431570847.91121.yahoomailba...@web140603.mail.bf1.yahoo.com
(SOLUCIONADO) Re: Debian testing (Audacity no reproduce sonidos)
El 12/05/15 a las 15:24, Camaleón escribió: El Mon, 11 May 2015 22:34:00 +0200, Eduardo Rios escribió: Llevando Debian Jessie estable tan poco tiempo, me he decidido a saltar a la nueva testing. La primera en la frente: Con gnome tengo sonido sin mayor problema, pero con Audacity, depende del dispositivo de salida que escoja, no se escucha nada, o da error de dispositivo. La versión de Audacity es la misma tanto en Debian Jessie como testing. Si restauro la copia de seguridad de Debian Jessie, el sonido funciona perfectamente con audacity. Si vuelvo a testing, el sonido va bien con gnome, Ryhtmbox, etc... pero con Audacity, nada. Prueba creando un nuevo usuario, iniciando sesión y probando Audacity desde ahí. También puedes iniciar Audacity desde línea de comandos por si saca algún mensajito que sea interesante. Ejecutando audacity desde terminal, he visto bastantes mensajes, pero entre ellos, me han llamado la atención estos: ALSA lib pcm_equal.c:196:(_snd_pcm_equal_open) No slave configuration for equal pcm ALSA lib pcm_equal.c:196:(_snd_pcm_equal_open) No slave configuration for equal pcm ALSA lib pcm_equal.c:236:(_snd_pcm_equal_open) Problem with control file .alsaequal.bin. ALSA lib pcm_equal.c:236:(_snd_pcm_equal_open) Problem with control file .alsaequal.bin. He ido a la carpeta del usuario. y allí había un fichero llamado .alsaequal.bin Lo he tirado a la papelera y he vuelto a ejecutar audacity. Perfecto ;) Ese fichero lo cree hace varias versiones de Debian atrás para algo, pero debe ser que ya no es necesario y da problemas. Asunto arreglado :) -- www.LinuxCounter.net Registered user #558467 has 2 linux machines -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/mj0059$rdu$1...@ger.gmane.org
Re: [OT] ¿Cambian los ISP el ToS?
El Wed, 13 May 2015 18:34:24 +0200, José Miguel (sio2) escribió: El Wed, 13 de May de 2015, a las 03:55:10PM +, Camaleón dijo: ¿Has detectado algún problema o se trata sólo de simple curiosidad? Estoy investigando la calidad de servicio y voy haciendo pruebas según voy aprendiendo. De hecho, una de las cosas para las que me interesa es para que la sesiones SSH vayan fluidas a todas horas. Cuando he ido a fijar una política para los paquetes que entran en la máquina, he pensado que sería buena idea reservar un mínimo ancho de banda de bajada para el tráfico SSH interactivo y no para el que se genera con scp (que a fin de cuentas es descargar o subir fichero y no me importa si va más o menos fluido). Pero he detectado que el tráfico, aunque sale bien del cliente, siempre llega al servidor con DSCP 0x0 cuando debería llegar con DSCP 0x4 el interactivo y con DSCP 0x2 el no interactivo. Y eso me impide distinguir uno y otro tráfico. En local todo funciona bien. ¿Y desde dónde/cómo has configurado esa política de los paquetes para reservar ancho de banda? ¿Router del ISP? ¿Debian (tc)? Con FTP pasa lo mismo, aunque eso ya me importa menos. No sé si habrás pensado en usar otro sistema para la detección de ese tipo de tráfico, porque depender del proveedor no parece muy fiable. No, hombre, si ya te he dicho antes que no sabía si el cambio de ToS era normal o no por eso te dije que investigaras por otro lado más allá de pensar que los ISP no tienen nada mejor que hacer que alterar el tráfico SSH :-) Pero me dejaste una búsqueda en google en la que ningún enlace hablaba de lo que yo preguntaba o al menos así lo vi yo. Excepto el del foro de ubuntu que trataba de un bug del cliente ssh de openSSH que no le ponía el ToS correcto a los paquetes que generaba. Intentaba apuntarte a que el problema lo podía estar originando el propio paquete de SSH, que no necesariamente tenía que generarlo el operador (por manipulación) y que aún tratándose de este último caso, podía ser lo esperable. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.05.13.16.53...@gmail.com
Re: [OT] ¿Cambian los ISP el ToS?
El Wed, 13 de May de 2015, a las 07:52:17PM +0200, Raúl Alexis Betancor Santana dijo: Te voy a contar un truco ... PASA UN KILO de lo que te llega ... como ya te he dicho, no puedes controlar lo que te llega ... solo lo que TU mandas ... Si quieres prioritizar el tráfico interactivo ... sobre el no interactivo ... hazlo en el servidor QUE TE LO MANDA, como tráfico saliente. Eso ya pienso hacerlo, pero ¿es suficiente? (No he hecho aún pruebas reales). El caso es que ese tráfico SSH estaría compitiendo con bastantes clientes internos que están navegando y ciertas horas consumen bastante más ancho de bajada que de subida. Gracias. Un saludo. -- Todo el mundo se suicidaría si después de suicidarse se pudiera seguir viviendo. --- Enrique Jardiel Poncela --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513181749.ga17...@cubo.casa
Re: [OT] ¿Cambian los ISP el ToS?
El Wed, 13 de May de 2015, a las 04:53:26PM +, Camaleón dijo: ¿Y desde dónde/cómo has configurado esa política de los paquetes para reservar ancho de banda? ¿Router del ISP? ¿Debian (tc)? En la interfaz del servidor que lo comunica con el router de salida. En el esquema, la eth0: eth0 eth1 INTERNET ROUTER -- SERVIDOR --- RED INTERNA O sea, en una debian con tc. Con FTP pasa lo mismo, aunque eso ya me importa menos. No sé si habrás pensado en usar otro sistema para la detección de ese tipo de tráfico, porque depender del proveedor no parece muy fiable. Bueno, si el proveedor no se dedicara a tocar ese byte que es mío... No sé por qué narices tiene que tocarlo. De hecho, yo no lo toco: tiene ese valor, porque se lo asignan las aplicaciones dependiendo de la naturaleza del tráfico. Entiendo que no le preste atención y use sus propias estrategias para priorizar (de lo contrario, todos manipularíamos nuestros paquetepata asignarles la máxima prioridad). El problema es que a la entrada, el control se realiza antes de pasarle el paquete a netfilter, así que no puedo basarme en el seguimiento de la conexión (conntrack). Desgraciadamente el seguimiento no lo puedo hacer en el router (es un router de telefónica que no permite hacer muchas cosas). Tampoco voy a poner una máquina intermedia sólo para poder hacer el seguimiento, que es la alternativa que se me ocurre. Un saludo. -- Todos los hombres que no tienen nada importante que decir hablan a gritos. --- Enrique Jardiel Poncela --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513175046.ga15...@cubo.casa
Re: [OT] ¿Cambian los ISP el ToS?
Te voy a contar un truco ... PASA UN KILO de lo que te llega ... como ya te he dicho, no puedes controlar lo que te llega ... solo lo que TU mandas ... Si quieres prioritizar el tráfico interactivo ... sobre el no interactivo ... hazlo en el servidor QUE TE LO MANDA, como tráfico saliente. Yo, tomos mis scripts de QoS, se basan en que yo clasifico y prioritizo LO QUE ENVIO ... lo que recibo simplemente lo entrego ... o como mucho 'lo limito' ... luego ya la parte de control de congestión de TCP se encarga de el resto. Saludos - Mensaje original - De: José Miguel (sio2) sio2.sio2+lista.deb...@gmail.com Para: debian-user-spanish@lists.debian.org Enviados: Miércoles, 13 de Mayo 2015 17:34:24 Asunto: Re: [OT] ¿Cambian los ISP el ToS? El Wed, 13 de May de 2015, a las 03:55:10PM +, Camaleón dijo: ¿Has detectado algún problema o se trata sólo de simple curiosidad? Estoy investigando la calidad de servicio y voy haciendo pruebas según voy aprendiendo. De hecho, una de las cosas para las que me interesa es para que la sesiones SSH vayan fluidas a todas horas. Cuando he ido a fijar una política para los paquetes que entran en la máquina, he pensado que sería buena idea reservar un mínimo ancho de banda de bajada para el tráfico SSH interactivo y no para el que se genera con scp (que a fin de cuentas es descargar o subir fichero y no me importa si va más o menos fluido). Pero he detectado que el tráfico, aunque sale bien del cliente, siempre llega al servidor con DSCP 0x0 cuando debería llegar con DSCP 0x4 el interactivo y con DSCP 0x2 el no interactivo. Y eso me impide distinguir uno y otro tráfico. En local todo funciona bien. Con FTP pasa lo mismo, aunque eso ya me importa menos. No, hombre, si ya te he dicho antes que no sabía si el cambio de ToS era normal o no por eso te dije que investigaras por otro lado más allá de pensar que los ISP no tienen nada mejor que hacer que alterar el tráfico SSH :-) Pero me dejaste una búsqueda en google en la que ningún enlace hablaba de lo que yo preguntaba o al menos así lo vi yo. Excepto el del foro de ubuntu que trataba de un bug del cliente ssh de openSSH que no le ponía el ToS correcto a los paquetes que generaba. Saludos. -- La virtud, como el arte, hallarse suele cerca de lo difícil [...] --- Lope de Vega --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513163424.ga12...@cubo.casa -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/137781313.341613.1431539537639.javamail.zim...@dimension-virtual.com
Re: [OT] ¿Cambian los ISP el ToS?
Es que estás cometiendo varios errores de base ... 1- En el router que te hace NAT (porque supongo que lo tienes en multipuesto y el router te hace NAT), es el propio router quien SEGÚN su politica de QoS ... cambiará los valores que envía a la WAN, esto es lo más normal del mundo. 2- Los operados NO RESPETAN, los valores de QoS que tu utilices ..., no tienen porque hacerlo y de hecho, no lo hacen, ya que aplican sus propias políticas. 3- Sigue el consejo que te puse en el otro correo ... preocupate de clasificar, prioritizar y limitar LO QUE ENVIAS, lo que recibes ... no lo puedes controlar, en todo caso ... no en la eth0 ... sino en la eth1, osea ... dale la vuelta a la 'tortilla'. - Mensaje original - De: José Miguel (sio2) sio2.sio2+lista.deb...@gmail.com Para: debian-user-spanish@lists.debian.org Enviados: Miércoles, 13 de Mayo 2015 18:50:46 Asunto: Re: [OT] ¿Cambian los ISP el ToS? El Wed, 13 de May de 2015, a las 04:53:26PM +, Camaleón dijo: ¿Y desde dónde/cómo has configurado esa política de los paquetes para reservar ancho de banda? ¿Router del ISP? ¿Debian (tc)? En la interfaz del servidor que lo comunica con el router de salida. En el esquema, la eth0: eth0 eth1 INTERNET ROUTER -- SERVIDOR --- RED INTERNA O sea, en una debian con tc. Con FTP pasa lo mismo, aunque eso ya me importa menos. No sé si habrás pensado en usar otro sistema para la detección de ese tipo de tráfico, porque depender del proveedor no parece muy fiable. Bueno, si el proveedor no se dedicara a tocar ese byte que es mío... No sé por qué narices tiene que tocarlo. De hecho, yo no lo toco: tiene ese valor, porque se lo asignan las aplicaciones dependiendo de la naturaleza del tráfico. Entiendo que no le preste atención y use sus propias estrategias para priorizar (de lo contrario, todos manipularíamos nuestros paquetepata asignarles la máxima prioridad). El problema es que a la entrada, el control se realiza antes de pasarle el paquete a netfilter, así que no puedo basarme en el seguimiento de la conexión (conntrack). Desgraciadamente el seguimiento no lo puedo hacer en el router (es un router de telefónica que no permite hacer muchas cosas). Tampoco voy a poner una máquina intermedia sólo para poder hacer el seguimiento, que es la alternativa que se me ocurre. Un saludo. -- Todos los hombres que no tienen nada importante que decir hablan a gritos. --- Enrique Jardiel Poncela --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513175046.ga15...@cubo.casa -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/551967384.341620.1431539802260.javamail.zim...@dimension-virtual.com
Re: [OT] ¿Cambian los ISP el ToS?
Llevo como 9 o 10 años con el mismo script de QoS ... solo le cambio los valores de subida/bajada en función de la línea ... y 0 problemas. - Mensaje original - De: José Miguel (sio2) sio2.sio2+lista.deb...@gmail.com Para: debian-user-spanish@lists.debian.org Enviados: Miércoles, 13 de Mayo 2015 19:17:49 Asunto: Re: [OT] ¿Cambian los ISP el ToS? El Wed, 13 de May de 2015, a las 07:52:17PM +0200, Raúl Alexis Betancor Santana dijo: Te voy a contar un truco ... PASA UN KILO de lo que te llega ... como ya te he dicho, no puedes controlar lo que te llega ... solo lo que TU mandas ... Si quieres prioritizar el tráfico interactivo ... sobre el no interactivo ... hazlo en el servidor QUE TE LO MANDA, como tráfico saliente. Eso ya pienso hacerlo, pero ¿es suficiente? (No he hecho aún pruebas reales). El caso es que ese tráfico SSH estaría compitiendo con bastantes clientes internos que están navegando y ciertas horas consumen bastante más ancho de bajada que de subida. Gracias. Un saludo. -- Todo el mundo se suicidaría si después de suicidarse se pudiera seguir viviendo. --- Enrique Jardiel Poncela --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513181749.ga17...@cubo.casa -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1950108775.341645.1431540350810.javamail.zim...@dimension-virtual.com
