Hola, he conseguido acceder por SSH al Askey con el usuario 1234 pero la mayoría de comandos están capados y la salida, bloqueada.
¿Existe la posibilidad de acceder por root o mostrar la salida por pantalla de los comandos?
Theliel , sabes si se puede acceder por root o qué versión del HGU no tenía capados los comandos?
Necesito desactivar una regla del iptables que no aparece en la interfaz Web.
Hola usuario_retirado.
Te pedimos disculpas por las molestias ocasionadas y que no hayas podido realizar la configuración como deseabas porque no permitiese. Ya sabes donde nos tienes para otras consultas.
Un saludo.
Angela.
Bueno Theliel , al final he intentado configurar una cola más en QoS (veip_6) y asignar a ella el tráfico de la consola,
dejando a las 2 ultimas colas (veip_7,veip8) posteriores con mayor SP (menor peso) tráfico restante tipo IP normal desde LAN y W0/w1, pero a la que creo una regla con w1 se reinicia la interfaz web y no me deja crear la regla.
También, si creas una regla en una posición intermedia, se solapa con otras reglas (el array con Js está mal programado) y 2 reglas obtienen el mismo ID en la lista de orden. Solo se pueden poner reglas en la primera y última posición... tampoco quiero borrar las reglas QoS predefinidas.
Así que al final no uso reglas o dejo en la cola con máxima prioridad (key33) el tráfico UDP3074, tampoco es excesivo y no hace que se "mueran de hambre" el resto de colas o los paquetes DHCP y de control de la misma. El tráfico es muy bajo por el puerto 3074UDP y no noto inestabilidad...
No se puede hacer nada con este QoS por la cantidad de bugs que tiene, parece que lo han puesto así para que no toquemos nada.
Saludos
Hola usuario_retirado.
Te pedimos disculpas por las molestias ocasionadas. ¿Podrías confirmarnos si la información facilitada por Theliel (muchas gracias por tu aportación), se ha resuelto la consulta que nos planteabas, por favor?
Un saludo.
Angela.
Buenas usuario_retirado
Como te dije es todo basado en suposiciones. Para saber exactamente que está pasando sería necesario encontrar herramientas internas que permitiesen ver el tráfico que pasa por las colas y como va entrando/saliendo. Que no digo que no se pueda hacer, pero honestamente no tengo tiempo para ponerme con algo así
Todo lo que dije podría no ser así. Las reglas SIP/VoIP es totalmente diferente, son canales independientes y que si es posible Movistar tenga en cuenta por su red interna, aunque los sobreescriba al margen de que se configure, pero estoy seguro que internamente usan QoS en su red, es lógico. La regla ACS tiene en parte lógica es la conexión al servidor TR069, con lo que parte de local. Tendría todo mucho más sentido una cola para br0, pero esa no existe.
Las colas están ya creadas, lo úico que habría uqe hacer es meter diferentes reglas para que el tráfico se clasificase correctamente. el 1/SP que por defecto creo que es el 33 debería de ser la de mayor prioridad, yo no pondría ahí tráfico preferente para juegos ni para nada, lo dejaría para tráfico de control, es mucho más importante tráfico tipo ARP, DHCP, DNS... y por supuesto flags para TCP, que no pueden usarse. Además me aseguraría de tener otras colas detrás de menor prioridad y menor que la que quisieses meter entre medias, para clasificar tb la mayoría del tráfico que se pueda generar, sea web o sea del tipo que sea.
Hola Theliel , Finalmente, he dejado la cola de prioridad más alta LAN -> ppp0.1 con el puerto 3074 UDP y ToS DSCP desactivado (al igual que CoS 802.1p). Es cierto que no tiene sentido marcarlo ya que al salir, Movistar lo remarca a best effort cs0 y el sistema de colas por prioridad es lo que funciona en estos routers, aplicándose marcados en switchers/routers posteriores y en este caso, no se mantiene. Aunque es cierto que el teléfeno tiene puesto Expedited Forwarding en el apartado Voice > SIP Advanced Settings.
Por otro lado, ¿no crees que las colas LOCAL hacia ppp0.1 pueden ser para obtener IP pública desde servidores de Movistar en vez de asignar DHCP a clientes en LAN?
Aunque es cierto que es raro ya que pone el puerto 67 como origen y ese es el que usa un server DHCP...es decir, habla del DHCP del router... muy raro, luego hay una regla llamada CPU_ACS con una IP pública, que sale por la misma interfaz que CPU_DHCP. Muy raro.
| Class Name | Order | Class Intf | Ether Type | SrcMAC/ Mask | DstMAC/ Mask | SrcIP/ PrefixLength | DstIP/ PrefixLength | Proto | SrcPort | DstPort | DSCP Check | 802.1P Check | Queue Key | DSCP Mark | 802.1P Mark | Enable | Remove |
| Xbox | 1 | (interfaz)LAN | (ether type) IP | (protocolo) UDP | (puerto origen) 3074 | (queue key) 33 |
No se si crear una cola Local > ppp0.1 con puerto de destino 3074... No se si eso haría la función de "paquetes de descarga", ya que con la regla anterior solo priorizo los tiempos en cola de los paquetes de "subida".
Gracias
jaja Theliel, tendré que mirarme tu respuesta unas cuantas veces...
Lo de eth1 tienes razón, al no ser multitarea no tiene mucho sentido, pero pensaba que eth1 hacia ppp0.1(routed) se refería de LAN(eth1 puerto) a WAN (ppp0.1)..
Mirare de hacer lo que me has dicho, pero, a resumidas cuentas, ¿para priorizar el tráfico UDP 3074 hacia fuera / hacia dentro (aunque no tiene sentido ya que ya ha llegado a la interfaz) que colas crearías y a qué lo asignarías?
Este QoS da dolores de cabeza, no se entiende nada pero me basé en las especificaciones de Netcomm (ISP Australiana), que tenía varias guías de QoS con la misma interfaz para routers domésticos...
https://support.netcommwireless.com/sites/default/files/3G29Wn_QoS_Setup_guide.pdf
https://support.netcommwireless.com/sites/default/files/NB604n_QoS_SetupV2.pdf
http://media.netcomm.com.au/public/assets/file/0019/72109/NB6Plus4Wn_QoS_Setup_Guide.pdf
https://www.telechoice.com.au/uploads/nbn/NF10WV-User-Guide.pdf
Buenas usuario_retirado
Por desgracia la interfaz de estos equipos para la configuración QoS es, como la mayoría de los casos, un tanto críptica y poco... amigable.
Según lo que yo interpreto en como está concebido en este equipo QoS (Askey), estaría mal. Por supuesto a partir de aquí es todo hipotético, no lo he probado en ningún caso y es solo aplicando lógica, que no tiene por qué que ellos lo hayan hecho así.
Dicho esto...
Parece que realmente no están haciendo una gestión mediante DSCP, sino más bien por colas. Como bien dicen al principio solo se permiten 8 colas por interfaz, de mayor a menor peso, y aunque en principio se presupone que se podrían configurar colas de igual peso y aplicar Round-Robing a ellas, parece que aquí solo puede hacerse si se configuran con política estricta de 8 (8/SP). En cualquier caso, a lo que nos interesa, por defecto el Askey ya crea varias colas para ello, y las que nos interesarían realmente son las 5 colas veip0, key 33 al 37 por defecto, se podrían crear 3 colas más. Estas van a ser las encargadas en priorizar el tráfico a la hora de sacarlo por WAN, y ese es tu primer error
Has creado una/varias colas para eth1. Eso lo que haría sería priorizar tu propio tráfico en relación a otro posible tráfico que tu equipo generase, pero no lo priorizaría en lo relativo al tráfico global del Router hacia fuera. Hay mucha inconsistencia en el sistema usado y muchas incógnitas que solo podemos presuponer.
1º. Podemos escoger interfaz para crear las colas, y si bien tenemos interfaces para los dos adaptadores WIFI, tenemos 5 para Ethernet. 4 pertenecen a los puertos físicos, el 5º puede ser o la CPU o Quantenna. No podemos saberlo... internamente está claro eth0-eth3 son los puertos físicos, wl0 la interfaz WIFI de 2.4GHz y eth4 la interfaz WIFI de 5GHz. Pero aquí ya tenemos wl0 y wl1... entonces que es eth4 aquí? Podría ser redundante, o podría ser la CPU¿? Solo presuponer...
2º. No aparece la interfaz propia. Si vemos en la clasificación, el tráfico que genera el propio Router como DHCP lo mete dentro de una cola para WAN, esto no tiene ningún sentido porque DHCP es un tráfico local. Sí, está bien clasificado, es decir, se considera local, puerto etc... clasificado sí, pero se asigna a una cola que es para WAN, tendría que existir otro conjunto de colas para el tráfico interno del propio Router. ¿Podría ser ese eth4? No lo sé, lo que está claro es que en la configuración por defecto de dicho tráfico usa la misma cola WAN
3º. Como he dicho no parece que usen realmente un marcado para uso interno. Si miramos la clasificación hay dos partes, la primera hace referencia clara a las condiciones a cumplir de dicho tráfico para categorizarlo, la segunda parte como categorizarlo. Teniendo en cuenta que parece siempre hacer la gestión por cola, el marcado lo estaría usando sólo para uso propio si por ejemplo dicho paquete se envía a otro Router propio. Es decir, que realmente no nos importa el marcado, solo la cola en este caso. Si lo marcamos, el paquete saldrá en teoría marcado con los bits que especifiquemos, pero dado que va para fuera poco valor van a tener. El sistema QoS que va a funcionar para nosotros realmente va a tomar simplemente la cola.
4º. Por desgracia, la interafaz no permite especificar dentro del tráfico TCP los flags de estos, con lo que deja fuera de poder categorizar algo esencial, que son los paquetes de control.
---------------------
Teniendo en cuenta todo eso... yo crearía 3 colas más en WAN para tener de sobra, por si acaso. en la clasificación cambiaría bastantes cosas incluso de lo que viene por defecto
Las reglas CPU tienen sentido siempre y cuando el tráfico vaya a asalir. Pero no tenemos cola de prioridad para el tráfico local que va al bridge. Por eso que las dos primeras reglas, relativas a DHCP, tal como lo veo, para mi no tendrían sentido alguno. O a lo mejor internalmente el tráfico que va a LAN desde el Router es indiferente en la interfaz a la que vaya dirigida la cola, quien sabe.
Las reglas ACS son para el servidor TR069, en lo personal no tiene ningún tipo de prioridad, yo le asignaría el key que estuviese asignado al 8/SP de WAN (si se crearon 3 adicionales, sino al 5/SP)
La regla DEF imagino que quiere referirse a que cola se usará por defecto para el tráfico que no cumple las anteriores, y les da una prioridad menor, id 35 por defecto que sería 3/SP
Dentro de las reglas LAN tenemos el mismo problemas. LANPPPDISC y PPPSE, pero en ete caso ponen como interfaz de origen LAN, es decir, darían prioridad a clientes PPPoE conectados al Router, no el del propio Router, y en este caso es correcto sacarla por la cola WAN.
Las dos reglas finales dan un peso medio al resto de tráfico IP.
Configurar bien QoS aquí sería tedioso.
1º. Tendríamos que saber realmente que cola es la que hay que establecer para el tráfico cuyo destino sea el propio bridge, no se especifica. Movistar usa en la clasificación PPPoE (WAN), pero esto no tiene a priori sentido.
2º. Aclarado eso, el tráfico que más prioridad debería de tener es siempr eel tráfico de control, paquetes PPPoE (pero del router, no de LAN, interfaz local), DHCP, ARP... pero como ya he dicho no sabemos la cola que se usa para br0, y tampoco podemos especificar los paquetes de control TCP , lo máximo que poedmos configurar es el tipo de protocolo, nada más. Por ejemplo 1/SP
3º. Después crearía otras con lo que realmente queremos priorizar, la tuya a lo mejor de la consola, siempre en una cola con menos peso (mayor SP) que las anteriores, si los paquetes de control no tienen máxima prioridad, da igual la prioridad que tengan los paquetes UDP/TCP que mandas, y se puede ademas causar problemas de estabilidad. Digamos que 2/SP
4º. Crearía luego otra para tráfico general que no esté incluido en las otras dos, y a lo mejor asignarle 3/SP
5º. No es posible especificar como dios manda el tráfico por servicio. Se puede por puerto, pero no en función de que tipo de carga. Si se permitiese podría especificar que a partir de unos 5Mbps por ejemplo en tráfico HTTPs/HTTP se degradase a otra cola. Aqi no se puede, así que de forma patatera se podría crear una clasificación a puerto 80/443 con menos peso (mayor SP) que las anterioes, asumiendo que la mayoría de descarga se harán por protocolos Webs y evitaría interrupciones de estos, aplicando menor prioridad a estos (mayor SP), me facilitaría el resto, por ejemplo 4/SP. En este caso el tráfico que no fuese HTTP tendría más prioridad, y dejaría el tráfico HTTP por debajo, lo que incluiría las descargas, YT y otros.
-----------
Se podría crear una cola delimitante y meter en ella tráfico que nos quisiésemos asegurar que no supersae cierto umbral...
El marcado aquí como digo no parece que tenga la mayor importancia a menos que el tráfico fuese enviado a un nodo/Router/Switch que si lo clasificase en función de su marcado. Pero a como lo gestiona el Router, es lo de menos.
Tampoco veo positivo marcar 802.1p, puede confundir cuando lo meta en el ramal de la VLAN6. Las cosas están para que funcionen ya bien, es como intentar engañar a un sistema para supuestamente querer mejorarlo. Ya fue diseñado para ser bueno, y dudo enormemente que ninguno de los presentes sepa más que los crearon el estándar y las recomendaciones :), el tráfico "de fondo" que llamamos, lo normal y la recomendación siempre es 802.1p = 1, que es lo que usa Movistar por defecto para su VLAN 6. Además es muy posible que al cruzar el tráfico por WAN lo vuelva a configurar a 1
----------------
Todo esto como digo siempre teniendo en cuenta que es aplicando la lógica y lo que se puede ver. Realmente la firmware podría estar haciendo por detrás lo que le diese la real gana.
Las colas Eth1 por otro lado podrían tener igualmente importancia, pero para tu propio tráfico. Es decir, configurar las colas que afectaría al tráfico que escupe tu dispositivo. Esto en consolas no es que tenga mucho sentido porque por lo general no son equipos multitarea... es decir no vas a estar descargando sin parar con la consola mientras que estás jugando ymientras que ves un vídeo... todo ello desde, repito, la misma consola. En un PC si podría tener más uso, por ejemplo relegar el tráfico P2P a favor del tráfico HTTP (por ejemplo).
Theliel ya aparecen las fotos, ¿ podríamos decirme si la regla parece a priori estar bien configurada?
Saludos
