Me gustaría compartir con todo el mundo la solución que he encontrado con el problema de este Router y el emule cuando hay muchas conexiones o bien se usa la red Kademlia. Como algunos sabréis este Router (y me imagino que esto es aplicable a otros routers del mismo fabricante, e incluso de otros fabricantes) está basado en Linux. Pues bien, he descubierto que el problema reside en que por firwmare está limitado a una cantidad máxima de conexiones NAT. Si se excede ésta, el router se cuelga y la conexión deja de responder.
Para solucionar esto, debéis hacer telnet al router:
- telnet 192.168.1.1
Entonces como login: root y como password: admin (el que tengáis en la web del router si lo cambiáis). Entonces llegareis al terminal Linux del router:
BusyBox v0.61.pre (2004.07.21-12:17+0000) Built-in shell (ash)
Enter ‘help’ for a list of built-in commands.
El archivo que tenemos que cambiar en cuestión es el siguiente (si haceis un cat
vereis el valor que tiene):
# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max 1024
Lo queremos cambiar a 2048:
# echo 2048 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
Et voilà! Teóricamente os deberían desaparecer las inestabilidades (probad a meter 400-500 conexiones con el emule a ver que tal). Teoricamente el router soporta un valor maximo de ip_conntrack_max de 2500 pero yo recomiendo probar con 2048.
Ya podéis hacer un exit. La mala noticia es que este cambio se pierde cada vez que apagáisel router 🙁 Para que fuera permanente habría que guardarlo en el firmware y de momento no se como hacerlo todavía.
Espero que os ayude como me ha ayudado a mi, comentaros que he puesto en contacto con Dlink a ver si sacan un Firmware para corregir esto.
PD. Si quereis podeis ver cosas wais en la consola:
Si hacéis un cat /proc/cpuinfo vereis información sobre la pequeña CPU que lleva el router 🙂 y si haceis un cat /proc/version veréis la versión
de linux que corre 🙂
Actualización del tutorial
He continuado investigando sobre la arquitectura NAT de linux y he llegado a conclusiones importantes. La primera es que mi anterior solución al problema de la estabilidad de sus routers y programas p2p que consistía en incrementar el tamaño máximo de entradas NAT de 1024 a 2048 era incorrecto. Si bien esto me ayudó a aumentar el tiempo que tardaba el router en saturarse, no era más que un mero parche temporal que retrasaba lo inevitable: la saturación de la tabla NAT. Pero después de investigar en documentación técnica, foros y otras fuentes de información he llegado a una solución que parece definitiva y efectiva.
Básicamente el problema no está en el tamaño de la tabla NAT en si mismo sino en que se juntan dos problemas: por un lado, el programa p2p en cuestión (p.e.emule) lanza una cantidad de masiva de conexiones, muchas de las cuales se quedan en un estado «established» pero sin tráfico alguno, las denominadas conexiones fantasma, que se van acumulando y acumulando y acumulando, pueden comprobar esto con el siguiente comando:
#cat /proc/net/ip_conntrack | grep «tcp» -c (para conexiones TCP) #cat /proc/net/ip_conntrack | grep «udp» -c (para UDP, emule usa de este tipo tb)
Prueben a lanzar el programa p2p en cuestión y a monitorizar periódicamente las conexiones, verán que comienzan a aumentar y aumentar sin parar hasta que llegan al limite (por defecto, 1024 para mi DLink 504T) y el router se cuelga.
Para rematarlo del todo se ha juntado con un segundo problema: los timeouts de limpieza de la tabla NAT que incorpora por defecto el router son muy largos, demasiados largos para un aparato de estas características, miren por ejemplo:
#cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established 432000
Si miran la documentación Linux, este valor se mide en segundos, lo cual significa (sí, sí) que el router tarda 5 días (!) en limpiar la tabla NAT de conexiones «established» fantasma. Como digo este, digo otros timeouts que son demasiado largos. El problema es (sin ánimo de criticar a D-link) que han puesto un kernel Linux a saco en el firmware sin reajustar los valores para adaptarlos a un aparato de esta índole, que tiene una cantidad de RAM limitada (no como equipos PC router que tienen cantidades ingentes de memoria), con ello una cantidad limitada de conexiones máximas (y que los usuarios se encargan de agotar rápidamente). La solución ha sido poner unos timeouts mucho más cortos para que el router limpie periódicamente la tabla NAT:
echo 2048 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
echo 50 > /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout
echo 5 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close
echo 120 >
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
echo 1200 >
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
echo 120 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
echo 60 >
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
echo 10 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
Si comprueban ahora con el primer comando mencionado, la cantidad de conexiones activas TCP/UDP verán que se mantienen dentro de un rango aceptable, puesto que el router limpia activamente todas aquellas conexiones que ya no son necesarias a intervalos cortos de tiempo.