Publicado el

nf_conntrack: table full, dropping packet

NetworkingEsta semana me he encontrado con un servidor CentOS con varios mensajes de error como el que sigue, en su fichero de logs messages:

Mar 14 18:55:48 localhost kernel: nf_conntrack: table full, dropping packet.

Ya había visto antes este error, que se solucionaría de forma radical, reiniciando el server, pero por suerte un compañero ya había hecho algo de investigación sobre este mismo problema.

Para empezar, ¿a qué se refiere este problema? Aquí lo explican bastante bien. El Connection Tracking le permite al kernel mantener un seguimiento de todas las conexiones (o sesiones) abiertas con el servidor, y poder así relacionar los paquetes con su correspondiente conexión. Así, Connection Tracking puede entender que dos o más conexiones distintas están «relacionadas». Por ejemplo, cuando se abre una sesión FTP, primero se abre una conexión contra el puerto 21 para iniciar la sesión FTP, y después se abre otra conexión contra el 20 o contra un puerto aleatorio en función de como tengamos configurado el servidor FTP. En cualquier caso, el Connection Tracking se encargaría de marcar ambas conexiones como relacionadas (RELATED).

Continuar leyendo «nf_conntrack: table full, dropping packet»

Publicado el

– Toc, toc. -¡Ocupado!

Busy Hace poco me llamaron diciendo que una determinada página web no funcionaba. Efectivamente así era. Entramos en el servidor web en cuestión (Windows con IIS) y probamos de ver la página de bienvenida del IIS, que tampoco funcionaba. Después de algunas comprobaciones, vimos que teniendo el servicio IIS parado (y por tanto sin tener la web publicada), el puerto 80 estaba ocupado por otra aplicación. ¿Pero, por cual? Lo único que sabía, gracias a netstat -an era que efectivamente nuestro puerto 80 estaba escuchando.

Para descubrir qué aplicación nos estaba fastidiando el puerto 80, bajé una aplicación de Microsoft, llamada TCPView , que no nos sirvió para nada. La verdad es que es una herramienta gráfica, que refresca en tiempo real las conexiones de la máquina, pero que no nos mostraba nada sobre determinados puertos, entre ellos, el puerto 80.

Navegando llegué a esta página, donde explicaban como usar netstat para sacar el identificador del proceso (pid) correspondiente a cada conexión. Si lo juntamos con el comando "find", podemos sacar únicamente por pantalla las conexiones que están en estado "escuchando".

netstat -ano | find /i "listening"

Una vez hemos identificado el pid del proceso que nos tiene el puerto 80 ocupado, podemos utilizar una pequeña herramienta llamada PUList , que viene con el Windows 2000 Resource Kit, pero que podemos bajar de forma totalmente independiente (aunque atención, nos pedirá validar Windows). En el ejemplo (sacado directamente de la página del autor del post original), querremos buscar el nombre del proceso (que es lo que devuelve pulist) con pid "6372"

pulist |find /I "6372"

He de decir que el comando find, solo nos ayudará a acotar las salidas de los comandos que realmente necesitamos, que son "netstat -ano" y "pulist".

Con esto podremos identificar el proceso, y hacer una búsqueda en google para saber más sobre él, o directamente, abrir el administrador de tareas para finalizar dicho proceso.

Flickr! Foto por Alaskan Dude