Ya lo tengo configurado :) Muchisimas gracias. Esta noche probaré el consumo de energía sobre WIFI.
Algunas dudas que me surgen...
- El APSD se lo he puesto en los 4 SSID no solo en el principal y el WMM igual, en los 3 secundarios no existia la entrada WMM y la he creado, ¿es así o no había que ponerlo en los secundarios?
- ¿Hay que tener habilitado el QoS para que funcione el WMM y el APSD? Lo digo porque al ser el WMM una forma de QoS, no se si lo deshabilito si tengo el QoS quitado y prefiero no tener el QoS.
Alguna cosa sobra la configuración avanzada del router...
- Al configurar el interfaz WAN, en avanzadas "RIP & MULTICAST SETUP" se puede poner la versión RIP en 1 o en 2, por defecto viene en 1, ¿no sería mejor ponerla en RIP2?
- En la misma configuración se puede configurar el IPv6/4 Dual Stack, viene en v4+v6, ya que de momento solo usamos v4, no sería lo suyo ponerlo en IPv4 en lugar de los dos?
- En la LAN, lo mismo, viene por defecto RIP1, lo he puesto en RIP2, ¿algún problema a la vista con eso?
¡¡Gracias de nuevo!!
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.
Otra cosa, en el log desde siempre se ve esto:
26 Jan 1 00:00:41 WARNING Couldn't increase MTU to 1500.
27 Jan 1 00:00:41 ERROR Couldn't increase MRU to 1500
Movistar usa un MTU de 1480, yo en Windows al interfaz de red ya se lo he puesto a 1480, pero no veo que se pueda asignar al interfaz WAN un MTU en el router (por web), sin embargo a voz y tele si se les puede decir el MTU.
Por cierto, que para voz y tele pone un MTU de 1492, ¿como podemos saber el MTU que usa Movistar en esos dos interfaces? Porque si estuviese usando para esos dos 1480 como en el caso de la WAN, estaría fragmentando todos los paquetes de voz y tele y sería mejor ponerlo en 1480, ¿no?
Y sobre la cuenta supervisor, en el cfg del router B23 aparece esto:
Parece que existen las cuentas 1234, admin y supervisor y que supervisor es la que mas acceso tiene, ya que en el display mask tiene todo a F, mientras que 1234 tiene el primer camp del display mask a 0. Eso ya estaba así en las versiones anteriores, ¿se sabe cual era la diferencia entre 1234 y supervisor?
En la B14 ya cambie la máscara de la cuenta 1234 a todo F y no vi diferencia a primera vista.
