voilà, j'ai ce message qui "inonde" actuellement le log firewall de ma passerelle, accompagné de "X messages suppressed", après une recherche sur google, j'ai compris que ceci provenait du noyau 2.4.18 (j'avais gardé le noyau 2.4.7-10 de la RH 7.2 et je n'avais jamais eu ce message), bref après 27 heures d'uptime sur cette machine, je rencontre ce problème... que faut-il faire dans ce cas au niveau du firewall ? (à part virer le logging )

BMOTheKiller a écrit a écrit : voilà, j'ai ce message qui "inonde" actuellement le log firewall de ma passerelle, accompagné de "X messages suppressed", après une recherche sur google, j'ai compris que ceci provenait du noyau 2.4.18 (j'avais gardé le noyau 2.4.7-10 de la RH 7.2 et je n'avais jamais eu ce message), bref après 27 heures d'uptime sur cette machine, je rencontre ce problème... que faut-il faire dans ce cas au niveau du firewall ? (à part virer le logging )

 
moi j'ai eu ça une fois, en poussant un peu trop mldonkey
donc soit tu as un prog qui bouffe méchament de ressources, soit qq'un te flood par je ne sais quelle technique

c'est pas du flood  
 
mais t'as trouvé la conséquencen......  
 
mais bon ça ne me l'a jamais fait avant et pourtant ça fait un p'tit moment que j'ai ce firewall, juste le noyal qui a changé

up.
j'ai ces messages qui me polluent mon /var/log/messages sur mon serveur alors que tout c'est très bien passé jusqu'ici (25 jours d'uptime).
C'est un 2.4.19 qui fait tourner en autres un mldonkey derrière un firewall. Si je stoppe le mldonkey ça s'arrête, mais pourquoi avoir attendu 24 jours (ça le fait depuis hier soir) pour faire chier ?
 
poser un 2.4.20 servira-t-il à quelque chose ? (puisque d'après bmothekiller c'est une défaut lié au kernel.)

<reponse naive> parce que MLdonkey ouvre de plus en plus de connexion vers l'exterieur, et donc le suivi de connexion commence a etre "embouteille" si certaines d'entre elles ne se termine pas correctement</reponse naive>
 
Moi je dis ca, mais je suis pas expert iptables alors je sais pas comment ca fonctionne le ip_conntrack, mais bon ca m'etonnerais pas que ce soir u truc du genre.
 
A tester : relancer le firewall (je parle pas de la machine juste du script iptables)

déjà fait pour le firewall. j'aurais bien décharger/recharger les ip_conntract mais il est en hard dans le noyau
j'y connais rien en iptables mais dans la série question naïve: y a pas moyen de la flusher cette table ? [je sors ?]

Tu peux aussi augmenter la taille de cette table :  
 

j'y avais pensé (elle étais à 4096) mais je m'interrogais sur les conséquences et sur l'efficacité du remède à long terme.
de plus, en faisant un
cat /proc/net/ip_conntrack |wc -l
des paquets commencaient à être oubliés alors que la table ne contenait 'que' 3800 entrées et des brouettes, du coup je me suis également demandé s'il s'agissait bien de la même chose.
 
J'ai passé la valeur à 8192, je teste...

Normalement, il y a un timeout ... sauf que si la connexion est tojours maintenue, le timeout ne se produit jamais et ne libère pas la connexion donc ... en clair, ca veut dire que tu as de plus en plus de connectés via ML Donkey ... ou en tout cas, de plus en plus de connexions volotairement maintenues ...

Petite question à tous ceux qui ont eu des pbs récemment :
Est ce que l'option "IP: TCP Syncookies support" (CONFIG_SYN_COOKIES) est activée à la compil du noyau ?
Et ensuite, est ce que cette option est activée au boot ? (via un echo 1 > /proc/sys/net/ipv4/tcp_syncookies )
Cette option permet de combattre ce que l'on appelle le SYN Flooding ... on sait jamais, ca peut aider ...