taker59 no sé como andarás de tiempo... podrías probar esto?? Lo he testeado con el mío usando el PC para emular un servidor PPPoE y me funciona, pero como siempre sin un entorno real no me la juego a fastidiarle el router a alguno.
En realidad es la misma modificación pero hacerla en dos tramos para que no supere la limitación de 130 caracteres recien descubierta:
dhcp_fix="mkdir /etc/crontabs" dhcp_fix2="echo '* * * * * ebtables -D FORWARD -p ipv4 --ip-proto 17 --ip-source-port 67:68 -j DROP' > /etc/crontabs/admin"
El primero es para crear la carpeta que aún no existirá cuando se ejecute la instrucción. El segundo para crear el con dentro de la misma carpeta donde el daylight time creará su propio cron y lo ejecutará, con lo que así no tenemos que iniciarlo nosotros para que el no lo detenga.
Ojo que no he puesto el cierre de Entry, y dado que el cron se ejecuta una vez por minuto, puede tardar un minuto desde que se levanta la interfaz para empezar a asignar IPs.
Si no casca el router, que no debería, y no funciona, mira a ver las ebtables a ver si la regla está o no está... dale tiempo como digo a que se elimine
Theliel escribió:@taker59 no sé como andarás de tiempo... podrías probar esto?? Lo he testeado con el mío usando el PC para emular un servidor PPPoE y me funciona, pero como siempre sin un entorno real no me la juego a fastidiarle el router a alguno.
En realidad es la misma modificación pero hacerla en dos tramos para que no supere la limitación de 130 caracteres recien descubierta:
dhcp_fix="mkdir /etc/crontabs" dhcp_fix2="echo '* * * * * ebtables -D FORWARD -p ipv4 --ip-proto 17 --ip-source-port 67:68 -j DROP' > /etc/crontabs/admin"El primero es para crear la carpeta que aún no existirá cuando se ejecute la instrucción. El segundo para crear el con dentro de la misma carpeta donde el daylight time creará su propio cron y lo ejecutará, con lo que así no tenemos que iniciarlo nosotros para que el no lo detenga.
Ojo que no he puesto el cierre de Entry, y dado que el cron se ejecuta una vez por minuto, puede tardar un minuto desde que se levanta la interfaz para empezar a asignar IPs.
Si no casca el router, que no debería, y no funciona, mira a ver las ebtables a ver si la regla está o no está... dale tiempo como digo a que se elimine
Ok.Lo he probado en el principal y funciona correctamente ,no sale ninguna entrada en ebtables.
Confrimar que trás el downgrade de B21 a B14, los problemas de reinicios y cuelgues han desaparecido completamente, previamente como comentaís era casi diario el reinicio o cuelgue y en el mejor de los casos pasados unos días.
La pasada semana, antes de cambiar por un AC87U, el Mitrastar con P2P incluido pudo aguantar la semana entera sin problema.
Un saludo y agradecer el trabajo que haceís por la comunidad.
Randolf como te digo es cfg_manager que agota totalmente la RAM. El router funciona y tu conexión a inet también si finalizas cfg_manager (todas sus instancias) y la RAM vuelve toda, si cascase dejarían de funcioanr algunas cosas, pero no habría problema. El bloqueo es porque la RAM se esfuma del todo, la ramfs necesita espacio para funcionar el router y... KO
voy a jugar un buen rato con el mío y cfg_manager a ver si soy capaz primero de finalizarlo correctamente y restaurarlo, así al menos tendríamos un primer posible fix. Y si llega a ser posible, intentar aislar el problema dentro de cfg_manager. Coincide también con que la B14 no parecía tener este problema, y de las pocas cosas que se actualizaron fueron precisamente el binario de cfg_manager, a ver que encuentro, aunque no prometo nada ;)
Buenas,
vamos con los datos de hoy...
# cat /proc/meminfo MemTotal: 125672 kB MemFree: 37592 kB Buffers: 4976 kB Cached: 24820 kB SwapCached: 0 kB Active: 44288 kB Inactive: 22188 kB Active(anon): 36680 kB Inactive(anon): 8 kB Active(file): 7608 kB Inactive(file): 22180 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 36644 kB Mapped: 7872 kB Shmem: 8 kB Slab: 9796 kB SReclaimable: 1132 kB SUnreclaim: 8664 kB KernelStack: 1904 kB PageTables: 820 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 62836 kB Committed_AS: 59004 kB VmallocTotal: 1048180 kB VmallocUsed: 7052 kB VmallocChunk: 1025516 kB
Sigue bajando la cosa... Quizás algo más lento de lo que pensaba, pero ahí sigue..
# uptime 21:42:25 up 2 days, 10:46, load average: 4.46, 4.35, 4.30
Mem: 88184K used, 37488K free, 0K shrd, 4976K buff, 24820K cached Load average: 4.40, 4.35, 4.30 (State: S=sleeping R=running, W=waiting) PID USER STATUS RSS PPID %CPU %MEM COMMAND 112 1234 S 30M 1 1.9 24.9 cfg_manager 2583 1234 S 2488 1 0.4 1.9 tr69 118 1234 S 30M 117 0.3 24.9 cfg_manager 18671 1234 R 348 17868 0.2 0.2 top 117 1234 S 30M 112 0.0 24.9 cfg_manager 4157 1234 S < 2740 1 0.0 2.1 icf.exe 4316 1234 S < 2740 4157 0.0 2.1 icf.exe 4317 1234 S < 2740 4316 0.0 2.1 icf.exe 2803 1234 S 2488 2802 0.0 1.9 tr69 2802 1234 S 2488 2583 0.0 1.9 tr69
Yo apuesto más por un casque del cfg_manager que por agotamiento de la RAM...
Un saludo.
Edito: Veo que hemos contestado a la vez... jajaja
Un reinicio del cfg_manager a las 3 o 4 de la manaña quizás...?
taker59 perfecto!! has podido comprobar si recibe también correctamente por DHCP?? no sé que configuración tendrás ahora con los dos
barcelones encantado. Está lo mejor expliado posible, pero no lo recomiendo si no se sabe minimamente que tocar o como hacerlo, una coma de más accidental es suficiente para que el router no quiera arrancar luego... que le pregunten al bueno de taker59. En esencia es coger la copia de ajustes del router que se puede obtener desde su interfaz web, modificarla como se dice en cada caso y volver a cargarla
Randolf tus datos coinciden perfectamente con los que he podido ver esta noche desde el PC del amigo enric666 el cual tiene que reiniciarlo mas o menos una vez cada 4-5 días. Es cfg_manager, no es como creí en un principio culpa de la ramfs. En su caso cuando lo he visto iba ya con sólo 20MB libres.
Dado que cfg_manager puede estar interactuando con otros componentes, el problema puede estar en él directamente o en algún servicio que el gestione, o un sencillo leak de el mismo. También parece que el problema no es para todos igual, en el caso de eric parece q cada 4-5 días sin excepción, otros son pequeños cortes, otros cada mas tiempo... con lo que la configuración de la red y los servicios que se usan de esta dependen en gran medida... pero lograr diseccionar aun mejor que parte de cfg_manager lo ocasiona, es complicado... me quedan mcuhas pruebas por delante, pero no prometo nada.
Soluciones??
-Vaciar el cache y los buffer ayuda, recupera unos 20-30MB pero no arregla el problema, tan solo serviría para ganar unos días.
-Encontrar la causa exacta, quizás es una opción concreta la que interacciona con cfg_manager... pero esto sera algo mas complicado, al menos como sé que proceso es puedo intentar jugar con él en el mío y reproducir el incremento
-Si se finaliza cfg_manager efectivamente toda la RAM se recupera, pero deshabilita muchos servicios del router que podríamos necesitar. La navegación web no se interrumpe, pero afecta a otras partes. Una solución factible podría ser la creación de un cron que finalice el/los procesos una vez cada 2-3 días y los vuelva a reiniciar, con suerte los servicios se podrían restaurar y hacer como que aquí no ha pasado nada
