Alors voici un problème assez tordu que je n'arrive pas à résoudre. Je viens donc ici en espérant avoir un peu plus d'explications...
Bon alors voilà, en utilisant deluge avec un port manuel configuré (port x) dans deluge et sur mon routeur (freebox), je me suis rendu compte qu'il y avait encore du "traffic" ou plutôt des requêtes passant par ce port à l'aide de wireshark lorsque deluge était fermé !
Bon je n'utilise pas deluge en mode démon pour l'instant, donc ce n'était pas ce problème.
J'ai cru que c'était deluge, donc je l'avais désinstallé et remis transmission, mais avec lui idem, j'ai configuré un autre port y, et même quand transmission est fermé, ca génère des requêtes...
Le seul moyen apparemment serait de virer le port dans la configuration du routeur puis d'en mettre un autre...mais ce port est aussitôt encombré par ces nouvelles requêtes
Y compris après un redémarrage de la machine et/ou du routeur...
Voici un post sans réponse qui en parlait http://forum.deluge-torrent.org/viewtopic.php?f=7&t=4355&p=1(...) mais le problème n'est en fait pas relié à deluge lui même...
Voici l'exemple d'une requête (extraits de Wireshark ):
82.40.72.59 192.168.0.11 TCP 4263 > port X [SYN] Seq=0 Win=65535 Len=0 MSS=1460
192.168.0.11 82.40.72.59 TCP port X > 4263 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
...qui arrive régulièrement (au moins une fois par minute) avec une adresse distante et un port qui change presque à chaque fois.
Comment faire pour remédier à ce problème ?
Voici le résultat d'un lsof -i :
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
rpc.statd 5087 statd 5u IPv4 13085 UDP *:1023
rpc.statd 5087 statd 7u IPv4 13093 UDP *:51373
rpc.statd 5087 statd 8u IPv4 13096 TCP *:40403 (LISTEN)
mpd 5111 mpd 4u IPv4 482858 TCP localhost:6600 (LISTEN)
mpd 5111 mpd 15u IPv4 482902 TCP localhost:6600->localhost:59059 (ESTABLISHED)
mpd 5111 mpd 16u IPv4 492980 TCP localhost:6600->localhost:37940 (ESTABLISHED)
/usr/bin/ 5612 user1 15r IPv4 492979 TCP localhost:37940->localhost:6600 (ESTABLISHED)
avahi-dae 5753 avahi 14u IPv4 13850 UDP *:mdns
avahi-dae 5753 avahi 15u IPv4 13851 UDP *:54884
cupsd 5797 root 2u IPv4 13896 TCP localhost:ipp (LISTEN)
cupsd 5797 root 4u IPv4 13899 UDP *:ipp
dhclient 5944 dhcp 6u IPv4 496419 UDP *:bootpc
hddtemp 6217 root 0u IPv4 14245 TCP localhost:7634 (LISTEN)
ntpd 6386 ntp 16u IPv4 497083 UDP *:ntp
ntpd 6386 ntp 17u IPv6 497084 UDP *:ntp
ntpd 6386 ntp 18u IPv6 497086 UDP ip6-localhost:ntp
ntpd 6386 ntp 19u IPv4 497088 UDP localhost:ntp
ntpd 6386 ntp 20u IPv4 497089 UDP 192.168.0.11:ntp
ntpd 6386 ntp 21u IPv6 497109 UDP [::::ipv6 address::::::]:ntp
python 7338 user1 22u IPv4 482900 TCP localhost:59059->localhost:6600 (ESTABLISHED)
Il ne me semble rien voir d'anormal...
C'est ça qui est bizarre, je n'arrive pas à savoir de quelle application ça pourrait venir...
Est-ce que quelqu'un aurait quelques pistes à suivre ?
Merci
# C'est le GPS dans ton alim.
Posté par Barnabé . Évalué à 5.
Tu as fermé ton client, mais il faut du temps avant que ceux qui y accédaient de l'exterieur s'en rendent compte :
82.40.72.59 essaie de se connecter à ton client :
82.40.72.59 192.168.0.11 TCP 4263 > port X [SYN] Seq=0 Win=65535 Len=0 MSS=1460Tu l'envoies chier gentiment, car le client ne tourne pas :
192.168.0.11 82.40.72.59 TCP port X > 4263 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0[^] # Re: C'est le GPS dans ton alim.
Posté par anakin . Évalué à 3.
Ya pas de timeout ?
Merci pour les explications ;)
[^] # Re: C'est le GPS dans ton alim.
Posté par Amand Tihon (site web personnel) . Évalué à 4.
En théorie, ils feront au maximum chacun une tentative et voyant que tu ne réponds plus, en déduiront que tu as fermé ton client et te retireront de leur liste. Ça peut demander du temps avant de se terminer, mais c'est absolument sans conséquences.
[^] # Re: C'est le GPS dans ton alim.
Posté par anakin . Évalué à 1.
La fréquence d'apparition dans le scan de wireshark a d'ailleurs diminué depuis ce matin...
(plus qu'une adresse IP qui envoie apparemment)
Bon c'est vrai que j'avais pas remarqué cas chaque fois c'était d'abord le distant qui faisait la requête en premier...c'est pour ça que j'avais cru à un logiciel corrompu en local qui aurait envoyé des trucs ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.