Lo coloco aquí porque ni idea de dónde sería el sitio idóneo en hispasonic.
En resumen, para los que tengan modem/router adsl comtrend hg536+
mayoritariamente jazztel y estén notando últimamente que el p2p se lo come, o que tras unas horas navegando intensamente, ya no está como antes.
Hay un bug en el linux (busibox) que tiene, para más delito en la última actualizacion, que hace que la tabla ip_dst_cache no haga más que inflarse hasta que colapsa o se arrastra. En teoría, con un telnet y un "echo 1 > /proc/sys/net/ipv4/route/flush" soltaría lastre, pero ese es el bug que tiene el puñetero. No solo está afectado este router, si buscaís en google "bug ip_dst_cache" vereís los linux y firmwares afectados.
Solución:
Telnet a tu router, cuando te sale el menú, escribe "sh" y en la línea de cónsola que aparece, le pegas para ejecutar:
echo 8192 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
echo 50 > /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout
echo 10 > /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 60 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
echo 120 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
echo 30 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 9 > /proc/sys/net/ipv4/tcp_keepalive_probes
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_icmp_timeout
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_last_ack
echo 16384 > /proc/sys/net/ipv4/route/max_size
echo 4 > /proc/sys/net/ipv4/route/gc_elasticity
echo 1 > /proc/sys/net/ipv4/route/gc_interval
echo 32 > /proc/sys/net/ipv4/route/gc_thresh
se puede discutir más o menos sobre los parámetros, quizá el 16384 al /proc/sys/net/ipv4/route/max_size me he pasado un poco, pero tal como lo he puesto.... Mano de santo.
El coñazo es que cada vez que apagues el chisme tienes que volver a ejecutar esto, pero bueno, yo lo hago de uvas a peras. No he querido perder más el tiempo si alguién se anima que lo explique.
En resumen, para los que tengan modem/router adsl comtrend hg536+
mayoritariamente jazztel y estén notando últimamente que el p2p se lo come, o que tras unas horas navegando intensamente, ya no está como antes.
Hay un bug en el linux (busibox) que tiene, para más delito en la última actualizacion, que hace que la tabla ip_dst_cache no haga más que inflarse hasta que colapsa o se arrastra. En teoría, con un telnet y un "echo 1 > /proc/sys/net/ipv4/route/flush" soltaría lastre, pero ese es el bug que tiene el puñetero. No solo está afectado este router, si buscaís en google "bug ip_dst_cache" vereís los linux y firmwares afectados.
Solución:
Telnet a tu router, cuando te sale el menú, escribe "sh" y en la línea de cónsola que aparece, le pegas para ejecutar:
echo 8192 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
echo 50 > /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout
echo 10 > /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 60 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
echo 120 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
echo 30 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 9 > /proc/sys/net/ipv4/tcp_keepalive_probes
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_icmp_timeout
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_last_ack
echo 16384 > /proc/sys/net/ipv4/route/max_size
echo 4 > /proc/sys/net/ipv4/route/gc_elasticity
echo 1 > /proc/sys/net/ipv4/route/gc_interval
echo 32 > /proc/sys/net/ipv4/route/gc_thresh
se puede discutir más o menos sobre los parámetros, quizá el 16384 al /proc/sys/net/ipv4/route/max_size me he pasado un poco, pero tal como lo he puesto.... Mano de santo.
El coñazo es que cada vez que apagues el chisme tienes que volver a ejecutar esto, pero bueno, yo lo hago de uvas a peras. No he querido perder más el tiempo si alguién se anima que lo explique.
