Soluciones Fallos Mitrastar (Batería, WIFI, DHCP...)

Theliel
Yo probé el VDSL
Soluciones Fallos Mitrastar (Batería, WIFI, DHCP...)

Sumario (Fix existentes actualmente)

 

  • -Problema de Batería de la B21, el problema de los ARP (Solucionado a partir de la b23)
  • -Problema de Batería y degradación WIFI por tráfico excesivo IGMP (Sólo usuarios con TV contratada)
  • -Activación del modo de bajo consumo para dispositivos portátiles
  • -Uso de banda de frecuencia de 40MHz en WIFI (Duplica la velocidad de enlace, hasta 300mbs)
  • -Bloqueo del tráfico DHCP de clientes/servidor hacia fuera del Router
  • -Cuelgues periódicos donde es necesario reiniciar el Router (Solucionado a partir de la b23)
  • -Como añadir equipos a la tabla ARP de forma estática para poder hacer WOL/WOW

 

 

Pese a las muchas quejas que tienen los usuarios ante este Router, he de decir que no es tan malo como aparenta, el principal problmea que tiene son los numeros bugs que tiene su software, y en segundo lugar su adaptador WIFI que podría ser mejor. Sobre lo segundo no podemos hacer mucho, sobre lo primero podemos ir aplicando pequeños "parches" (que iré añadiendo/poninedo en este post) para ir solucionando los problemas que van apareciendo, hasta que Mitrastar/Movistar lancen firmware que de una vez por todas vayan puliendo los fallos.

 

Antes que nada, recordar que todo lo que pasa en el mundo no es culpa del Mitrastar. Quiero decir con esto que porque alguien tenga un problema X no implica que el router tenga un problema. Así que intentemos separar por un lado lo que son fallos del router, por otro lado lo que nos gustaría que hiciese el router (que también pueden añadirse esas cosillas a la lista de abajo) y por último problemas del usuario o de otros dispositivos, que nada tiene que ver con el Router. Un problema se debe de poder replicar y verificar!! Si esto no sucede por lo general no es un problema del router, y es otra la causa. Decir "Problemas de Cuelges" es demasiado genérico, hay que ver cuando se cuelga, por qué... y si podemos replicarlo seguramente entonces podremos corregirlo.

 

Hace ya unas semanas que algunos de nosotros sabemos aplicar diferentes correcciones y modificaciones, pero hay que tener ciertos conocimientos, y además esas modificaciones no sobreviven a un reinicio. Ahora de forma "sencilla" podemos hacer las mismas modificaciones y que sobrevivan a los reinicios. El procedimiento es exactamente el mismo para cada "parche" que se quiera ir aplicando, simplemente se añade el "nuevo" a la "lista".

 

ATENCION: Está probado sobre la Firmware Pseudo-oficial B21, no he realizado ninguna prueba sobre la B14, ni en si el proceso se puede realizar ni tampoco si los fixes son funcionales. Por otro lado mucho cuidadito con añadir una coma o un caracter de más/menos, no me hago responsable de lo que cada uno haga. En el peor de los casos se debería de poder realizar un Reset y listo (En teoría), pero cada cual que asuma lo suyo. El proceso es sencillo

 

1º. Acceso a la interfaz Web del Mitrastar (http://192.168.1.1/cgi-bin/main.html por defecto), usuario/contraseña: supervisor/zyad1234

 

2º. Realizamos un backup de nuestros ajustes: Maintenance -> Backup/Restore -> Backup

 

3º. Editamos el cfg de configuración con un editor de texto (a poder ser notepad++ o cualquier otro que respete los saltos de linea unix/linux

 

4º. Buscamos la cadena: "</Autoexec>"

 

5º. Añadimos/modificamos dicha línea parar crear nuestro bloque, que tendrá este formato:

 

<Autoexec> 	<Entry
/> </Autoexec>

6º- Entre esas dos líneas se irán incluyendo los "fixes" que queramos, una línea nueva por cada uno. Los "fixes" no serán más que la ejecución de ciertos comandos/herramientas que permitan solucionarlos (vemos dos ejemplos luego)

 

7º. Cuando se haya modificado a voluntad, guardamos, volvemos a la interfaz web, restauramos nuestro nuevo cfg y listo, los cambios se estarán aplicando desde el primer momento.

-----------------------------------------------

 

Batería (Problerma con los ARP):

 

Para empezar, vamos a añadir la solución definitiva para el consumo de batería que sufre la B21. La B14 tiene sus problemas, pero con la B21 se solucionan en gran medida. Repito de nuevo, esto es para la B21, y el fallo que tiene el router de bombardear con paquetes ARP a todos los clientes conectados. Esto hace que los dispositivos portátiles no entren en sueño profundo y la batería sufre enormemente. Hay quienes lo acusan más y otros menos, pero el problema es real (hablamos de un consumo de más de un 20-30% fácilmente)

 

El problema viene a que algún módulo de red o el kernel del router no respeta el parámetro mcast_solicit, establecido a 3 por defecto, así que se fuerza mcast_solicit a cero. Traducido esto en una instrucción que puede ejecutarse en la Shell:

 

sysctl -w net.ipv4.neigh.br0.mcast_solicit=0

Si queremos transportar ese "fix" a nuestro cfg, nuestro bloque quedaría de la siguiente forma:

 

<Autoexec> 	<Entry
arp_fix="sysctl -w net.ipv4.neigh.br0.mcast_solicit=0" />
</Autoexec>

-------------------------------------------------

 

Bateria (Reducir el tiempo de Query en IGMP Proxy):

 

Pese a que en un principio achaqué el problema de la batería exclusivamente al problema de los ARP anteriormente mencionado, lo cierto es que los resultados de la comunidad han sido variados, mientras unos reafirmaban que todo estaba perfecto, otros que aunque había mejorado mucho aun estaba lejos del consumo que tenían antes. Al final resultó existir un segundo problema importante en el consumo de batería, pero este SOLO AFECTA a quellos que tienen contratada igualmente la Televisión con Movistar. Es decir, que aquellos que no tienen dicho servicio contratado no les afecta en nada, y explica efectivamente el motivo por el cual a algunos usuarios el problema de los ARP no solucionaba completamente el problema.

 

En este ocasión el responsable es un seteo "incorrecto" (aunque sería mejor decir inadecuado) en el archivo de configuración que carga Movistar, con lo que en teoría podría ser solucionado POR ELLOS, sin que Mitrastar tenga mucho que aportar aquí.

 

Para que la TV funcione correctamente, el Mitrastar requiere tener habilitada una función llamada IGMP Proxy (no confundir con IGMP Snooping). En función de los servicios contratados, Movistar realiza la telecarga con la configuración específica de cada usuario, y habilita IGMP Proxy si tenemos habilitada la televisión. Las opciones de IGMP Proxy no pueden configurarse a través de la interfaz Web, ni siquiera habilitarlo o deshabilitarlo, los ajustes quedan especificados en el archivo de configuración que manda Movistar por remoto... y por supuesto dichos ajustes se reflejan en la copia de los ajustes que siempre podemos realizar.

 

Cuando IGMP Proxy está en funcionamiento, el Router emite a la red por Broadcast (en realidad lo hace por Multicast, pero a todos) un Query (pregunta) para conocer los grupos Multicast a los que pertenece cada uno de los equipos de la red, y estos a su vez como es natural responden a dicha petición... y lo hacen también por Multicast (llega a todos). Este funcionamiento es normal, el problema es que estos Querys se realizan de forma demasiado frecuentes, y esto es lo que no es normal. Por defecto el Mitrastar, el archivo de configuración que carga Movistar, está configurado para que el Router lance estos Query cada 10 Segundos!! Esto es una barbaridad, porque si a eso le sumamos las respuestas de TODOS los dispositivos de la red, se está generando en la red un flujo constante de tráfico IGMP, que es Multicast y llega a todos!! Con lo que de nuevo tenemos el mismo problema que con los ARP... los dispositivos portátiles no pueden entrar en sueño profundo.

 

Para hacernos una idea, el tiempo que define el estándar IGMP como "normal" se establece por defecto en los 125segundos. Esto significaría que el Mitrastar estaría usando un tiempo 12 veces menor. Ya no se trata sólo de ahorrar ancho de banda en la red, que a fin de cuentas los recursos WIFI son limitados y estos paquetes tienen que llegar igualmente a dispositivos portátiles, sino que impide que nadie "duerma".

 

Por suerte la solución en este caso es sencilla, tan sólo debemos de modificar el tiempo prefijado de 10 segundos a otro que nos guste más, por ejemplo 125, que como me han asegurado los compañeros es más que suficiente. Tan sólo debemos editar nuestro archivo de configuración. Como siempre, realizar una copia de seguridad de este y al editarlo tener cuidado de no tocar nada más que lo necesario. En este ocasión buscaremos por:

 

<IGMPproxy

Encontraremos rápidamente un bloque como el siguiente:

 

 

<IGMPproxy> 	<Entry Enabled="Yes" Robustness="2" QueryInterval="10"
QueryResInterval="9" LastMemQueryInterval="10" StartQueryInterval="10"
StartQueryCount="2" MaxGroups="16" UnsolicitedReportInterval="1"
SSMEnable="true" ProxyVersion="IGMPv2" />
</IGMPproxy>

El valor mágico a modificar es eefctivamente: QueryInterval="10"

 

Cambiando el valor por 125 tendríamos suficiente, en mi caso, el bloque quedaría de la siguiente forma (el bloque puede ser diferente dependiendo del usuario y su configuración, lo importante es modificar el QueryInterval):

 

<IGMPproxy> 	<Entry Enabled="Yes" Robustness="2" QueryInterval="125"
QueryResInterval="9" LastMemQueryInterval="10" StartQueryInterval="10"
StartQueryCount="2" MaxGroups="16" UnsolicitedReportInterval="1"
SSMEnable="true" ProxyVersion="IGMPv2" />
</IGMPproxy>

Como siempre, guardar, volver a cargar la nueva configuración y listo. Cuando reinicie todo funcionará exactamente igual, con la salvedad de que ahora el Router no preguntará cada 10 segundos, sino lo hará cada 125 segundos, una gran diferencia que ahorrará a dispositivos tipo teléfonos/tablets bastantes puntos porcentuales de batería durante los tiempos de reposo.

------------------------------------------------ 

 

Batería (Activar el modo PowerSafe para dispositivos portátiles):

 

Las extensiones WMM de WIFI, entre otras muchas, poseen una especificación llamada APSD. APSD permite que el punto de acceso (en este caso el router) mantener al dispositivo asociado que lo solicite/permita en un estado de menor consumo.

 

Como vimos en el fix anterior, los dispositivos logran ahorrar muchísima batería cuando entran en estados llamados de sueño profundo. En el caso anterior cuando reciben paquetes de datos constantes por WIFI impide que estos entren en sueño profundo, haciendo que la batería se agote a un ritmo enorme. APSD viene a intentar lograr que el tráfico que llega a los dispositivos cuando están en reposo, sea más... "ordenado" y "pausado", para despertar lo menos posible al dispositivo. Para esto lo que hace el router es que una vez un dispositivo le informa que está en reposo, en vez de enviarle al instante todo el tráfico que vaya dirigido a él, lo almacena en un buffer que no manda hasta que este está lleno.

 

Visto desde un punto de vista práctico... si nos mandan un WhatsApp en vez de mandarnos al instante dicho WhatsApp, si el buffer tiene el tamaño de 3 WhatsApp por ejemplo, nos mandaría los 3 de golpe, en vez de uno en uno. Con esto se logra que el móvil esté mucho más tiempo en reposo con lo que aumenta aun más el ahorro de energía. La contraindicación básicamente es que hay una mayor latencia en la recepción de los datos, a lo mejor pasa de ser inmediato a ser 2-3 segundos... o lo que sea. Normalmente esto no es un problema porque precisamente si la pantalla está apagada es que no estamos generando de forma activa tráfico.

 

Esta opicón dependiendo del Router viene habilitada o no por defecto, aunque la mayoría la soportan, y prácticamente el 100% de todos los dispositivos móviles. Debería de ahorrar un buen % de batería sobre todo por la noche. Este router no tiene en la interfaz Web una opción para habilitar o deshabilitarla, pero existe como opción interna en el archivo de configuración, con lo que NO HAY QUE AÑADIRLO EN NUESTRO BLOQUE DE FIX.

 

En este caso en concreto, editamos el archivo de configuración y buscamos por: "<Entry0 SSID"

(sin las comillas). Si miramos bien estaremos en las opciones de configuración de nuestro WIFI, concretamente en la sección WLan -> Entry0. Lo que tenemos que hacer es añadir un parámetro nuevo:

 

APSDCapable="1"

 

Si originalmente tenemos esto:

 

<Entry0 SSID="NUESTROSSID" HideSSID="0"

Lo modificaremos con la entrada anterior:

 

<Entry0 SSID="NUESTROSSID" HideSSID="0" APSDCapable="1"

 

También deberemos por asegurarnos, establecer el parámetro WMM que está en el mismo bloque de cero (en caso de estar a cero) a 1.  (sustituir el 0 -> 1)

 

De este modo los dispositivos móviles deberían de lograr ahorrar aun más batería cuando están por WIFI. Originariamente puse buscar otra cadena, pero por lo que he visto diferentes cargas telemáticas de la B21 tienen diferencias entre unos y otros, y en algunos no se encontraba la cadena que se buscaba antes. En teoría se debería de poder añadir el nuevo parámetro en cualquier lugar del bloque citado, dentro de Entry0

------------------------------------------------ 

 

Uso de la Banda de frecuencia de 40Mhz de WIFI (Duplica la velocidad):

 

En las especificaciones 802.11n, se permite la anchura de 40MHz para mejorar la transmisión de datos, logrando literalmente a doblar la velocidad que se obtiene usando la anchura estándar de los 20MHz. A dái de hoy prácticamente cualquier router o dispositivo permite trabajar en esta frecuencia, logrando como es natural una velocidad mucho mayor. Pasamos de tener básicamente enlaces de 144mbs a tener 300mbs, que es una gran diferencia.

 

Nuestro querido Mitrastar permite el uso de los 40Mhz estableciendo una opción en la interfaz web llamada "Channel Width", que permite establecerlo en 20Mhz (fijo) o en Auto (20/40). El problema está en que un fallo del Driver provoca que si se establece en Auto (y por tanto poder tener enlaces de 300mbs) funcionará TAN SOLO hasta que se reinicie. Una vez que se reinicie por le motivo que sea el router, este dejará de usar la banda de 40MHz, siendo necesario para volver activarla poner de nuevo dicha opción en 20Mhz, reiniciar, y ponerla otra vez en Auto... y volverá a funcionar otra vez sólo el tiempo que dure sin reiniciar.

 

Aquí lo que se ha hecho es usando nuestro bloque de "fixes" forzar que cada vez que se reinicie el router este funcione en la banda de 20/40. Pero hay que tener en cuenta dos cosas:

 

a) El fix SOLO FUNCIONA si en la interfaz web se configura como 20MHz, si se configura como Auto, el fix NO FUNCIONARÁ. Así que antes/después de poner el fix, asegurarse que Channel Width está en 20MHz. Esto se debe a que si el router se reinicia estando configurado como 20/40 la interfaz WIFI se configura mal haciendo imposible su uso.

 

b) Es necesario especificar el canal que tengamos cada uno. Si usamos el 5, poner el 5 en el fix. Yo tengo puesto 13, así que por eso pone 13, pero que cada uno use el suyo. El procedimiento es el mismo, nuestro fix sería en este caso:

 

wifi_fix="/userfs/bin/iwpriv ra0 set HtBw=1; /userfs/bin/iwpriv ra0 set Channel=13"

 

 

Si lo quisiésemos añadir al primero de la batería, el bloque quedaría:

 

<Autoexec> 	<Entry
arp_fix="sysctl -w net.ipv4.neigh.br0.mcast_solicit=0"
wifi_fix="/userfs/bin/iwpriv ra0 set HtBw=1; /userfs/bin/iwpriv ra0 set Channel=13" />
</Autoexec>

------------------------------------------------

 

Bloqueo del tráfico DHCP del router

 

Otro problema que ha surgido a algún compañero ya, @ManuelTT@taker59 entre otros, es que el router bloquea por sistema todo el tráfico DHCP que circula por él que no genere él. Esto normalmente no importa, pero si queremos que sea otro dispositivo de nuestra red quien haga de servidor DHCP, nos encontraremos que ningún dispositivo conectado al Mitrastar puede obtener el lease.

 

El problema en esta ocasión es algo más complejo, pero es real. El router cuando levanta la interfaz WAN crea un filtrado que impide este tipo de tráfico. Solucionar este bloque es muy sencillo, simplemente se elimina la regla que lo bloquea y solucionado. El problema en este caso es que dicho bloqueo se realiza no al iniciar el router que es cuando se ejecutan nuestros "fixes", sino que se realiza de forma dinámica una vez se establece la conexión WAN. Sin modificar la firmware y sin las herramientas para poder ejecutar instrucciones que se disparen ante ciertos sucesos (es posible que sí se pueda, pero no tengo ganas de trabajar más en ello), la mejor opción que se me ocurre es crear en este caso un cronjob, una tarea que se repite cíclicamente cada X, siendo X el tiempo que queramos, de este modo se puede hacer que se ejecute una instrucción que sea eliminar las reglas que causan el problema cada X, con lo que se pude solventar el problema de que la regla se aplica después de levantar WAN. Lo ideal es que la tarea sólo se ejecutase una vez, pero como esto es imposible, hay que hacer que sea indefinido.

 

Si establecemos un tiempo pequeño, la ventaja es que el tráfico DHCP empezará a circular tan pronto como se ejecute la 1º vez la regla (si ya se ha levantado la instrucción), pero en contra se ejecutará más veces la instrucción (aunque esto no es un problema). Si se usa un tiempo más grande se ejecutará menos veces, pero el tráfico no circulará hasta que se ejecuta por primera vez. Así que por comodidad yo he preferido usar un minuto. Debería de ser tiempo suficiente para que al ejecutarse la regla ya exista y se elimine. No es lo más ortodoxo, pero funciona bien. Eso quiere decir que un minuto después de que se ejecute el cron, la regla que bloquea DHCP sería eliminada, y todo funcionaría bien

 

El bloqueo es una regla ebtable, y se eliminaría así por Shell:

 

ebtables -D FORWARD -p ipv4 --ip-proto 17 --ip-source-port 67:68 -j DROP

 

La creación de cron en este router es un poco... cogida con pinzas. Tenemos que programar el cron igualmente por nuestro archivo de configuración. El archivo de crontab es la sintaxis estándar, la línea para programarlo sería algo así:

 

 

* * * * * ebtables -D FORWARD -p ipv4 --ip-proto 17 --ip-source-port 67:68 -j DROP

 

Eso programaría una tarea cron para que se ejecutase cada minuto. El problema es que el router ya usa para otra cuestión un cron, que cuando se ejecuta si detecta algún otro lo cierra, así que tenemos más bien que añadir este otro a parte, pero el cron que ejecuta el router para otras tareas tb ejecutará este. Por una limitación de la firmware, es necesario escribir el fix en dos líneas, si se pusiese en una sola el router cascaría, así que... MUCHO OJO. El fix completo quedaría así:

 

 

dhcp_fix="mkdir /etc/crontabs"
dhcp_fix2="echo '* * * * * ebtables -D FORWARD -p ipv4 --ip-proto 17 --ip-source-port 67:68 -j DROP' &gt; /etc/crontabs/admin"

 

 

 

De nuevo traducido esto en nuestro archivo cfg (y por ejemplo con el fix de la batería (ARP) incluido también), quedaría de la siguiente forma:

 

<Autoexec> 	<Entry
arp_fix="sysctl -w net.ipv4.neigh.br0.mcast_solicit=0"
dhcp_fix="mkdir /etc/crontabs"
dhcp_fix2="echo '* * * * * ebtables -D FORWARD -p ipv4 --ip-proto 17 --ip-source-port 67:68 -j DROP' &gt; /etc/crontabs/admin" />
</Autoexec>

 

Hay que tener en cuenta que aunque la B23+ continúa usando dicha regla, debido a cambios internos no se pude usar el usuario admin (no existe), con lo que sería necesario añadir el crontab directamente al que el sistema crea para sus propias necesidades. Se puede hacer, básicamente en vez de crear el archivo "admin" se adjuntaría como línea nueva al archivo "1234" de la misma ubicación, pero no he probado aun los tiempos. Si primero se ejecuta nuestro fix, el archivo es muy posible que no exista aun, así que tendría que comprobar si cuando el sistema crea el suyo lo adjunta al que nosotros crearíamos o lo sustituiría... se tendría que ver.

-------------------------------------------------

 

Bloqueos del Router

 

Algunos usuarios han experimentado que llega un momento en el que el router "muere". la conectividad es correcta, todo parece funcionar en teoría, pero... no hay internet, nada funciona. El problema se soluciona como es natural reiniciando el router. Esto se ha observado al menos en la versión B21, no se sabe bien si estaba presente antes, o si está presente en versiones posteriores

 

El problema no afecta a todos, de echo aunque sabemos por qué ocurre, no sabemos que lo dispara, o que provoca esta situación. Por lo general, quienes lo sufren, suelen padecerlo cada 3-5 días de uso, tras los cuales se ven obligados a reiniciar el Router. Otros como digo no les afecta en absoluto, con lo que estos fix no serían para ellos

 

El problema aparece porque el Router agota la RAM. Este ejecuta varias instancias de un proceso crítico llamado cfg_manager, que gestiona muchas partes del Router y servicios. Por alguna razón que desconocemos, el consumo de RAM de este proceso y sus instancias empieza a aumentar sin parar la RAM necesaria. El aumento no es sustancial, pero es más o menos contínuo... el Router cuenta con 128MB de RAM y después de arrancado tiene libre unos 80-90MB, lo cual no está nada mal. Agotar toda esta memoria al proceso con el problema (además del consumo que hacen otros procesos, servicios, archivos... ) lleva su tiempo, no es algo que suceda (al menos no lo hemos visto) en minutos, pero a lo largo de 3-5 días, sí. Cuando el Router se queda sin RAM... se congela.

 

No podemos deshabilitar/suprimir el proceso porque es crítico, si lo hacemos se perdería seguro el acceso a la interfaz web y posiblemente otros servicios. Si matásemos el proceso y todas las instancias, la RAM se recupera, pero... no es una opción. Otra opción sería reiniciarlo. Esta opción aun creo que sería posible... el problema no radica tanto en finalizar el proceso y arrancarlo de nuevo, esto es fácil, el problema es que cuando se inicia de nuevo, el propio proceso reinicia muchos servicios, entre ello la ejecución misma de los comandos que introducimos, con lo que en cuanto se ejecutase (hay que ejecutarlo dos veces), no se ejecutaría la segunda vez, y el cron encargado para reiniciar el proceso cada X no funcionaría...

 

Debido a esto, por ahora, la única "solución" que si es sencilla, sería cortar por lo sano. Sino podemos reiniciar el proceso problemático, podemos reiniciar completamente el Router. Es un mal menor, ya que podemos hacerlo al menos de modo programado, por ejemplo una vez al día por la noche, o una vez cada 3 días a las 5 de la mañana.... tiene la desventaja no obstante que mientras se reinicia, cualquier conexión que tuviésemos en ese momento se iría al trasto, pero aun así creo que es mucho mejor poder controlar esos reinicios, a no que se bloquee cuando dios le dio a entender.

 

El proceso sería igual (muy similar) al visto en el bloque anterior. Se trata de programar una tarea cron que se ejecute a una determinada fecha/hora, y esa tarea en este caso será: Reiniciar Router. Aquí, cada cual debe de ver cual es la mejor hora/fecha para el reinicio, así que la siguiente línea quedará pendiente para cada cual la modifique según crea. El cron para esto sería el siguiente:

 

 

0 3 */2 * * /sbin/reboot

 

Es necesario entender mínimamente como funciona, puesto que cada cual deberá de modificar los números que aparecen en función de sus necesidades. Nosotros nos interesa tan solo día hora y minuto, así que nos centramos en las tres primeros columnas, en el caso que yo he puesto: 0 3 */2

 

-La primera columna especifica el minuto, se pude poner cualquier valor entre 0 y 59. El * sería cada minuto, cosa que no queremos

-La segunda columna especifica la hora, con lo que pude usarse cualquier valor entre 0 y 23.

-La tercera el día, y este tiene truco. Podemos especificar un valor entre 1-31, pero eso no nos serviría porque el router se reiniciaría sólo un día concreto al mes. En cambio si usamos la sintaxis que aparece "*/2", implica que estamos seleccionado los días pares del mes. si usásemos "*/3" estaríamos indicando que se ejecutase cada 3 días... y así sucesivamente.

 

Es decir, en el caso de ejemplo estaríamos programando el reinicio a las 3:00 de la mañana (AM) de los días pares (que en la práctica sería cada 2 días exceptuando los finales de meses de 31 día que se ejecutaría al tercero. Si quisiésemos que se ejecutase cada 3 días a las 5 de la mañana y 15 minutos, por ejemplo:

 

15 5 */3 * * /sbin/reboot

 

Pues si cogemos todo eso, creamos el archivo necesario y todo lo demás, el fix completo quedaría del siguiente modo, tomando los valores del primer ejemplo:

 

 

bloqueo_fix="mkdir /etc/crontabs"
bloqueo_fix2="echo '0 3 */2 * * /sbin/reboot' &gt; /etc/crontabs/admin"

 

NOTA: Si por un casual se necesitase un segundo cron (por ejemplo por usar el fix de DHCP), sería posible, pero el segundo cron debería de ser añadido al archivo existente, no sobreescrito. Es decir, usar >> en vez de >. Es decir

 

&gt;&gt;

en vez de

&gt;

--------------------------------------------------​------------------

 

Añadir equipos a la tabla ARP de forma estática

 

Como ya son muchos los que lo han pedido y preguntado, no veo motivo de no añadirlo aquí. Ya se había hablado en el hilo, pero es verdad que sepultado entre otros cientos de post.

 

Una función bastante habitual, es hacer uso de Wake On Lan, es decir, poder encender de forma remota nuestro equipo. Esto requiere como es natural tener configurado el equipo, que este esté conectado por cable al Router, que la bíos esté configurada para tal efecto... y evidentemente un programa que podemos instalar en el Móvil, o en otro PC o incluso a través de una web, para mandar las señales necesarias al equipo para que este se inicie. Esto no es algo nuevo, WOL se lleva usando desde tiempos inmemorables.

 

WOL no suele dar problemas, una vez se configura bien el equipo no hay mucho más que hacer. Pero tenemos una variante, Wake On WAN (WOW), que es poder realizar lo mismo, pero desde fuera de la red, es decir, desde Internet. La utilidad es evidente, poder apagar el equipo, irnos a cualquier lado, y si necesitamos acceder a él poder arrancarlo desde donde estemos para poder acceder luego de forma remota.

 

El problema con WOW, es que WOL se fundamenta en poder enviar a una dirección física específica (Una MAC) un paquete específico, pero desde Internet esto no lo podemos hacer. Desde Internet, podemos crear una redirección de puertos en el Router para que al llegar a él, este los reenvíe a su vez al equipo que sea, y ojo, funciona perfectamente, pero para que eso sea posible el Router por lo general debe de conocer quien/que equipo, posee esa IP. Como el equipo está apagado, no tiene asignada ninguna IP, así que el Router tiene que buscar en la tabla ARP para ver al menos si tiene registrada dicha dirección MAC. El problema es que la tabla ARP es dinámica, se va rellenando en función de los equipos que se van conectado o desconectando, y después de cierto tiempo, si un equipo se ha ido de la red, la tabla ARP elimina el registro del equipo que ya no está.

 

Esto hace que dependiendo del funcionamiento del Router y de la propia aplicación que se use para poder realizar WOL/WOW, sea a veces un infierno. Una solución es por ejemplo el reenvío de puertos en Broadcast, otra que el Router permita cierto tránsito especial de tráfico... pero nada puede garantizarse, como digo es muy dependiente de cada Router y de cada aplicación que se use. Hay Routers que simplemente con crear el DHCP estático pertinente es capaz, otros funcionan bien simplemente usando la dirección de broadcast 255.255.255.255.. como digo es muy dependiente.

 

Existe no obstante una solución "global" a esto, en el caso de que el usuario no logre configurar el equipo o la aplicación. Crear manualmente un registro estático en la tabla ARP del Router. De este modo la tabla ARP siempre contendrá IP/MAC del equipo que queremos despertar, y junto al mapeo de puertos correspondiente, nos aseguramos que el tráfico especial qeu se manda para iniciar el equipo, llegue.

 

Algunos Routers permiten realizar esto en la propia interfaz, aunque son los menos. La mayoría que lo permiten se pude realizar por scripts. El Mitrastar como es normal no lo permite por la interfaz web, y en teoría tampoco podemos usar Scripts, pero... sí podemos hacerlo gracias digamos a la "puerta trasera" que he ido usando para aplicar los diferentes fix. Se pueden aplicar fix, y se pueden crear igualmente entradas ARP estáticas.

 

En Linux, un registro ARP estático se añade del siguiente modo, los datos de la IP/MAC son inventados:

 

 

arp -s 192.168.1.55 aa:bb:cc:dd:00:11

 

Así, que si usamos exactamente el mismo procedimiento que en el resto de "correcciones", podríamos hacer algo así:

 

arp_mod="/sbin/arp -s 192.168.1.55 aa:bb:cc:dd:00:11"

 

Si quisiésemos añadir más de un equipo, tan sólo tendríamos que añadir una línea adicional por cada equipo, cambiando el nombre de la etiqueta

 

arp_mod="/sbin/arp -s 192.168.1.55 aa:bb:cc:dd:00:11"
arp2_mod="/sbin/arp -s 192.168.1.56 aa:bb:cc:dd:00:12"

 

Con esto, el Router nada más iniciar, crearía las entradas pertinentes en su tabla ARP, permitiendo poder hacer WOW sin problema.

 

---------------------------------------------------------------------

 

A medida de que vayan saliendo otros problemas QUE REALMENTE SEAN problemas del router Y que puedan ser solucionados mediante la aplicación de estos pequeños... "fixes", no veo la razón por la cual no seguir añadiendo otros. Por supuesto estos "fixes" no tienen porqué necesitarlos todos, por ejemplo el problema de DHCP no es un problema si no usamos un servidor DHCP diferente.

 

Por supuesto el potencial de esto no se limita a realizar fixes, sino a poder realizar ajustes avanzados o concretos, ya sean filtrados, rutas... un poco lo que se quiera.



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 1 de 991
84.007 Visitas
990 RESPUESTAS 990
Theliel
Yo probé el VDSL

Ya sabemos por qué ocurren más o menos, el problema es aislarlo o poder reiniciar sin tener complicaciones el proceso pertinente, y eso es un problema. Podemos programar reinicios automáticos cada X horas/dias.... pero es una solución bastante fea, me gustaría dar con alguna otra opción...



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 376 de 991
2.417 Visitas
Swapper
Mi vida cambió con el ADSL

Hola.

 

Ha sido un alivio encontrar este hilo, porque me estaba volviendo loco. Desde hace 2 semanas mi router Mitrastar HGW-2501GN-R2 se quedaba 'tonto' cada 1-2 días: me dejaba de dar ips,  le dejaba de funcionar la interficie web y me dejaba de funcionar el teléfono, aunque respondía al ping. Si me ponía ip estática y como servidor DNS el de google por ejemplo, podía navegar, aunque seguía sin poder acceder al router. Reiniciándolo todo volvía a funcionar.

 

Tras poner 4 incidencias a Movistar, y que me cambiasen el router, la explicación de los técnicos era que me pasaba esto porque tenía demasiados dispositivos en casa (tengo como unos 20 porque tengo la casa medio domotizada), pero hace 3 semanas por ejemplo no me pasaba. supongo que era por tener una versión anterior del firmware  (ni me pasaba antes de pasarme a la fibra, cuando tenía ADSL). Ahora que veo que lo de los 'cuelgues' del router le pasa a más gente por un problema en la versión B21 ya estoy más tranquilo, será cuestión de ir reiniciándolo cada noche hasta que saquen un nuevo firmware (o hasta que a Theliel se le ocurra algo 😉 )

 

Un saludo.

 

Mensaje 377 de 991
2.380 Visitas
Swapper
Mi vida cambió con el ADSL

Añado info de 2 casos en los que creo que no aparece este problema (lo comprobaré mañana).

 

En el trabajo, tengo dos de estos routers, cada uno conectado a una FFTH diferente, en los que no solemos tener problemas con la conexión a Internet.

 

En un caso tengo el router mitrastar conectado a una LAN en la que usa su acceso a Internet un mínimo de 95 equipos, pero no de forma directa, sino a través de un firewall con Linux que hace NAT. Es decir, tengo una LAN con todos estos equipos que tienen como puerta de enlace al firewall con Linux, el firewall con Linux hace NAT y de Proxy transparente, y es este FW el que se comunica con el router Mitrastar. Al router Mitrastar solo le llega un cable de red. No uso el DHCP del router Mitrastar sino que tengo un servidor DHCP en la LAN que ofrece este servicio (y les provee de un servidor DNS interno a la LAN que sale a Internet por una línea distinta). El router mitrastar ve venir todo el tráfico desde una sola IP  (por lo que tuve que aumentarle el valor de Max NAT/Firewall Session Per User a 8192 ya que el FW del router Mitrastar descartaba conexiones). Dado que 95 personas navegando generan un tráfico considerable, descarto que el problema aparezca según la cantidad de tráfico diario que se usa en la parte WAN del router. Aunque ahora que lo pienso, como no usamos la línea de teléfono de esa FFTH, podría estar ocurriéndome este problema en este router y no darme cuenta, ya que no uso los servicios del router Mitrastar, solo su acceso a Internet (y con el router mitrastar de mi casa ya he comprobado que puedo seguir navegando si no uso el servidor DHCP del mistrastar). Mañana miraré a ver si va la línea de teléfono y si me puedo conectar al mitrastar. En el router mitrastar tengo desactivada la Wifi.

 

En otro caso tengo otro router Mitrastar conetado a una VLAN distinta en la que usa su acceso a Internet un número variable de equipos (para hacer pruebas y como acceso a Internet de una wifi de visitas). En este caso tampoco uso el servidor DHCP del mitrastar (uso el mismo servidor DHCP que en el caso anterior), pero en este caso no tengo un Firewall con NAT entre los equipos y el router mistrastar: el router recibe el tráfico directamente de los equipos de la LAN. En este caso tampoco usamos la línea de teléfono de esta FFTH, por lo que podría estar teniendo el mismo problema y no haberme enterado. También tengo desactivada la Wifi de este router, y también le llega 1 solo cable de red al router.

 

Mañana comprobaré si estos 2 routers también dejan de ofrecer sus servicios.

 

Mensaje 378 de 991
2.351 Visitas
djbill
Yo probé el VDSL

En el primer caso, en el que tienes un Firewall de por medio, yo directamente quitaba el router y conectaba directamente la ONT al FW y que sea el firewall el encargado de todo. ¿como lo ves?

Mensaje 379 de 991
2.292 Visitas
e_zitro
Yo probé el VDSL

@Theliel Aprovecho tu invitación a evidenciar otros problemas de este Router y te presento uno que he visto en el blog, que ahora me sucede a mí y que parece que nadie da solución, salvo cambiar de Router.

 

La cuestión es la siguiente:

Desde hace 15 días que me sustituyeron el anterior Router (un Teldat 1104) por avería, he perdido el protocolo Bonjour que utiliza Apple para dialogar.con las impresoras. Los síntomas son que se pierde la configuración de los MacBook por WiFi con las impresoras, y si bien se pueden conectar por IP fija, NO se puede utilizar ni el Scanner ni el FAX que la impresora posee.

Otro inconveniente, es la imposibilidad de imprimir desde iPad/iPhone a través de AirPrint/ePrint activados en los Apple y en la impresora respectivamente, porque utilizan el protocolo Bonjour que este Router normalmente ignora.

Siendo este protocolo una variante del de DNS, no sé que filtro hace que no retransmita estos paquetes por WiFi.

Te agradecería me dieras alguna pista para poder tratar de solventar este problema, que como digo no es sólo mío.

Saludos

e_zitro

Mensaje 380 de 991
2.285 Visitas
taker59
Yo probé el VDSL

Se sabe algo del supuesto nuevo firmware B22?

Mensaje 381 de 991
2.270 Visitas
Swapper
Mi vida cambió con el ADSL

El caso 1 que tenía que comprobar (router Mitrastar con firmware B21 que usan para navegar más de 95 equipos): no he podido hacer la prueba del teléfono, ya que en este caso el teléfono está conectado a la ONT (Huawei ONT HG824OH) y no al router, pero sí he comprobado que podía acceder al router, aunque el último reinicio era de hace 6 días (la web del router marcaba un uso de memoria del 34%). En este caso tenemos activado el servidor DHCP del router, aunque no se usa porque el único equipo que conecta a él es un Firewall (y un portátil que uso para hacer la prueba). Iré probando a conectarme a este router en los próximos días para ver si también sufre el mismo problema.

 

El caso 2 que tenía que comprobar (router Mitrastar con firmware B21 que usamos para pruebas): sí que tenía el problema. He comprobado que podía salir a Internet a través de él (usando otro servidor DHCP y DNS que tenemos,  tenemos el servidor DHCP del router desactivado), pero no podía llamar por el teléfono que estaba conectado al router (la ONT es ONT-GG1100), ni me respondía la interficie web del router. Lo he reiniciado y ya he podido llamar por teléfono y acceder a la interficie web del router. Así que en este router también tengo el problema, aunque por la configuración de la red que uso, no estábamos sufriendo las consecuencias.

Mensaje 382 de 991
2.248 Visitas
Swapper
Mi vida cambió con el ADSL

@djbill La verdad es que no me había planteado lo de eliminar el router Mitrastar simplemente porque no he mirado cómo hacerlo. Hace años, cuando Telefonica ponía los routers 3COM812, por sus limitaciones con la tabla NAT los pasaba a monopuesto y accedía a ellos a través de un Firewall, no se si sería algo parecido lo que necesitaría para eliminar el router mitrastar y conectar directamente a la ONT, buscaré información por si me animo.

 

Mensaje 383 de 991
2.239 Visitas
Theliel
Yo probé el VDSL

@e_zitro lo cierto es que no tengo mucho para poder probar mdns, quizás el Chromecast, pero no recuerdo a ver visto ninguna interacción errática entre ellos. Tampoco existe que yo sepa filtrados para DNS, con lo que debería de funcionar bien. Puedo echar un ojo pero ya te digo que sin poder probar mucho...

 

 



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 384 de 991
2.232 Visitas
e_zitro
Yo probé el VDSL

Efectivamente debería funcionar bien porque no se ve ningún filtro para DNS, pero el caso es que no funciona.

La cuestión es que en algún momento a aparecido la impresora, creí que lo había solucionado al cambiar la seguridad WPS de TKIP a AES, pero no fué así, porque despues desapareció y ahora no aparece nunca.

 

Gracias por el interes

Saludos

e_zitro

 

Mensaje 385 de 991
2.211 Visitas
madralphw
Yo probé el VDSL

Buenos días,

 

Van 6 días sin problemas aparentes (en mi caso sin wifi,sin nat, sin pppoe,vamos solo la parte VoIP y enrutamiento estático):


Password:# uptime
10:31:04 up 6 days, 18:44, load average: 3.67, 3.70, 3.70
# free
total used free shared buffers
Mem: 125672 51832 73840 0 4092
Swap: 0 0 0
Total: 125672 51832 73840

 

Parece que se ha estabilizado en consumo de memoria.

Me falta probar la otra parte del provider que tengo en mente que este finde no pude.

 

 

Saludos 😉 

Mensaje 386 de 991
2.079 Visitas
Theliel
Yo probé el VDSL

Aun así @madralphw tan solo 52MB libres y usándolo csai sólo como bridge es muchisimo, es posible que vaya bajando más lentamente o que el problema se dispare intermitentemente o a saber



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 387 de 991
2.067 Visitas
madralphw
Yo probé el VDSL

Hola @Theliel,

 

Son 73840 libres, los otros son usados, pero aún así es mucho, por poner un ejemplo el router mikrotik que tengo puesto tiene 100MB libres de 128:

/system resource> print
uptime: 1w3d17h7m28s
version: 6.33 (stable)
build-time: Nov/06/2015 12:49:27
free-memory: 100.7MiB
total-memory: 128.0MiB
cpu: MIPS 74Kc V4.12
cpu-count: 1
cpu-frequency: 600MHz
cpu-load: 0%

 

La pena que no se pueda obtener el firmware del fabricante sin modificaciones, al final son chapucillas a medida encargadas a vete a saber quien termina implementado.... 

Además otro punto de fallo de estos equipos es la poca calidad de los transformadores, en cuanto deje de ser estable o fluctue, puede hacer cosas raras en el equipo, además con la diferencia de consumo usando wifi + puerto ata para teléfono, de un estado en reposo.  Por lo menos es de 12v 1.(algo, no recuerdo ahora)A, fácil de sustituir.

 

 

Saludos 😉 

 

Mensaje 388 de 991
2.045 Visitas
Theliel
Yo probé el VDSL

ups, tienes razón, lo leí al revés.

 

No son las modificaciones. Realmente quitando las personalizaciones de Movistar, que no son muchas, el resto es lo común a cualquier router. Son pocos los componentes a nivel de binarios que están modificadio específicamente para Ellos. Que evidentemente pueden ser la causa de los problemas, pero yo me incluo más a que son problemas propios. Por ejemplo, el problema de los cuelges es debido a cfg_manager, componente que sí fue actualizado en la B21, y creo recordar que es totalmente agnóstico a los ISP. Y así la mayoría de fallos. Es Movistar quien le dice a Mitrastar como quiere sus cosillas y listo

 

 



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 389 de 991
2.035 Visitas
e_zitro
Yo probé el VDSL

@Theliel No creo que con Chromecast se pueda ver mucho de este problema, como poco se necesitaría una impresora capaz de imprimir AirPrint (las de HP lo llaman ePrint) a ser posible multifunción, un iPad/iPhone o en su defecto un MacBook, toods conectados a la misma red mediante WiFi.

Claro que en esa situación, es dificil ver que pasa con WireShark o cualquier otro Sniffer. 

En cualquier caso yo sigo trabajando para ver si termino de descifrar una captura que hice con WireShark en un momento que funcionó y en el que aparecen por primera vez protocolos IPP, MDNS con respuestas sobre la impresora y SRVLOC con direcciones de una red 224.0.0 y 224.0.1

Saludos

Mensaje 390 de 991
1.973 Visitas
madralphw
Yo probé el VDSL

Hola @e_zitro,

 

Yo he comprobado que a veces al tocar reglas/conf, se desactiva partes de las reglas o no se cargan correctamente (vamos limpia la tabla y la vuelve a cargar bien o mal a veces), en ese intervalo hay un momento que no hay reglas...

Quita las reglas y desactiva el firewall y el ddos y prueba a ver (reincia después, por igual el cambio no se aplica bien).

 

 

Saludos 😉 

Mensaje 391 de 991
1.956 Visitas
e_zitro
Yo probé el VDSL

Hola @madralphw,

Desde luego debe ser algo así, porque si hago un restore del fichero .cfg que hacía un momento no funcionaba, vuelve a aparecer la impresora, que después desaparece.

Seguiré probando.

Gracias

 

Mensaje 392 de 991
1.938 Visitas
Theliel
Yo probé el VDSL

@e_zitro puedo conectarle mi impresora WIFI, si funciona a través de ZeroConfig/mdns podría probar en condiciones que está pasando, pero no te garantizo que pueda...



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 393 de 991
1.924 Visitas
zadkyn
Yo probé el VDSL

a mi me pasa que si lleva el router encendido un hora o dos y me conecto con un portatil windows 10 al wifi router empiezan a cargar las paginas lentas se quedan mucho tiempo en blanco y aveces ni carga, a alguien mas le pasa? que puede ser? estoy cansando ya de este router.

Mensaje 394 de 991
1.908 Visitas
madralphw
Yo probé el VDSL

Hola @e_zitro,

 

Bueno puedes hacer una cosa.... guarda en un fichero el contenido de iptables -L -n -v

Y luego haz iptables -F (borra todas la reglas).

Si te funciona borrando todas las reglas... eso que hay alguna que filtra, cuelga el fichero por ahí y le hecho un ojo a ver si doy con el filtro en cuestión.

 

Un saludo 😉 

Mensaje 395 de 991
1.880 Visitas
e_zitro
Yo probé el VDSL

Hola @madralphw

 

Yo ya había echado un vistazo a la iptables y no había visto nada raro, de todas formas te las envío para que las veas y me digas si tu ves algo.

 

# iptables -L -n -v
Chain INPUT (policy ACCEPT 23 packets, 6670 bytes)
pkts bytes target prot opt in out source destination
3387 455K VOIP_INPUT tcp -- * * 0.0.0.0/0 0.0.0.0/0
37090 13M VOIP_INPUT udp -- * * 0.0.0.0/0 0.0.0.0/0
40620 13M CWMP_CR all -- * * 0.0.0.0/0 0.0.0.0/0
40623 13M DOS_INPUT all -- * * 0.0.0.0/0 0.0.0.0/0
40621 13M DHCP_RELAY all -- * * 0.0.0.0/0 0.0.0.0/0
40621 13M ACL all -- * * 0.0.0.0/0 0.0.0.0/0
40621 13M FrwlInChk all -- * * 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy ACCEPT 58824 packets, 7517K bytes)
pkts bytes target prot opt in out source destination
0 0 TCPMSS tcp -- * eth0.3 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
2269 145K TCPMSS tcp -- * ppp100 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
0 0 RETURN udp -- !br+ * 0.0.0.0/0 0.0.0.0/0 destination IP range 224.0.0.0-239.255.255.255
0 0 DROP udp -- !br+ !br+ 0.0.0.0/0 0.0.0.0/0 udp dpt:68
116K 42M DOS_FORWARD all -- * * 0.0.0.0/0 0.0.0.0/0
58824 7517K Parental_Ctrl all -- br+ * 0.0.0.0/0 0.0.0.0/0
116K 42M UPNP_PRE all -- * * 0.0.0.0/0 0.0.0.0/0
116K 42M ADDRMAP_FORWARD all -- * * 0.0.0.0/0 0.0.0.0/0
116K 42M ipfilter_chain all -- * * 0.0.0.0/0 0.0.0.0/0
8933 1245K url_filter_chain tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 80
113K 42M app_filter_chain tcp -- * * 0.0.0.0/0 0.0.0.0/0
3002 270K app_filter_chain udp -- * * 0.0.0.0/0 0.0.0.0/0
116K 42M PORT_FORWARDING all -- * * 0.0.0.0/0 0.0.0.0/0
116K 42M DEFAULT_SERVER all -- * * 0.0.0.0/0 0.0.0.0/0
58824 7517K FrwlForwardInChk all -- br0 * 0.0.0.0/0 0.0.0.0/0
56859 35M FrwlForwardInChk all -- ppp100 * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 198K packets, 21M bytes)
pkts bytes target prot opt in out source destination
198K 21M FrwlOutChk all -- * * 0.0.0.0/0 0.0.0.0/0

Chain ACL (1 references)
pkts bytes target prot opt in out source destination

Chain ADDRMAP_FORWARD (1 references)
pkts bytes target prot opt in out source destination

Chain CWMP_CR (1 references)
pkts bytes target prot opt in out source destination

Chain DEFAULT_SERVER (1 references)
pkts bytes target prot opt in out source destination

Chain DHCP_RELAY (1 references)
pkts bytes target prot opt in out source destination

Chain DOS_FORWARD (1 references)
pkts bytes target prot opt in out source destination

Chain DOS_INPUT (1 references)
pkts bytes target prot opt in out source destination

Chain FrwlForwardInChk (2 references)
pkts bytes target prot opt in out source destination
56859 35M ACCEPT all -- ppp100 * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 DROP tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:23
0 0 DROP udp -- br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:23
0 0 DROP tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:161
0 0 DROP udp -- br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:161
58824 7517K FrwlOutChk all -- br0 * 0.0.0.0/0 0.0.0.0/0
0 0 FrwlOutChk tcp -- ppp100 * 80.58.63.128/25 0.0.0.0/0 tcp dpt:7547
0 0 FrwlOutChk icmp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 FrwlOutChk tcp -- ppp100 * 80.58.63.128/25 0.0.0.0/0 tcp dpt:22
0 0 FrwlOutChk tcp -- ppp100 * 172.20.25.0/24 0.0.0.0/0 tcp dpt:22
0 0 FrwlOutChk tcp -- ppp100 * 172.20.45.0/24 0.0.0.0/0 tcp dpt:22
0 0 FrwlOutChk tcp -- ppp100 * 193.152.37.192/28 0.0.0.0/0 tcp dpt:22
0 0 FrwlOutChk tcp -- ppp100 * 80.58.63.128/25 0.0.0.0/0 tcp dpt:443
0 0 FrwlOutChk tcp -- ppp100 * 172.20.25.0/24 0.0.0.0/0 tcp dpt:443
0 0 FrwlOutChk tcp -- ppp100 * 172.20.45.0/24 0.0.0.0/0 tcp dpt:443
0 0 FrwlOutChk tcp -- ppp100 * 193.152.37.192/28 0.0.0.0/0 tcp dpt:443
0 0 LOG tcp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 limit: avg 6/hour burst 5 LOG flags 0 level 1 prefix `Intrusion -> '
0 0 DROP all -- ppp100 * 0.0.0.0/0 0.0.0.0/0
58824 7517K FrwlOutChk all -- * * 0.0.0.0/0 0.0.0.0/0

Chain FrwlInChk (1 references)
pkts bytes target prot opt in out source destination
773 236K ACCEPT all -- ppp100 * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
602 110K ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
197 15948 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
1883 97916 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 520
0 0 DROP tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:23
0 0 DROP udp -- br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:23
0 0 DROP tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:161
0 0 DROP udp -- br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:161
33612 12M ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp -- ppp100 * 80.58.63.128/25 0.0.0.0/0 tcp dpt:7547
6 268 ACCEPT icmp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 ACCEPT tcp -- ppp100 * 80.58.63.128/25 0.0.0.0/0 tcp dpt:22
0 0 ACCEPT tcp -- ppp100 * 172.20.25.0/24 0.0.0.0/0 tcp dpt:22
0 0 ACCEPT tcp -- ppp100 * 172.20.45.0/24 0.0.0.0/0 tcp dpt:22
0 0 ACCEPT tcp -- ppp100 * 193.152.37.192/28 0.0.0.0/0 tcp dpt:22
0 0 ACCEPT tcp -- ppp100 * 80.58.63.128/25 0.0.0.0/0 tcp dpt:443
0 0 ACCEPT tcp -- ppp100 * 172.20.25.0/24 0.0.0.0/0 tcp dpt:443
0 0 ACCEPT tcp -- ppp100 * 172.20.45.0/24 0.0.0.0/0 tcp dpt:443
0 0 ACCEPT tcp -- ppp100 * 193.152.37.192/28 0.0.0.0/0 tcp dpt:443
99 4984 LOG tcp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 limit: avg 6/hour burst 5 LOG flags 0 level 1 prefix `Intrusion -> '
3545 251K DROP all -- ppp100 * 0.0.0.0/0 0.0.0.0/0

Chain FrwlOutChk (13 references)
pkts bytes target prot opt in out source destination

Chain PORT_FORWARDING (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- ppp100 * 0.0.0.0/0 192.168.1.33 udp dpts:8001:8008
1 40 ACCEPT tcp -- ppp100 * 0.0.0.0/0 192.168.1.33 tcp dpts:8001:8008

Chain PORT_SCAN (0 references)
pkts bytes target prot opt in out source destination

Chain Parental_Ctrl (1 references)
pkts bytes target prot opt in out source destination

Chain UPNP_PRE (1 references)
pkts bytes target prot opt in out source destination

Chain VOIP_INPUT (2 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- eth0.3 * 0.0.0.0/0 10.23.129.250 udp dpt:5060
0 0 ACCEPT udp -- eth0.3 * 0.0.0.0/0 10.23.129.250 udp dpt:5060

Chain app_filter_chain (2 references)
pkts bytes target prot opt in out source destination

Chain ipfilter_chain (1 references)
pkts bytes target prot opt in out source destination

Chain url_filter_chain (1 references)
pkts bytes target prot opt in out source destination

Saludos

 

Mensaje 396 de 991
1.835 Visitas
e_zitro
Yo probé el VDSL

Hola de nuevo @madralphw

 

Curiosamente en el momento que te he enviado el resultado de iptables, la impresora NO estaba visible en AirPrint, pero al poco tiempo si ha aparecido.

En ese momento he realizado una nueva conexión con el router y obtenido una nueva salida de iptables que paradójicamente es distinto a lo obtenido un momento antes.

Te adunto el nuevo output

# iptables -L -n -v
Chain INPUT (policy ACCEPT 23 packets, 6670 bytes)
pkts bytes target prot opt in out source destination
5872 667K VOIP_INPUT tcp -- * * 0.0.0.0/0 0.0.0.0/0
40585 13M VOIP_INPUT udp -- * * 0.0.0.0/0 0.0.0.0/0
46608 14M CWMP_CR all -- * * 0.0.0.0/0 0.0.0.0/0
46611 14M DOS_INPUT all -- * * 0.0.0.0/0 0.0.0.0/0
46609 14M DHCP_RELAY all -- * * 0.0.0.0/0 0.0.0.0/0
46609 14M ACL all -- * * 0.0.0.0/0 0.0.0.0/0
46325 14M FrwlInChk all -- * * 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy ACCEPT 68560 packets, 8681K bytes)
pkts bytes target prot opt in out source destination
0 0 TCPMSS tcp -- * eth0.3 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
2639 169K TCPMSS tcp -- * ppp100 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
0 0 RETURN udp -- !br+ * 0.0.0.0/0 0.0.0.0/0 destination IP range 224.0.0.0-239.255.255.255
0 0 DROP udp -- !br+ !br+ 0.0.0.0/0 0.0.0.0/0 udp dpt:68
138K 47M DOS_FORWARD all -- * * 0.0.0.0/0 0.0.0.0/0
68560 8681K Parental_Ctrl all -- br+ * 0.0.0.0/0 0.0.0.0/0
138K 47M UPNP_PRE all -- * * 0.0.0.0/0 0.0.0.0/0
138K 47M ADDRMAP_FORWARD all -- * * 0.0.0.0/0 0.0.0.0/0
138K 47M ipfilter_chain all -- * * 0.0.0.0/0 0.0.0.0/0
10888 1594K url_filter_chain tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 80
135K 47M app_filter_chain tcp -- * * 0.0.0.0/0 0.0.0.0/0
3639 328K app_filter_chain udp -- * * 0.0.0.0/0 0.0.0.0/0
138K 47M PORT_FORWARDING all -- * * 0.0.0.0/0 0.0.0.0/0
138K 47M DEFAULT_SERVER all -- * * 0.0.0.0/0 0.0.0.0/0
68560 8681K FrwlForwardInChk all -- br0 * 0.0.0.0/0 0.0.0.0/0
69820 38M FrwlForwardInChk all -- ppp100 * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 207K packets, 24M bytes)
pkts bytes target prot opt in out source destination
207K 24M FrwlOutChk all -- * * 0.0.0.0/0 0.0.0.0/0

Chain ACL (1 references)
pkts bytes target prot opt in out source destination
284 15069 acl_chain tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 80,443,23,21,22,161,53
0 0 acl_chain udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 80,443,23,21,22,161,53
0 0 acl_chain icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8

Chain ADDRMAP_FORWARD (1 references)
pkts bytes target prot opt in out source destination

Chain CWMP_CR (1 references)
pkts bytes target prot opt in out source destination

Chain DEFAULT_SERVER (1 references)
pkts bytes target prot opt in out source destination

Chain DHCP_RELAY (1 references)
pkts bytes target prot opt in out source destination

Chain DOS_FORWARD (1 references)
pkts bytes target prot opt in out source destination

Chain DOS_INPUT (1 references)
pkts bytes target prot opt in out source destination

Chain FrwlForwardInChk (2 references)
pkts bytes target prot opt in out source destination
69820 38M ACCEPT all -- ppp100 * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 DROP tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:23
0 0 DROP udp -- br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:23
0 0 DROP tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:161
0 0 DROP udp -- br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:161
68560 8681K FrwlOutChk all -- br0 * 0.0.0.0/0 0.0.0.0/0
0 0 FrwlOutChk tcp -- ppp100 * 80.58.63.128/25 0.0.0.0/0 tcp dpt:7547
0 0 FrwlOutChk icmp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 FrwlOutChk tcp -- ppp100 * 80.58.63.128/25 0.0.0.0/0 tcp dpt:22
0 0 FrwlOutChk tcp -- ppp100 * 172.20.25.0/24 0.0.0.0/0 tcp dpt:22
0 0 FrwlOutChk tcp -- ppp100 * 172.20.45.0/24 0.0.0.0/0 tcp dpt:22
0 0 FrwlOutChk tcp -- ppp100 * 193.152.37.192/28 0.0.0.0/0 tcp dpt:22
0 0 FrwlOutChk tcp -- ppp100 * 80.58.63.128/25 0.0.0.0/0 tcp dpt:443
0 0 FrwlOutChk tcp -- ppp100 * 172.20.25.0/24 0.0.0.0/0 tcp dpt:443
0 0 FrwlOutChk tcp -- ppp100 * 172.20.45.0/24 0.0.0.0/0 tcp dpt:443
0 0 FrwlOutChk tcp -- ppp100 * 193.152.37.192/28 0.0.0.0/0 tcp dpt:443
0 0 LOG tcp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 limit: avg 6/hour burst 5 LOG flags 0 level 1 prefix `Intrusion -> '
0 0 DROP all -- ppp100 * 0.0.0.0/0 0.0.0.0/0
68560 8681K FrwlOutChk all -- * * 0.0.0.0/0 0.0.0.0/0

Chain FrwlInChk (1 references)
pkts bytes target prot opt in out source destination
802 245K ACCEPT all -- ppp100 * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2576 287K ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
203 16466 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
1990 103K ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 520
11 688 DROP tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:23
0 0 DROP udp -- br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:23
0 0 DROP tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:161
0 0 DROP udp -- br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:161
37057 13M ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp -- ppp100 * 80.58.63.128/25 0.0.0.0/0 tcp dpt:7547
6 268 ACCEPT icmp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 ACCEPT tcp -- ppp100 * 80.58.63.128/25 0.0.0.0/0 tcp dpt:22
0 0 ACCEPT tcp -- ppp100 * 172.20.25.0/24 0.0.0.0/0 tcp dpt:22
0 0 ACCEPT tcp -- ppp100 * 172.20.45.0/24 0.0.0.0/0 tcp dpt:22
0 0 ACCEPT tcp -- ppp100 * 193.152.37.192/28 0.0.0.0/0 tcp dpt:22
0 0 ACCEPT tcp -- ppp100 * 80.58.63.128/25 0.0.0.0/0 tcp dpt:443
0 0 ACCEPT tcp -- ppp100 * 172.20.25.0/24 0.0.0.0/0 tcp dpt:443
0 0 ACCEPT tcp -- ppp100 * 172.20.45.0/24 0.0.0.0/0 tcp dpt:443
0 0 ACCEPT tcp -- ppp100 * 193.152.37.192/28 0.0.0.0/0 tcp dpt:443
106 5304 LOG tcp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 limit: avg 6/hour burst 5 LOG flags 0 level 1 prefix `Intrusion -> '
3677 260K DROP all -- ppp100 * 0.0.0.0/0 0.0.0.0/0

Chain FrwlOutChk (13 references)
pkts bytes target prot opt in out source destination

Chain PORT_FORWARDING (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- ppp100 * 0.0.0.0/0 192.168.1.33 udp dpts:8001:8008
1 40 ACCEPT tcp -- ppp100 * 0.0.0.0/0 192.168.1.33 tcp dpts:8001:8008

Chain PORT_SCAN (0 references)
pkts bytes target prot opt in out source destination

Chain Parental_Ctrl (1 references)
pkts bytes target prot opt in out source destination

Chain UPNP_PRE (1 references)
pkts bytes target prot opt in out source destination

Chain VOIP_INPUT (2 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- eth0.3 * 0.0.0.0/0 10.23.129.250 udp dpt:5060
0 0 ACCEPT udp -- eth0.3 * 0.0.0.0/0 10.23.129.250 udp dpt:5060

Chain acl_chain (3 references)
pkts bytes target prot opt in out source destination
3 156 ACCEPT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 multiport dports 80 source IP range 0.0.0.0-223.255.255.255
0 0 ACCEPT udp -- br0 * 0.0.0.0/0 0.0.0.0/0 multiport dports 80 source IP range 0.0.0.0-223.255.255.255
280 14873 ACCEPT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 multiport dports 23 source IP range 0.0.0.0-223.255.255.255
0 0 ACCEPT udp -- br0 * 0.0.0.0/0 0.0.0.0/0 multiport dports 23 source IP range 0.0.0.0-223.255.255.255
0 0 ACCEPT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 multiport dports 21 source IP range 0.0.0.0-223.255.255.255
0 0 ACCEPT udp -- br0 * 0.0.0.0/0 0.0.0.0/0 multiport dports 21 source IP range 0.0.0.0-223.255.255.255
0 0 ACCEPT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 multiport dports 53 source IP range 0.0.0.0-223.255.255.255
0 0 ACCEPT udp -- br0 * 0.0.0.0/0 0.0.0.0/0 multiport dports 53 source IP range 0.0.0.0-223.255.255.255
0 0 ACCEPT icmp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 icmp type 8 source IP range 0.0.0.0-223.255.255.255
0 0 ACCEPT icmp -- eth0.3 * 0.0.0.0/0 0.0.0.0/0 icmp type 8 source IP range 0.0.0.0-223.255.255.255
0 0 ACCEPT icmp -- br0 * 0.0.0.0/0 0.0.0.0/0 icmp type 8 source IP range 0.0.0.0-223.255.255.255
0 0 ACCEPT tcp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 source IP range 80.58.63.129-80.58.63.190
0 0 ACCEPT udp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 source IP range 80.58.63.129-80.58.63.190
0 0 ACCEPT tcp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 source IP range 172.20.25.1-172.20.25.254
0 0 ACCEPT udp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 source IP range 172.20.25.1-172.20.25.254
0 0 ACCEPT tcp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 source IP range 172.20.45.1-172.20.45.254
0 0 ACCEPT udp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 source IP range 172.20.45.1-172.20.45.254
0 0 ACCEPT tcp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 source IP range 193.152.37.193-193.152.37.206
0 0 ACCEPT udp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 source IP range 193.152.37.193-193.152.37.206
0 0 ACCEPT tcp -- eth0.3 * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 source IP range 80.58.63.129-80.58.63.190
0 0 ACCEPT udp -- eth0.3 * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 source IP range 80.58.63.129-80.58.63.190
0 0 ACCEPT tcp -- eth0.3 * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 source IP range 172.20.25.1-172.20.25.254
0 0 ACCEPT udp -- eth0.3 * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 source IP range 172.20.25.1-172.20.25.254
0 0 ACCEPT tcp -- eth0.3 * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 source IP range 172.20.45.1-172.20.45.254
0 0 ACCEPT udp -- eth0.3 * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 source IP range 172.20.45.1-172.20.45.254
0 0 ACCEPT tcp -- eth0.3 * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 source IP range 193.152.37.193-193.152.37.206
0 0 ACCEPT udp -- eth0.3 * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 source IP range 193.152.37.193-193.152.37.206
0 0 ACCEPT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 source IP range 0.0.0.0-223.255.255.255
0 0 ACCEPT udp -- br0 * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 source IP range 0.0.0.0-223.255.255.255
0 0 ACCEPT tcp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 source IP range 80.58.63.129-80.58.63.190
0 0 ACCEPT udp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 source IP range 80.58.63.129-80.58.63.190
0 0 ACCEPT tcp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 source IP range 172.20.25.1-172.20.25.254
0 0 ACCEPT udp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 source IP range 172.20.25.1-172.20.25.254
0 0 ACCEPT tcp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 source IP range 172.20.45.1-172.20.45.254
0 0 ACCEPT udp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 source IP range 172.20.45.1-172.20.45.254
0 0 ACCEPT tcp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 source IP range 193.152.37.193-193.152.37.206
0 0 ACCEPT udp -- ppp100 * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 source IP range 193.152.37.193-193.152.37.206
0 0 ACCEPT tcp -- eth0.3 * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 source IP range 80.58.63.129-80.58.63.190
0 0 ACCEPT udp -- eth0.3 * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 source IP range 80.58.63.129-80.58.63.190
0 0 ACCEPT tcp -- eth0.3 * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 source IP range 172.20.25.1-172.20.25.254
0 0 ACCEPT udp -- eth0.3 * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 source IP range 172.20.25.1-172.20.25.254
0 0 ACCEPT tcp -- eth0.3 * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 source IP range 172.20.45.1-172.20.45.254
0 0 ACCEPT udp -- eth0.3 * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 source IP range 172.20.45.1-172.20.45.254
0 0 ACCEPT tcp -- eth0.3 * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 source IP range 193.152.37.193-193.152.37.206
0 0 ACCEPT udp -- eth0.3 * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 source IP range 193.152.37.193-193.152.37.206
0 0 ACCEPT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 source IP range 0.0.0.0-223.255.255.255
0 0 ACCEPT udp -- br0 * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 source IP range 0.0.0.0-223.255.255.255
1 40 LOG all -- !lo * 0.0.0.0/0 0.0.0.0/0 limit: avg 1/min burst 1 LOG flags 0 level 7 prefix `RemoteManagement: Action=DROP Unsecured Client Access Deny '
1 40 DROP all -- !lo * 0.0.0.0/0 0.0.0.0/0

Chain app_filter_chain (2 references)
pkts bytes target prot opt in out source destination

Chain ipfilter_chain (1 references)
pkts bytes target prot opt in out source destination

Chain url_filter_chain (1 references)
pkts bytes target prot opt in out source destination
#

Mensaje 397 de 991
1.832 Visitas
madralphw
Yo probé el VDSL

Hola @e_zitro,

 

¿Así que cuando pasa un rato se añade más reglas solo? o ¿Eso pasa al rato de iniciarse? 

 

Puedes volcar también:

 

# ip add

# brctl show 

 

Llevo media mirando las diferencias y no veo nada que tenga que caparlo y a mi me da que va a ser tema wifi, que no es estable, es decir, hay señal parece que se conecta, pero no llega/procesa el tráfico. (A pesar de que indica calidad suficiente). Si acercas la impresora al router, ¿Desaparece el problema? 

 

 

 

Mensaje 398 de 991
1.808 Visitas
e_zitro
Yo probé el VDSL

Hola @madralphw

 

Efectivamente en las iptables no se ve nada que pueda estar filtrando el protocolo Bonjour (5353) que el que se ocupa de este dialogo.

La impresora está a menos de un metro del router y con una señal magnífica

Este es el resultado de lo que me has pedido.

Trying 192.168.1.1...
Connected to router.
Escape character is '^]'.
Login: 1234
Password:
>sh
Password:#
# ip add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: imq0: <NOARP,UP,LOWER_UP> mtu 16000 qdisc pfifo_fast qlen 11000
link/void
3: imq1: <NOARP> mtu 16000 qdisc noop qlen 11000
link/void
4: ifb0: <BROADCAST,NOARP> mtu 1500 qdisc noop qlen 32
link/ether 7a:41:d9:1d:0d:98 brd ff:ff:ff:ff:ff:ff
5: ifb1: <BROADCAST,NOARP> mtu 1500 qdisc noop qlen 32
link/ether a6:68:18:69:50:40 brd ff:ff:ff:ff:ff:ff
6: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
7: ip6tnl0: <NOARP> mtu 1460 qdisc noop
link/tunnel6 :: brd ::
8: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether e0:41:36:5c:fd:78 brd ff:ff:ff:ff:ff:ff
inet6 fe80::e241:36ff:fe5c:fd78/64 scope link
valid_lft forever preferred_lft forever
9: ra0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether e2:41:36:5c:fd:78 brd ff:ff:ff:ff:ff:ff
inet6 fe80::e041:36ff:fe5c:fd78/64 scope link
valid_lft forever preferred_lft forever
10: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether e0:41:36:5c:fd:78 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global br0
inet 192.168.249.1/30 brd 192.168.249.3 scope global br0:0
inet 1.1.1.1/24 brd 1.1.1.255 scope global br0:9
inet6 fe80::e241:36ff:fe5c:fd78/64 scope link
valid_lft forever preferred_lft forever
11: ra1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether e2:41:36:5c:fd:79 brd ff:ff:ff:ff:ff:ff
12: ra2: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether e2:41:36:5c:fd:7a brd ff:ff:ff:ff:ff:ff
13: ra3: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether e2:41:36:5c:fd:7b brd ff:ff:ff:ff:ff:ff
14: wds0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether e2:41:36:5c:fd:78 brd ff:ff:ff:ff:ff:ff
15: wds1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether e2:41:36:5c:fd:78 brd ff:ff:ff:ff:ff:ff
16: wds2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether e2:41:36:5c:fd:78 brd ff:ff:ff:ff:ff:ff
17: wds3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether e2:41:36:5c:fd:78 brd ff:ff:ff:ff:ff:ff
18: eth0.3281@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether e0:41:36:5c:fd:78 brd ff:ff:ff:ff:ff:ff
inet6 fe80::e241:36ff:fe5c:fd78/64 scope link
valid_lft forever preferred_lft forever
19: eth0.3282@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether e0:41:36:5c:fd:78 brd ff:ff:ff:ff:ff:ff
inet6 fe80::e241:36ff:fe5c:fd78/64 scope link
valid_lft forever preferred_lft forever
20: eth0.3283@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether e0:41:36:5c:fd:78 brd ff:ff:ff:ff:ff:ff
inet6 fe80::e241:36ff:fe5c:fd78/64 scope link
valid_lft forever preferred_lft forever
21: eth0.3284@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether e0:41:36:5c:fd:78 brd ff:ff:ff:ff:ff:ff
inet6 fe80::e241:36ff:fe5c:fd78/64 scope link
valid_lft forever preferred_lft forever
22: eth0.3286@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether e0:41:36:5c:fd:78 brd ff:ff:ff:ff:ff:ff
inet6 fe80::e241:36ff:fe5c:fd78/64 scope link
valid_lft forever preferred_lft forever
23: eth0.3287@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether e0:41:36:5c:fd:78 brd ff:ff:ff:ff:ff:ff
inet6 fe80::e241:36ff:fe5c:fd78/64 scope link
valid_lft forever preferred_lft forever
24: eth0.6@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc prio
link/ether e0:41:36:5c:fd:78 brd ff:ff:ff:ff:ff:ff
inet6 fe80::e241:36ff:fe5c:fd78/64 scope link
valid_lft forever preferred_lft forever
25: eth0.3@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc prio
link/ether e0:41:36:5c:fd:78 brd ff:ff:ff:ff:ff:ff
inet 10.23.129.250/19 brd 10.23.159.255 scope global eth0.3
26: ppp100: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1480 qdisc pfifo_fast qlen 3
link/ppp
inet 88.5.196.64 peer 192.168.144.1/32 scope global ppp100
inet6 2a02:9100:e038:cca4:e241:36ff:fe5c:fd78/64 scope global dynamic
valid_lft forever preferred_lft forever
inet6 fe80::e241:36ff:fe5c:fd78/10 scope link
valid_lft forever preferred_lft forever
#
# brctl show^M
bridge name bridge id STP enabled interfaces^M
br0 8000.e041365cfd78 no ra0^M
ra1^M
ra2^M
ra3^M
eth0.3281^M
eth0.3282^M
eth0.3283^M
eth0.3284^M
eth0.3286^M
eth0.3287^M

telnet> Connection closed.

Mensaje 399 de 991
1.798 Visitas
madralphw
Yo probé el VDSL

Hola @Theliel,

 

Pues sí, he conseguido conectar otro provider (cuidado con las contraseñas que no acepta caracteres la interfaz web, como ocurre en la clave wifi). Ocurre también algo parecido a la interfaz web para la pagina del dhcp, si faltan campos no registra, aunque si te acepta los cambios.

 

 SIP Status

AccountRegistrationLast RegistrationURLMessage WaitingLast Incoming NumberLast Outgoing Number
SIP1Up6 day(s), 4:39:129xxxxxxxxxx@telefonica.net0xxxxxxxxxxxxxxxxxxxxx
SIP2Disabled0:00:00ChangeMe@telefonica.net0N/AN/A
SIP3Up0 day(s), 0:08:59201@192.168.2.1000200N/A
SIP4Disabled0:00:00ChangeMe@192.168.2.1000N/AN/A

 

Me falta ver si el dial plan (20x@|) que le he puesto funciona... Deja tener 2 extensiones por proveedor. 

 

Edito: no funciona el dialplan :// Probaré con (200@) 

 

 

 

 

Mensaje 400 de 991
1.795 Visitas