Je ne suis pas sur que ça ait un rapport, mais je sais que le mien de mldonkey causait la saturation de /proc/net/ip_conntrack. En effet mon kernel avec iptables garde en memoire l'état d'un nombre limité de connections pour mettre à disposition des règles de filtrage supplementaires. Mais lorsque ce nombre est atteint, il ne peut plus stocker l'état des nouvelles connections (ceci dit je ne pense pas que ça les droppait pour autant) et il se peut donc que dans certains circonstances et en présence de certaines règles de filtrage, certaines paquets soient interdits d'accès. Ce comportement peut paraitre aléatoire car les connections stockée dans ip_conntrack ont une durée de vie et lorsqu'elle est atteinte, elles laissent un peu de place pour de nouvelles connections. Du coup on peut avoir l'impression que ça marche aléatoirement. Pour résoudre mon problème, j'ai comme toi limité le nombre de connections que mldoney pouvait effectuer et j'ai augmenté la valeur de /proc/sys/net/ipv4/ip_conntrack_max
Ceci dit, il y a de grandes chances que ce problème n'ait rien à voir avec le tien car il ne me semble pas que le réseau local était perturbé. Mais il se peut qu'il le soit avec certaines configs de iptables qui limitent également le transfert local... Mais ça me parait tout de meme tiré par les cheveux. Serge Hartmann said: > bonjour, > > je suis un lecteur assidu et silencieux de cette liste. > > j'espère que parmi vous, certains auront une piste à me proposer pour un > problème de réseau lié à mldonkey 2.5.4. > > quand le démon mldonkey tourne depuis quelques minutes au moins, j'ai > affaire à de sérieuses interruptions de traffic sur mon interface ethernet > (reliée à un switch + routeur adsl). > > j'ai constaté qu'à chaque fois que je tuais le process mlnet, et quelques > dizaines de secondes le traffic revenait à la normale. > > j'ai tenté de baisser les valeurs réseau de mldonkey (nombre de clients > connectés, de serveurs, bande passante, etc) mais ça n'y fait rien. > > test simple : un ping -a sur une adresse externe (ça me permet de ne pas > garder le regard dessus en permanence) avec un tcpdump host <ip du ping> > pour surveiller. > > étonnant : alors que je croyais envoyer tous les paquets icmp et n'en > recevoir que quelques uns, ce sont les intervalles d'envoi des paquets qui > s'allongent ; autrement dit tous les paquets icmp émis ont une réponse, > mais j'en émets dix fois moins (voire plus du tout si la crise réseau est > importante). > > dans le même temps je n'ai qu'une vingtaine de ports utilisés par mlnet > (netstat -alpe --ip). > > les process mlnet tendent à prendre des ressources cpu quand le problème > arrive, mais rien n'indique que ce soit une cause et pas un effet. > > détail important : une session ssh établie avec une machine distante n'est > pas affectée par le problème, la connexion reste fonctionnelle et les > paquets des sessions existantes passent bien. > en revanche, pas la peine de vouloir accéder à un nouveau site web. > > voir ci-dessous pour ma config mldonkey si besoin. > > quelqu'un aurait-il une idée ? > ou un endroit plus approprié où exposer ce problème ? > > -- > Serge Hartmann > [EMAIL PROTECTED] - cell: +33(0)6 16 56 11 86 > jabber-id : [EMAIL PROTECTED] > > > ~/.mldonkey $ grep -v "(\*" donkey.ini > > port = 4662 > max_connected_servers = 3 > reliable_sources = false > ban_identity_thieves = false > filters = "" > server_black_list = [] > master_server_min_users = 0 > force_high_id = false > update_server_list = true > max_indirect_connections = 300 > donkey_bind_addr = "0.0.0.0" > max_sources_per_file = 500 > server_client_md4 = "8EE64F732C20FBC3A8CB5D1063713B70" > client_md4 = "7F38305D7A0E135C8C779C5242026FDE" > random_order_download = false > > client_name = tpxbrs > allow_browse_share = true > buffer_writes = false > shared_directories = [] > gui_port = 4001 > http_port = 4080 > telnet_port = 4000 > max_hard_upload_rate = 7 > max_hard_download_rate = 50 > allowed_ips = [ > "127.0.0.1"] > enable_overnet = true > enable_bittorrent = true > enable_donkey = true > enable_opennap = true > enable_soulseek = true > enable_gnutella = true > enable_fasttrack = true > enable_directconnect = true > auto_commit = true > smtp_server = "127.0.0.1" > smtp_port = 25 > mail = "" > add_mail_brackets = false > max_concurrent_downloads = 60 > filename_in_subject = true > temp_directory = "/media/mldonkey/temp" > incoming_directory = "/media/mldonkey/incoming" > client_ip = "10.0.0.1" > force_client_ip = false > ask_for_gui = true > start_gui = false > run_as_user = "" > run_as_useruid = 0 > max_opened_connections = 200 > file_completed_cmd = "" > allowed_commands = [ > [ > df; > df]; > [ > ls; > "ls incoming"]] > users = [ > [ > admin; > "31D6CFE0D16AE931B73C59D7E0C089C0"]] > max_upload_slots = 5 > dynamic_slots = false > max_connections_per_second = 10 > > > Linux-Azur : http://www.linux-azur.org > Désinscriptions: http://www.linux-azur.org/liste.php3 > **** Pas de message au format HTML, SVP **** > -- Dario Spagnolo http://www.zaup.org Linux-Azur : http://www.linux-azur.org Désinscriptions: http://www.linux-azur.org/liste.php3 **** Pas de message au format HTML, SVP ****
