RTF8316VW - Monopuesto - RIP - Sin Rutas?
Recientemente contraté Fibra de 10G Ayer llegó el router e intenté configurarlo para mi entorno. En el router anterior tengo la siguiente configuración: 1. IP Address 192.168.3.1 (sí, la lan entr...
Foro
Hola, contesto varias cosas:
Alexander:
NO, el router NO se ha actualizado a pesar de estar conectado durante más de 18 horas seguidas. En el menú de actualizar solo admite un archivo. no permite "comprobar actualizaciones" ni ninguna otra funcionalidad. Si existiera una verificación periódica me imagino que ha baría saltado pero no ha pasado porque sigo con la V16.
Theliel:
He conseguido acceder bastante al funcionamiento interno del router entrando por ssh y, obviamente, con ayuda de la IA. He encontrado algo que quizá te resulte interesante.
El firmware sigue siendo:
GL_g1.16_R8316_V2.16
Internamente sigue teniendo un subsistema RTM y ejecuta rtmd y dos procesos ripd. Las interfaces IP que expone RTM son:
ip1 -> rbr4.0 -> LAN
ip2 -> ppp0 -> Internet / VLAN 6
ip3 -> rbr2.2 -> VoIP / VLAN 3
ip4 -> rbr3.3 -> IPTV / VLAN 2La GUI avanzada tiene una página RIP que llama a:
/cgi-bin/cbGetRipIntf.xml
/cgi-bin/cbSetRipIntf.xmly la configuración RIP actual que devuelve el backend es:
rip_intf_id=0 ip_intf_id=2 adm_state=0 accept_ra=1 send_ra=0
rip_intf_id=1 ip_intf_id=3 adm_state=1 accept_ra=1 send_ra=1
rip_intf_id=2 ip_intf_id=4 adm_state=1 accept_ra=1 send_ra=1(como ves, yo ya he añadido send_ra=1, pero como verás más adelante creo que esto no sirve para nada)
ip_intf_id=1 (ip1 / rbr4.0, LAN) no tiene ninguna entrada en la tabla RIP.
Los dos ripd que están ejecutándose son:
ripd 1 1 1 3 0 3
ripd 1 1 2 4 0 3lo que además parece correlacionar los argumentos con rip_intf_id=1/ip_intf_id=3 y rip_intf_id=2/ip_intf_id=4.
El backend acepta el cambio y queda persistido cuando lo hago vía javascript en la consola del navegador, pero naturalmente sigo sin recibir RIP en la LAN.
El router tiene además estos ficheros internos:
/tmp/config/rtm_cfg_igd.1.rip_intf.conf
/tmp/config/rtm_cfg_igd.1.rt.conf
/tmp/config/rtm_cfg_igd.1.ip_intf.confy sus correspondientes defaults en /tmp/defcfg.
El primero mide sólo 340 bytes y contiene presumiblemente esos tres registros RIP.
Pienso que para que el RTF8316VW intercambie RIP con el router neutro habría que crear una cuarta entrada rtm_cfg_rip_intf asociada a ip_intf_id=1 (ip1/rbr4.0), en lugar de limitarse a activar send_ra en las interfaces WAN.
La API web de Askey parece bastante genérica. Por ejemplo, para las rutas estáticas utiliza el mismo cbSetRoutingV4Rule.xml tanto para crear/modificar como para borrar (del=DEL). Sin embargo, rip.js sólo permite modificar los tres registros RIP existentes y no ofrece Add/Delete.
¿Sabes si existe alguna forma conocida de crear una entrada rtm_cfg_rip_intf para la LAN, ya sea mediante RTM, rtm_util, algún CGI no expuesto por la GUI o la CLI interna?
Muchas gracias,
Ignacio
Buenas IgnacioHR
Es indiferente, da exactamente igual que añadieses una entrada nueva configurada para el bridge principal que en cualquier caso es "sencillo". Eso no solucionaría nada, en la interfaz WAN Internet (VLAN6) no hay anuncio de rutas, con lo que da igual levantar RIP en ella, no tendría ningún efecto.
El problema de base es que quagga está compilado sin la versión llamemos nativa de ripd, y la implementación casera aunque en principio maneja la distribución no parece tener impacto alguno. El demonio parece ser "monointerfaz", no existe un único demonio configurado para escuchar en diferentes interfaces y poder distribuirlas, sino que se ancla a una de ellas y escucha sus rutas. Funcionará bien si permitiese efectivamente a su vez emitirlas, pero no parece que lo haga. Vamos, que básicamente compilaron la suite completa sin ripd, luego cogieron el código fuente de ripd, cambiaron el main y toquetearon 3 cosas y arreando.
La solución real pasa porque lo solucionen... en teoría el binario está pensado para hacerlo, en teoría repito... no sé cual será sus ideas.... de todos modos luego pruebo una cosilla que se me ha ocurrido... si te digo que tampoco es raro que no funcionen, es parte de código que están tocando constantemente y mucho.
Soluciones siempre hay, más imaginativas y menos, pero todas chocan con lo mismo. Si uno quiere una solución robusta, implica no tocar el HGU en nada, por defecto todo y monopuesto, y en todo caso como dices cambiar un ajuste o dos en la interfaz web. Todo lo que salga de ahí se corre el peligro de que cualquier actualización lo rompa.... y sí, es importante que esté siempre actualizado el HGU, aun en monopuesto
Saludos.
Ya se actualizó a la versión 19.
Como decías, en monopuesto no se actualiza. Después de un reset conectado a la fibra se actualizó solo.
Si uno quiere una solución robusta, implica no tocar el HGU en nada, por defecto todo y monopuesto, y en todo caso como dices cambiar un ajuste o dos en la interfaz web. Todo lo que salga de ahí se corre el peligro de que cualquier actualización lo rompa.... y sí, es importante que esté siempre actualizado el HGU, aun en monopuesto
No puedo estar más de acuerdo contigo en esto y espero que sea así lo antes posible. De hecho yo asumía que sería así cuando lo solicité. Llevamos muchos años usando estas configuraciones y deberían estar ya aprendidas por todos.
Espero a ver si se te ocurre alguna solución temporal mientras tanto.
Muchas gracias quedo atento a las novedades y dejo el tema abierto hasta que haya una versión en la que funcione la configuración monopuesto para poder usar IPTV y VOIP.
Saludos
Ignacio
Hola, IgnacioHR
No me olvido de tu caso, continuo a la espera de las revisiones por parte del área técnica, para que el pedido del router se complete. En cuanto me registre información, te lo estaré comunicando.Un saludo,
Rocio.
