MitraStar GPT-2541GNAC problemas y rutas

Highlighted
MitraStar GPT-2541GNAC problemas y rutas

Me he dado cuenta de que estando encendido el HGU, si desconectas el cable ethernet y lo vuelves a conectar la conexion se degrada hasta por debajo de 1Mb asi que mirando por telne la configuracion me ecnuentro con esto (he variado las macs y algunas IPs para evitar dar mas info de la necesaria):

 

> route show
Kernel IP routing table
Destination           Gateway               Genmask                Flags     Metric  Ref   Use    Iface
default                  *                            0.0.0.0                    U            0          0      0         ppp0.1
1.1.1.0                 *                             255.255.255.0        U            0          0      0         br0
10.yy.yy.0             *                            255.255.192.0        U            0          0      0         veip0.2
10.xx.xx.xx           10.yy.yy.1              255.255.255.255    UGH      0          0      0         veip0.2
10.xx.xx.xx           10.yy.yy.1              255.255.255.224    UG         3          0      0         veip0.2
192.168.1.0          *                            255.255.255.0        U            0          0      0         br0
192.168.116.141  10.yy.yy.1              255.255.255.255    UGH       0          0      0         veip0.2
192.168.144.1      *                            255.255.255.255    UH          0          0      0         ppp0.1


> arp show

IP address     HW type Flags HW address Mask Device Ethernet interface VLAN ID
1.1.1.2 0x1 0x2 00:26:86:00:00:00 * br0
192.168.1.29 0x1 0x2 aa:bb:cc:dd:ee:ff * br0 LAN2 0
10.28.192.1 0x1 0x2 aa:bb:cc:dd:ee:ff * veip0.2


> ifconfig br0:9
br0:9 Link encap:Ethernet HWaddr aa:bb:cc:dd:ee:ff
inet addr:1.1.1.1 Bcast:1.1.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1

 

 

Lo que quiero preguntar es a que dispositivos pertenecen esas ips que pongo en rojo. 

 

La ip 1.1.1.1 aparece configurada como br0:9 haciendo un ifconfig.

 

La ip 1.1.1.2 no aparece dentro de la HGU haciendo un ifconfig y mi ordenador que es el unico que esta conectado, tampoco muestra esa ip configurada. Tanto la 1.1.1.1 como la ip 1.1.1.2 responden a pings.

 

La ip 192.168.141.1 tampoco entiendo que hace configurada dentro del HGU, no responde pings siquiera.

 

Por otro lado tambien me llama la atencion una ip que aparece en la trazada dentro del enrutado del VOIP, la 192.168.116.141, esta ruta no estaba al principio de tener Fibra con este HGU, esta ip tampoco responde pings.....

 

 

¿Alguien que pueda aportar información y que me explique que significan y a que corresponden esas ips y rutas?

 

Gracias.

Mensaje 1 de 16
1.761 Visitas
15 RESPUESTAS 15
Highlighted

Buenas @Jesus.H.

 

Todas están por algo:

 

1.1.1.1 y 1.1.1.2, aunque son IPs que se puden rutear hacia el exterior porque son de echo IPs válidas, el Router las usa para comunicarse internamente con el adaptador WIFI de 5GHz Quantena, siendo el SoC principal creo recordar el 1.1.1.1 y el Quantena el 1.1.1.2. En mi opinión deberían usar otras y usar intervalos privados, pero bueno... no vamos a entrar en ello.

 

La 192.168.144.1 es la IP punto-a-punto, puedes verla algo así como la pureta de enlace del servidor PPPoE de Movistar, y la otra relativa a los servicios de VoIP, mira las interfaces de cada una.

 

Las IPs no tienen por qué responder a pings aquí eso no sirve para nada.


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 2 de 16
1.744 Visitas
Highlighted

Theliel escribió:

Buenas @Jesus.H.

 

Todas están por algo:

 

1.1.1.1 y 1.1.1.2, aunque son IPs que se puden rutear hacia el exterior porque son de echo IPs válidas, el Router las usa para comunicarse internamente con el adaptador WIFI de 5GHz Quantena, siendo el SoC principal creo recordar el 1.1.1.1 y el Quantena el 1.1.1.2. En mi opinión deberían usar otras y usar intervalos privados, pero bueno... no vamos a entrar en ello.

 

La 192.168.144.1 es la IP punto-a-punto, puedes verla algo así como la pureta de enlace del servidor PPPoE de Movistar, y la otra relativa a los servicios de VoIP, mira las interfaces de cada una.

 

Las IPs no tienen por qué responder a pings aquí eso no sirve para nada.

 

 

 

¿Y como es que la ip 1.1.1.2 no aparece haciendo un ifconfig? si las wifis están desactivadas ¿en que momento se crean las ips y con que comandos en telnet se puede comprobar la creacion de las mismas...con wlan5? la ip 1.1.1.1 si que aparece configurada como br0:9 como ya he comentado, pero ni rastro de la 1.1.1.2 a pesar de estar "levantada".

 

Sobre las puertas de enlace... no aparecían los primeros días que contraté Movistar fibra y todo funcionaba correctamente, han aparecido después, las puertas de enlace por ejemplo para la VoIP eran del rango 10.x.x.x no con ese rango 192.168.116.141. De la misma manera que cuando contrate la fibra hace 15 dias, si resetabas el HGU a los valores de fabrica solo se iniciaba la wifi normal de 2.4Ghz y hoy si lo reseteo este al iniciarse levanta las dos wifis a la vez....¿como es esto posible si la versión del firmware es la misma que hace 15 días? ¿algun técnico envia alguna archivo de configuración que se carga por medio de TR-069 o SNMP? o han creado un cambio en la NVRam del cacharro.... 

 

¿sobre el que la conexión se degrade si desconectas y vuelves a conectar un cable ethernet al HGU? algo raro y que seguro que tiene que ver con DHCP y con el enrutado, solo consigo solucionarlo si reinicio el HGU y es que tengo uno de los conectores del cable con la pestañita rota y se suelta al minimo movimiento.

 

Se me olvido comentar también otro problema que no deja ver el log del sistema de manera correcta y es un flodeo de mensajes de este tipo :

 

radvd[1188]: received RA from fe80::aabb:ccdd:eeff:6223

 

que creo que es de IPV6 y The Router Advertisement Daemon (RaDvd) que no se como evitar que aparezca en los logs y que creo que estan siendo generados por mi pc, ¿alguna idea de como evitar que aparezcan en los logs del HGU?

 

Y ya para terminar, con estos HGU y la fibra óptica, ¿se puede tener ya una Ip version 6 a nivel WAN?

 

Gracias Theliel por tu información, ¿para cuando un articulo en tu blog sobre este HGU? 😉

 

Mensaje 3 de 16
1.723 Visitas
Highlighted

Buenas @Jesus.H.

 

La IP cliente/servidor que interacciona con el Quantenna está codificada a nivel de firmware en ambas partes... por un lado en el mismo Quantena se especifica la IP que posee, y el Router se configura para poder conectarse a él. Imagina el Quantena como otro pequeño router, por así decirlo... este en cambio tiene una memoria Flash mínima... sin ser estrictamente exacto, así es como funciona el quantena:

 

1. Arranca el Router...

2. Alimenta el Quantena, este posee un prebootloader mínimo que básicamente todo lo que hace es crear una conexión TFTP a esperar el resto

3. El Router carga por TFTP el bootloader completo al Quantena, y acto seguido manda la firmware a este. Todo ello se hace a través de las IPs ya citadas.

4. El quantena se termina de arrancar, un sistema linux estandar en miniatura, configura la interfaz wifi bla bla bla... incluso tiene su propio configurador Web que con un poco de ingenio se puede acceder a él, en algún post perdido de aquí lo puse... creo.

5. A partir de aquí, el Router y el quantena se comunican a través del protocolo portmap, y sí... usando las IPs citadas. No tengo claro si usan un portmap estandar o no, imagino que sí...

 

La puerta de enlace 192.168.144.1 es inherente prácticamente a cualquier conexión PPPoE de Movistar, es la IP punto-a-punto de este protocolo. Al realizar el marcado PPPoE, este envía una petición de configuración a la red (en broadcast, sin destino dado que no conoce un destino, solo ttiene la interfaz por donde mandarlo) de Movistar... sus servidores PPPoE que están a la escucha lo reciben y envían de vuetta los parámetros y realizan la conexión. Entre esos parámetros, los primeros que envía el servidor PPPoE es la IP llamada punto-a-punto, que sería algo así como la IP de enlace del servidor PPPoE... es decir, a quien se tiene que dirigir el Router para configurarse... ese mismo servidor, después de todas las comprobaciones y otros le asignará además su IP de interfaz, que será la IP pública que tendrá el Router. Es decir... interpreta si quieres la IP dicha como la IP del servidor PPPoE, por así decirlo. Es una IP privada, no se enruta hacia fuera.

 

La otra IP, la 192.168.116.141, podría ser incluso, no tengo ahora mismo el mitrastar, una IP alias, mirar en ajustes y configuración avanzada del Router, hay una establecida, es posible que sea la misma 🙂

 

Los Routers usan RIP, y reciben de los servidores de Movistar actualizaciones de rutas si es necesario, esto es fundamental, garcias a esto funciona correctamente voIP o TV. No necesitan actualizar la configuración ni tocar ajustes a mano, las rutas se publican cada X y el Router las actualiza si es necesario, eso sin contar que evidentemente pueden hacer lo que quieran por TR069 o directamente por acceso remoto, tienen el usuario telefonica/telefonica para ello.

 

Por último, el mensaje de radvd.... se debe a que la versión de radvd que tiene el router no tiene parcheado un pequeño bug de este, que trata ciertos mensajes de información con más prioridad. Los puedes ignorar completamente, aunque sé que son una molestia son solo informativos... como digo fue un bug que se cometió hace algún tiempo y fue corregido, y el fix fue simple... sólo fue cambiar la prioridad de los mensajes de información para que se logeasen o no. Lo puedes ignorar, aunque sí, es muy muy molesto tener el log inundado de ellos. Te diría que quitases radvd, pero la última vez uqe lo intenté, no dejaba.

 

IPv6... muchas centralitas de Movistar están pre-preparadas, de echo he logrado sin problerma la asignación de IPv6 para la interfaz WAN, pero no usable de ningún modo, ahora mismo olvídate... mañana quien sabrá...

 

Y sobre la degradación... en el tiempo que lo tuve... no observé ningun problema similar, así que debe de ser en todo caso de compatibilidad o un efecto colateral de algo. Podría ser una sobresaturación de conexione que cree el equipo que se conecta por cable o cualquier historia rara... te pasa con otros equipos o solo con uno??

 

(En realidad ya exprimí y "reventé" al máximo el HGU Mitrastar en su día, por desgracia ahora estoy con el ASKEY y con menos tiempo, y con muchas cosas pendientes que irían primero... quizás algún día)

 

 


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 4 de 16
1.699 Visitas
Highlighted

Todo entendido, menos lo de la ip esa 192.168.116.141, recuerda que es una puerta de enlace de Voip no una Ip alias de la Lan asi que no se por donde entra dicha ruta...quizas lo que tu dices de el RIP...¿pero desde cuando Movistar usa ese rango de IPs para VoIP?.

 

Sobre lo de la degradación de la conexión ocurre con cualquier dispositivo, en este caso he probado con portatil y pc y las dos veces ocurre lo mismo, si en el momento de encender el HGU estan conectados no hay problema, pero como conecte o se desconecte y lo vuelva a conectar las medidiciones bajan a niveles irrisorios, por eso pensaba que era un problema de DHCP.

 

sobre esto: 

 

"""(En realidad ya exprimí y "reventé" al máximo el HGU Mitrastar en su día, por desgracia ahora estoy con el ASKEY y con menos tiempo, y con muchas cosas pendientes que irían primero... quizás algún día)""" 

 

creo que te equivocas de Mitrastar, el que exprimiste era el otro HGW-2501GN-R2 , el que no tiene ONT integrada, sobre el que estamos hablando es el cuadradito GPT-2541GNAC. 

 

¿como busco el configurador Web del Quantena? para buscar el porque aunque esten desactivados el Wifi y el Wifi Plus se levantan las interfaces...puede que tenga que ver por el tema de enrutamiento pero el caso es cacharrear y entender como funciona.

 

 

Mensaje 5 de 16
1.683 Visitas
Highlighted

Como te digo, no lo tengo ya por aquí, asi que... pero vamos, es una IP privada, ni te preocupes

 

Sobre lo otro... pueden ser muchas cosas, desde un dispositivo que esté mal interaccionando... a saber

 

Sobre el Mitrastar.. me refiero al HGU, el otro tambien lo destrocé... metaforicamente hablando, el HGW aun funciona como un campeon!!. El GPT murió de un día para otro, por los síntomas, voló los circuitos de alimentancion, pero a saber... así que ASKEY. Son muy similares, los de ASKEY son quizás mas metódicos y más seguros, el hardware es el mismo prácticamente, En cualquier caso tuve tiempo más que de sobra para exprimirlo todo y más.

 

No te compensa ni te interesa entrar en la configuración del Quantenna, además un mal ajuste y puedes bloquearlo del todo, piensa que esos cambios son los pocos que quedan en el prebootloader de este, no es recomendable, nada recomendable. Pero sí, se puede, así como saltar a la Shell del quantenna también.


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 6 de 16
1.678 Visitas
Highlighted

"""En cualquier caso tuve tiempo más que de sobra para exprimirlo todo y más"""

"""No te compensa ni te interesa entrar en la configuración del Quantenna"""

 

 

Ya soy mayorcito asi que no hay miedo, si puedes y quieres pasame la info por privado.

 

Te lo agradezco de antemano....seguire buscando el tema ese de esa puerta de enlace pero necesitaría el passwd de la shell para comprobarlo, ya que sigue apareciendo despues de un reseteo a default y con todo el acceso desactivado en el router, ni ssh, ni tr069, ni snmp...solo quiero comprobar de donde salen esos cambios.

 

 

Mensaje 7 de 16
1.666 Visitas
Highlighted

Yo también quiero unirme a la fiesta.Me interesa saber como entrar a la gui de quantenna.

Mensaje 8 de 16
1.638 Visitas
Highlighted

¿Mutis por el foro? Emoticono loco

Mensaje 9 de 16
1.583 Visitas
Highlighted

Buenas @Jesus.H.

 

No es mutis, al margen de que tena más o menos tiempo, es que a pesar de que me gusta explicar en la medida de lo posible las cosas, y si has leído mi blog sabes a que me refiero, cuando se trata de una posibilidad muy real de cargarte un hardware que no es en propiedad la cosa se complica... el amigo @taker59 sabe de que hablamos, verdad compañero?? Solo qeu en este caso no hay cable de serie que pueda salvar. Además... tampoco tengo por aquí ya el GPT y no te podría asegurar los pasos a seguir :). Por este foro puse en su día algun dato más y alguna imagen, no se donde andará, @taker59 lo vio en su día y le dije poco mas o menos lo mismo...

 

Saludos.


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 10 de 16
1.564 Visitas
Highlighted

Theliel escribió:

Buenas @Jesus.H.

 

No es mutis, al margen de que tena más o menos tiempo, es que a pesar de que me gusta explicar en la medida de lo posible las cosas, y si has leído mi blog sabes a que me refiero, cuando se trata de una posibilidad muy real de cargarte un hardware que no es en propiedad la cosa se complica... el amigo @taker59 sabe de que hablamos, verdad compañero?? Solo qeu en este caso no hay cable de serie que pueda salvar. Además... tampoco tengo por aquí ya el GPT y no te podría asegurar los pasos a seguir :). Por este foro puse en su día algun dato más y alguna imagen, no se donde andará, @taker59 lo vio en su día y le dije poco mas o menos lo mismo...

 

Saludos.


Asi es.

 

El Cable..... ,he podido conectar en ambos HGU (Mitra-Askey) el cable,tanto en los dos conectores (principal y Quanntena) y tengo comunicación ,pero ..... no funciona lo esencial ,el teclado.Estara la consola bloqueada?

 

Un saludo.

Mensaje 11 de 16
1.560 Visitas
Highlighted

Buenas @taker59, eso es simple... un fallo de configuración del cliente que estés usando para l  conexión serie. Por lo general es debido al control de flujo, usa control de flujo por software (llamado también XON/XOFF).


Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 12 de 16
1.554 Visitas
Highlighted

Theliel escribió:

Buenas @Jesus.H.

 

No es mutis, al margen de que tena más o menos tiempo, es que a pesar de que me gusta explicar en la medida de lo posible las cosas, y si has leído mi blog sabes a que me refiero, cuando se trata de una posibilidad muy real de cargarte un hardware que no es en propiedad la cosa se complica... el amigo @taker59 sabe de que hablamos, verdad compañero?? Solo qeu en este caso no hay cable de serie que pueda salvar. Además... tampoco tengo por aquí ya el GPT y no te podría asegurar los pasos a seguir :). Por este foro puse en su día algun dato más y alguna imagen, no se donde andará, @taker59 lo vio en su día y le dije poco mas o menos lo mismo...

 

Saludos.


Como ya dije solo quería la password para entrar en la shell sh para hacer una comprobación, nada más, de todas formas te agradezco tu atención.

 

Mensaje 13 de 16
1.520 Visitas
Highlighted

La pass de shell es la misma que la del mitrastrar negro y tambien es valida para el video bridge mitrastar.

 

Edit:No es la misma.

 

http://comunidad.movistar.es/t5/Soporte-T%C3%A9cnico-de-Fibra-%C3%93ptica/Shell-en-HGU-Askey/m-p/283...

Mensaje 14 de 16
1.507 Visitas
Highlighted

 


taker59 escribió:

La pass de shell es la misma que la del mitrastrar negro y tambien es valida para el video bridge mitrastar.

 

Edit:No es la misma.

 

http://comunidad.movistar.es/t5/Soporte-T%C3%A9cnico-de-Fibra-%C3%93ptica/Shell-en-HGU-Askey/m-p/283...


Muchas gracias taker59 por la info, el caso es que se producen cambios en el router que yo no realizo, como el que se active la regla del firewall del servicio ssh, o que aunque entres al router por telnet y crees o borres reglas en iptables, se autogeneran de nuevo anulando reglas previas....y todo esto teniendo TR069, ACS y SNMP deshabilitados y con reglas explicitas para bloquear las conexiones a dichos servicios.

 

me refiero a que si deshabilitas el TR069 aparece despues otra regla que acepta todo de nuevo, aquí se ve como se duplica la regla, ¿estas reglas permiten o bloquean? ¿el firewall está funcionando? 

 

Si la tabla INPUT (policy ACCEPT) está configurada con estas dos reglas:

ACCEPT udp -- anywhere 10.x.x.x udp dpt:5060
FrwlInChk all -- anywhere anywhere

 

y la tabla FrwlInChk tiene estas primeras reglas, aparte de otras

 

num target prot opt source destination
1 ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
2 DROP udp -- anywhere anywhere udp dpt:7547
3 DROP tcp -- anywhere anywhere tcp dpt:7547
4 DROP udp -- anywhere anywhere udp dpt:7547
5 DROP tcp -- anywhere anywhere tcp dpt:7547
6 ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED

 

¿tengo que entender que todas las conexiones son aceptadas aunque esten configuradas para dropear las conexiones? 

 

Me maravillo con la política de Movistar con respecto a la seguridad de sus usuarios...los DDOS, que sigue subiendo el porcentaje de amenaza y este router no tiene una proteccion ante tales ataques o similares, los típicos de bloqueo si se producen una determinada cantidad de paquetes TCP/IP a un puerto o con un protocolo especifico.

 

Edito: si que hay una regla:

 

LOG tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 6/hour burst 5 LO
G level alert prefix "Intrusion -> "

 

lo que no tengo claro es si solo las loguea o si tambien las dropea.

 

Tambien tengo un mensage que aparece constantemente cuando estoy en el telnet:

 

# omcid:error:55.623:cmsObj_getNthParam:301:Invalid parameter number (11 >= 11)
omcid:error:55.623: omci_msg_copy_to_packet:1220:get of parameter 11 from object id 2122 failed, ret=9003

 

¿alguna idea?

Mensaje 15 de 16
1.441 Visitas
Highlighted

 

 

 

 

 

 

Mensaje 16 de 16
1.328 Visitas