excustomer por ahora no he podido reproducir lo que cuentas de ningún modo desde Debian, voy a ver si soy capaz de reproducirlo desde Windows... igual es una cosa de la b21 o del apdatador WIFI tuyo??
-en realidad el que impota es el principal, los otros serán por si usas otros SSID invitados pero vamos...
-No, QoS es totalmente independiente
-RIP sólo se usa en VoIP para caparas las rutas que emite Movistar, en la interfaz internet no se usa. Por lo general protocolos más avanzados tienen mayor sobrecarga, así qeu a menos uqe Movistar necesite enviar las rutas por RIPv2, cosa que dudo, le sobra RIP1. No importa como lo pongas tú. Importaría si ellos las mandan en RIPv2 y tu tienes puesto Ripv1, entonces sí, pero al reves importa poco. A nivel de protocolo, RIPv2 tiene funciones que no tiene Ripv1, quizás la más improtante es que es mucho más eficiente a la hora de enviar las rutas a muchos clientes. pero en cualqueir caso repito si Movistar no lo usa... actualmente no sé como las manda Movistar, pero presupongo que en Ripv1 viendo lo visto
-Efectivamente, puedes poner sin problema sólo IPv4, y deshabilitar incluso en la itnerfaz web el soporte IPv6 de LAN
Yo también pensaba en principio que podría ser debido a algún problema con el Linux (Ubuntu 15.10 con una interfaz wireless tal cual se muestra a continuación), pero hete aquí que también me pasa con el Windows 7, aunque la verdad, parece que con algo menos de severidad:
"""
04:00.0 Network controller: Qualcomm Atheros AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
Subsystem: Lite-On Communications Inc Device 6661
...
Kernel driver in use: ath9k
"""
Ahora mismo estoy redactando el mensaje y la comunicación entre el PC y el resto del mundo va como le da la gana. El HTTP funciona a veces, los PING tirados a uno de los servidores de Movistar, funciona la mayoría de las veces, en cuanto subes un poco el tamaño de paquete casi nunca funciona (aunque no se puede descartar que me tire el tráfico Movistar):
"""
$ ping 80.58.61.254
PING 80.58.61.254 (80.58.61.254) 56(84) bytes of data.
64 bytes from 80.58.61.254: icmp_seq=1 ttl=250 time=5.86 ms
64 bytes from 80.58.61.254: icmp_seq=2 ttl=250 time=5.71 ms
64 bytes from 80.58.61.254: icmp_seq=3 ttl=250 time=6.05 ms
64 bytes from 80.58.61.254: icmp_seq=4 ttl=250 time=6.56 ms
64 bytes from 80.58.61.254: icmp_seq=5 ttl=250 time=5.60 ms
64 bytes from 80.58.61.254: icmp_seq=6 ttl=250 time=6.33 ms
64 bytes from 80.58.61.254: icmp_seq=7 ttl=250 time=31.9 ms
64 bytes from 80.58.61.254: icmp_seq=8 ttl=250 time=5.65 ms
64 bytes from 80.58.61.254: icmp_seq=9 ttl=250 time=5.98 ms
64 bytes from 80.58.61.254: icmp_seq=10 ttl=250 time=6.15 ms
$ ping -s 500 80.58.61.254
PING 80.58.61.254 (80.58.61.254) 500(528) bytes of data.
508 bytes from 80.58.61.254: icmp_seq=10 ttl=250 time=8.04 ms
508 bytes from 80.58.61.254: icmp_seq=11 ttl=250 time=14.2 ms
508 bytes from 80.58.61.254: icmp_seq=24 ttl=250 time=6.50 ms
508 bytes from 80.58.61.254: icmp_seq=25 ttl=250 time=7.24 ms
508 bytes from 80.58.61.254: icmp_seq=26 ttl=250 time=7.22 ms
508 bytes from 80.58.61.254: icmp_seq=28 ttl=250 time=7.44 ms
508 bytes from 80.58.61.254: icmp_seq=29 ttl=250 time=13.0 ms
508 bytes from 80.58.61.254: icmp_seq=34 ttl=250 time=7.98 ms
508 bytes from 80.58.61.254: icmp_seq=42 ttl=250 time=6.78 ms
508 bytes from 80.58.61.254: icmp_seq=44 ttl=250 time=7.07 ms
508 bytes from 80.58.61.254: icmp_seq=45 ttl=250 time=7.34 ms
"""
En este rato, la interfaz wireless en el lado del Linux no da errores a nivel 2, como tampoco se ven en los log desconexiones a nivel físico, ni nada que indique algo parecido. Y la semana pasada nada más traerme el router Alejandrita no me decía que hubiera ninguna versión más reciente.
Sigo investigando yo también , aunque el nivel de Theliel deja a cualquiera a la altura del betún
Y no se vayan todavía, que aún hay más . Como haciendo las pruebas anteriores llegó un punto que no iba de ninguna de las maneras, desactivo la interfaz wireless, pincho el cable de red, levanto la interfaz física, lanzo el cliente DHCP...y ni pa Dios.
Me pongo a mirar las estadísticas a nivel físico y veo que cuenta tanto tráfico de entrada como de salida, sin colisiones, dropped, ni similares. No me fío, me pongo a capturar, y veo que entre por el cable toda la morralla de este mundo y del de al lado. Pero de salida, veo el BOOTP saliente al broadcast, y no responde ni Perry.
Digo, a ver si va a ser el lado del Linux, bajo interfaz, elimino el módulo del kernel, lo cargo otra vez, repito ip up, dhcpcd y seguimos en las mismas, en un arrebato de desesperación "bypaseo" el switch y conecto directamente al Mitrastar con el cable físico sin switch intermedio, y que si quieres arroz Catalina.
Sólo el proverbial acto de reiniciar el PC Linux del todo ha solucionado el problema, lo que a cualquiera daría a pensar que es el Linux, pero es que al menos la parte de la WiFi me pasa lo mismo, siquiera menos exagerado, con Windows, y con Windows sólo tengo tráfico VPN IPsec al trabajo (es decir, sólo una conexión, pues todo va tunelado al concentrador de la empresa), y aún así mientras que he estado usando la wireless para el trabajo los síntomas eras muy parecidos, aunque no tan severos.
¿Qué será será? Ni la más remota idea.
Tass1234 es posible que algún ISP en su día usase otro MTU para sus conexiones, a saber... es cierto que se hizo famoso el 1480 como si fuese el MTU maximo PPPoE, pero creo que era por una cuestión de Windows que para el cliente PPPoE de el antiguamente era su MTU, pero no me hagas caso, de eso hace ya mucho tiempo y a saber. Sea como sea, el estádar PPPoE a día de hoy dicta que el MTU máximo es de 1492, por la sencilla razón de que requeire 8 Bytes,
Sobre establecerlo en Windows el MTU), tampoco es necesario, la negociación del MSS (El tamaño máximo de segmento), se realiza del siguiente modo, tal como funciona una conexión básica TCP:
1º. SYN
Tu PC lo primero que hace es mandar un paquete TCP SYN a la dirección que sea, Este paquete no lleva información propiamente dicha, sino que es un paquete para informar al servidor de que se requiere una conexión, y lo que adjunta es información de control, entre otras cosas: el MSS soportado, si hay escalado de ventana, si se permite SACK, timestamp... en fin, básicamente le informa al servidor con que pude trabajar él. Pero ten en cuenta que el cliente aun no sabe absolutamente nada del servidor.
2º. SYN-ACK
Es la respuesta del servidor al SYN del cliente, básicamente es un mensaje de conformidad. Con el SYN del cliente el servidor ya sabe como comunicarse con el cliente porque tiene sus datos en el SYN, así que usa el SYN-ACK para contestar al cliente primero que se ha enterado, y segundo configura la configuración en función de las capacidades del cliente, siempre evidentemente igual o más laxas.
3º. ACK
Si todo es correcto, el cliente debe de responder con un ACK al SYN-ACK del servidor. Aquí ya no le manda opciones de configuración de nada, el cliente se las mando en el 1º paso, el servidor respondio con las suyas a sabiendas de las que le había mandado el cliente en el paso 1º, con lo que ahora el cliente sólo tiene que responder con un ACK simple a modo de: "todo listo".
-------------------------------
Podrías pensar que tu PC envía siempre a 1500 hacia fuera, pero no es cierto, el Router no tiene que ensamblar nada porque tu PC manda todo con un MTU de 1492... un MSS de 1452 (Bytes menos). Por qué??? Es un tructo genial....
Tu PC hace el SYN con el servidor X, y evidentemente el SYN que manda es para un MSS de 1460 (1500 MTU) porque Windows está preconfigurado así. Pero el paquete es modificado por el Router, como ves la regla en el Firewall modifica todos los paquetes SYN y RST SYN y les cambia el MSS a 1452. Ese paquete no se tiene que reensamblar es un paquete muy chico... y el Router manda el paquete SYN ya modificado con un MSS de 1452 en vez de 1460 al servidor de destino. El servidor de destino dice, ei!! quieren conectarse conmigo con un MSS de 1452... así que respondo al cliente con un SYN-ACK en el que especifico evidentemente un MSS de 1452, porque es el el MSS que me ha llegado. A tu PC llega un paquete SYN-ACK que dice que quiere la conexión a un MSS de 1452!! Tu PC dice, bueno, yo puedo enviarlos a 1460 (MTU 1500), pero el servidor manda, si el los quiere a 1452 yo los mando a 1452....
Al final, tu PC en la conexión TCP no usa por tanto los 1500, usa 1492. El único paquete que manda con MSS de 1460 y que da igual porque el paquete es minúsculo, es el SYN inicial de cada conexión. A partir de ese.... da igual!!
excustomer dices que estás conectando a través de un Switch?? Eso podría explicar los problemas por cable, sobre todo si tienes tele contratada y la tienes conectada al mismo Switch, y este no tiene habilitado IGMP Snooping
De todos modos como te digo al menos en la B23 no he podido reproducirlo de ningun modo, ni Debian 8, ni Windows XP ni 10. Entra en Alejandra y mira a ver si pudes meterle la B23, y puedes probar de nuevo. Si aun así nanai, empezaría a pensar seriamente una limitación o problema raro del adaptador WIFI de algun tipo. Yo estoy probando con dos diferentes un Ralink RT3072 y una Broadcom BCM4352, y no noto en principio nada raro. Latencia y Jittler normal, navegación normal, telnet normal...
Podría ser a lo mejor también interferencias. Estamos dando po echo que la conexión es buena, pero WIFI ya sabemos como es, podrías estar teniendo colisiones a nivel WIFI, es cierto que yo en casa interferencias tengo poquitas.
Por descontado no digo que no tengas algo raro ahí, digo sólo que no soy capaz de reproducirlo... el problema del IGMP tardamos un tiempo en descubrirlo proque yo no tengo TV contratada y no podía ver nada [....], fue gracias a otros compañeros y de analizar su scapturas para ver lo que pasaba. Así que... por eso, a ver si puedes probar con otro adaptador u otro equipo directamente, al margen de actualizar a la b23, que ya te digo que todas estas pruebas las hago sobre esta, no sobre la b21
