Le manuel d'ed2k-gtk-gui: Questions/réponses, trucs et astuces

Page suivante Page précédente Table des matières

## 5. Questions/réponses, trucs et astuces

## 5.1 Foire aux questions (FAQ)

Reportez vous à la FAQ (disponible en anglais, allemand et français) sur la page d'accueil du projet.

## 5.2 Utilisation d'un serveur mandataire pour récupérez la liste de serveurs via http

ndt : serveur mandataire ou relais = proxy

Si vous utilisez un serveur relais pour accèder au web et vous voulez que le GUI l'utilise, avant de démarrer le GUI, positionnez la variable d'environnment "http_proxy" depuis un interpréteur de commandes (ligne de commande) :

> `

>     export http_proxy=http://wwwcache.somehost.net:8080/

> `

Remarquez la barre oblique "/" (slash) à la fin". D'autres programmes comme wget ou lynx utilise la même variable. Vous pouvez vérifier le contenu de celle-ci par la commande `echo $http_proxy`.

Le mieux est probablement de mettre cette commande d'export à la fin de votre fichier ~/.bashrc. Vous n'aurez plus à la tapper avant de démarrer le GUI, la variable d'environnement "http_proxy" sera positionnée à chaque fois que vous vous identifiez sur votre système.

## 5.3 Corruption found in XYZ in at N

Ceci signifie qu'après avoir complètement téléchargé un morceau, la somme de contrôle (checksum) de ce morceau n'est pas bonne.

Ce n'est rien. eDonkey/overnet téléchargera à nouveau ce morceau.

Il s'agit juste d'une corruption de donnée. Il n'y a rien à faire et pas lieu de s'inquièter. Si cela se produit très très souvent, il y a peut être un problème matériel sur votre machine (sur la mémoire, le disque dur, le contrôleur ou le câble IDE, un problème lié à un "overclocking", une surchauffe ou votre système de fichier,...).

## 5.4 Changement du navigateur instancié par le GUI

Par défaut, le GUI cherchera un navigateur sur votre système et utilisera le premier qu'il trouve (Galeon, Konqueror, Mozilla, Netscape, Opera). Si cela ne vous convient pas vous pouvez en changer. Avant de démarrer le GUI, positionnez la variable d'environnement "BROWSER" à partir d'un interpréteur de commandes (ligne de commande) :

> `

>     export BROWSER=/usr/bin/konqueror

> `

Vous devez spécifier un chemin absolu. Vous pouvez retrouver ce chemin en tappant `whereis konqueror` ou `which konqueror` ( ndt, je n'ai pas tout compris : note: `which` might not always find your binary because it has hard-coded paths)

Le mieux est probablement de mettre cette commande d'export à la fin de votre fichier ~/.bashrc. Vous n'aurez plus à la tapper avant de démarrer le GUI, la variable d'environnement "BROWSER" sera positionnée à chaque fois que vous vous identifiez sur votre système.

## 5.5 Personnalisation du script de prévisualisation

Vous pouvez "prévisualiser" les téléchargements avant la fin, à condition que le core et le GUI tournent sur la même machine. Votre core doit être capable de communiquer le contenu des fichiers temporaires x.part au GUI (Les versions récentes du GUI et du core le font).

A la première exécution de la fonction "prévisualisation", le GUI crééra le script `~/.ed2k_gui/ed2k_gui_preview`. Avec un éditeur de texte, vous pouvez modifier ce script à votre convenance.

Comment ça marche. Le GUI appelle le script et lui passe le nom du fichier partiellement téléchargé en tant que paramètre. Il apparaît dans le script comme `$*` qui signifie juste "remplace le par tous paramètres". Le GUI positionne aussi la variable d'environnement `ED2K_PREVIEW_EXTENSION` avec l'extension du fichier en minuscule (il n'est pas très facile de déterminer le type du fichier /mnt/temp/34.part).

Le script compare l'extension avec les cas préconfigurés dans la section `case`, positionne la variable `PREVIEW_BIN` avec le nom du programme et ses options de lancement. Puis il lance le programme. Comme vous pouvez le constater, il est très facile de changer vos visualisateurs et d'ajouter de nouvelles extensions.

A la fin de la prévisualisation, vous devrez appuyer sur Entrée pour fermer la fenêtre xterm. Cette fenêtre sert à montrer la sortie standard du programme de visualisation et vous permet de l'interrompre par ctrl-c, utile par exemple pour mpg123/ogg123.

Si vous voulez que la fenêtre xterm se ferme d'elle même, supprimer les deux lignes du script :

> `

>     echo "Fini.Appuyez sur <entrer> pour fermer cette fenétre"
>     read

> `

Si vous voulez que la fenêtre xterm se ferme juste après l'appel au programme de prévisualisation supprimez les deux lignes ci-dessus et modifier la commande d'appel comme ceci :

> `

>     $PREVIEW_BIN "$*" &

> `

## 5.6 Utilisation des liens ed2k

Merci de vous reporter au paragraphe sur ces liens au le chapitre "utilisation"

## 5.7 Execution d'une commande en fin téléchargement

TODO, see FAQ

## 5.8 Les caractères internationnaux ne s'affiche pas correctement

Si cela se produit pour les noms de fichiers ou de serveurs, cela vient probablement de votre configuration locale. Vous devez la modifier par quelque chose de correcte. Si vous la changer, il est préférable de choisir un jeu de caractère UTF8 plutot qu'un ISO-8859-x (par exemple, de_DE.UTF8 ou similaire).

Cependant, eDonkey2000 et Overnet sont indépendants de la configuration locale : ils ne fournissent pas au GUI ou aux autres clients le jeu de caracères utilisé pour l'encodage des chaines. Ainsi, les noms de fichiers apparaissant dans la fenêtre de résultats peuvent différer de ceux que peuvent voir d'autres clients ayant une configuration de langue différente. Habituellement, ceci ne constitue pas un gros problème.

## 5.9 DNS lookup for servers

TODO, see FAQ

## 5.10 Des choses étranges se produisent avec ma souris à molette. Pourquoi ?

Pourquoi? Je ne sais pas. Peut-être un bug de GTK+. Allez dans l'onglet d'options et assurez vous que l'option "Désactive le double-clic dans les listes" est positionnée. Cela devra résoudre vos problèmes.

## 5.11 La fonction "aperçu" n'est jamais disponible.

La fonction "aperçu" (clic droit dans la liste de téléchargement) est indisponible dans deux cas :

(1) aucune entrée n'est sélectionnée.

(2) Le Gui croit que le core tourne sur une autre machine. Ceci se produit lorsque vous utilisez un nom ou une IP différent de "localhost" ou 127.0.0.1 pour le "nom d'hôte où tourne le core". (remarque: des vérifications plus sophistiquées ont été supprimées à la demande d'utilisateurs). Maintenant, tout ce qui est différent de "localhost" ou "127.0.0.1" est considéré distant.

## 5.12 Utiliser plusieurs clients eDonkey sur différents ordinateurs et partageant les mêmes routeur ou ligne ADSL.

Problème : vous ne pouvez configurer votre routeur pour translater un port que vers une seule adresse, ainsi les autres machines ne peuvent utiliser le même port et avoir un ID élevé.

Solution : exécutez chaque client edonkey sur un port différent (par exemple : un sur 3662, un sur 4662, un sur 5662, un sur 6662, etc.), et configurer votre routeur pour translater chaque port vers la bonne adresse IP. Remarque : vous devez translater un port par client pour avoir un ID élevé.

## 5.13 Disposer de plusieurs core

Vous pouvez exécuter plusieurs cores que vous souhaitez piloter en même temps ou non. Dans ce cas vous pouvez utiliser l'option de lancement "-n" du GUI qui l'exécutera dans une autre "instance". Il utilisera un autre jeu de fichiers de configuration. Pour le premier core lancer le GUI normalement. Pour le second lancer le avec l'option "-n 2". Ainsi, vos statistiques, etc. seront conservées et vous pourrez configurer le GUI pour qu'il se connecte automatiquement au core en question.

## 5.14 Plusieurs connexions GUI à un core.

Ceci est un problème. Un core ne peut être piloté que par un GUI à la fois.

Toutefois, il y a une méthode simple et gratuite pour résoudre ce problème, utilisez VNC. Installez un serveur VNC sur la machine exécutant le core et clients VNC (disponible dur toute sorte de plateformes) sur les machines depuis lesquelles vous voulez piloter le GUI et le core. Maintenant, lancer le GUI sur la même machine que le core. Cela devrait résoudre le problème, en théorie du moins, je n'ai pas essayé moi même.

## 5.15 Un petit script de lancement

Comme j'étais fatigué de changer de répertoire tous les jours, j'ai (Thomas) écrit ce script de démarrage pour eDonkey. Il télécharge une liste récente de serveurs, démarre le core, attend et démarre le GUI.

    #!/bin/sh
    # Script de démarrage d'eDonkey
    # Démarrage d'eDonkey depuis son répertoire, remplacez le avec celui de votre eDonkey!
    cd ~/ablage/edonkey
    # Téléchargement d'une liste de serveur avec un peu d'astuce.
    mv server.met _server.met
    wget http://ocbmaurice.dyndns.org/pl/slist.pl/server.met?download/server-max.met || cp _server.met server.met
    rm _server.met
    # Démarrage d'eDonkey dans une session nommée et détachée "screen" (GNU screen est nécessaire !)
    screen -dmS donkey -- ./donkey - !
    # Autrement :
    # ./donkey - ! &
    # Attendons un peu
    sleep 5
    # Démarrage du GUI
    ed2k_gui -c

## 5.16 Démarrage du core en tâche de fond ou via telnet/ssh

Habituellement, vous ajoutez un "&" à la fin de la ligne de commande et le programme tourne joyeusement en tâche de fond. Avec le client ligne de commande, cela ne fonctionnera pas correctement. Vous aurez des problèmes similaires, si vous démarrez eDonkey depuis une session telnet/ssh (n'utilisez pas telnet, mais ssh!) et voulez le laisser tourner après déconnexion. "nohup" ne fonctionne pas non plus sur quelques systèmes.

La solution magique est l'outil "screen" (certainement déjà installé sur votre machine). Jeter un oeil sur le manuel avec `man screen`. Voici un résumé :

Démarrer eDonkey avec

> `

>     cd /home/joe/ed2k/
>     screen -dmS donk ./donkey0.50.1 - !

> `

La commande "cd" permet de s'assurer que le core utilisera toujours les fichiers de configuration d'un même répertoire (i.e. /home/joe/ed2k/ ici). Sinon, le core écrira et lira ses fichiers de configuration dans le répertoire courant, ce qui pourra engendrer des confusions.

Avec l'option "-", eDonkey peut être piloter par un GUI. Avec "!", eDonkey n'accepte de commande que depuis le GUI, ce qui est nécessaire pour arrêter proprement le core depuis le GUI.

Quitter le pseudo terminal "screen" en pressant d'abord Control-A, puis control-D. Vous devez alors revenir à votre interpréteur de commande.

Pour revenir au pseudo terminal d'eDonkey, tappez :

> `

>     screen -d -r donk

> `

## 5.17 Tous les serveurs disent que je suis derrière un pare-feu (firewalled), mais c'est FAUX.

Cela peut avoir plusieurs causes. Remarquez que "firewalled" ne doit pas être littéralement. "Firewalled" signifie simplement que les autres serveurs ne peuvent se connecter à votre client (le port par défaut est 4662).

L'une des raisons est que vous utilisez réellement un pare-feu sur votre machine ou sur votre passerelle/routeur et qu'il bloque les connexions entrantes depuis le serveur.

Une autre cause peut être que vous utilisez une routeur ADSL ou un autre routeur/passerelle et qu'il réalise un NAT ( = Network Address Translation = IP masquerading = Internet Connection sharing/ICS). Le NAT est utilisé sur de petits réseaux privés pour partager une connexion internet. Dans ce cas l'adresse IP "publique" fournie par votre FAI/ISP est assignée à votre routeur et toutes les machines du réseau privé ont une adresse privée (i.e. 192.168.x.x ou 10.x.x.x). Dans ce cas, vous devez réaliser un translation de port sur le routeur. Vous devez retransmettre le port tcp 4662 vers l'adresse IP de la machine sur laquelle le client eDonkey tourne. Si vous avez plusieurs clients eDonkey sur votre réseau, vous devez les faire tourner sur des ports différents et configurer la retransmission de port pour chacun d'eux sur le routeur.

Finalement, quelques serveurs sont mal configurés et n'autorisent pas les connexions sotrantes vers des ports non-standards. Ces serveurs vous diront toujours que vous êtes "firewalled". Si vous faites tourner eDonkey sur un port non-standard (différent de 4662), ceci peut se produire occasionellement. Cependant, si tous les serveurs disent que vous êtes firewalled, ce ne peut en être pas la cause.

## 5.18 Je dois utiliser un relai (proxy) SOCKS, mais le client ne semble pas le supporter.

Malheureusement, la version actuelle du client ne supporte pas un relai SOCKS. Vous pouvez essayer tsocks, qui permet d'utiliser un relai SOCKS pour les programmes ne le supportant pas nativement. (Il s'agit d'une librairie pré-chargée qui intercepte les appels connect() et les redirige vers un relai SOCKS, etc.).

## 5.19 Si votre connexion ADSL ne réponds plus et surfer sur le web devient une pénitence.

Il se peut qu'après avoir utiliser eDonkey un certain temps, votre connexion semble devenir terriblement lente : vous connecter à un seveur web ou récupérer vos couriels prend tout à coup quelques secondes au lieu de quelques millisecondes.

Tout d'abord, si cela se produit avec quelques serveurs spécifiques indépendamment de l'exécution d'eDonkey, le problème se situe ailleurs. Si vous utilisez PPP-over-Ethernet (PPPoE : modem connecté à votre ordinateur via ethernet), vérifiez le paramètre "MTU" des deux interfaces réseaux pppX et ethX. Si le problème apparaît uniquement quand edonkey envoie massivement, lisez ce qui suit.

En résumé voici le problème. Votre routeur ADSL implémente un mécanisme de file de paquets qui fonctionne simplement : le premier paquet arrivé est le premier envoyé (FIFO = first in, first out). Si la file d'attente est pleine, alors le routeur jète sournoisement et silencieusement les paquets en surplus. c'est tout à fait normal et TCP s'en accomode très bien. Chaque paquet de données reçu par votre ordinateur est acquité par un petit paquet (ACK) afin que l'émetteur sache que la réception s'est déroulé correctement. Ce mécanisme permet de se prémunir contre la perte de données et d'ajuster le débit en fonction de la bande passante. Maintenant, si les envois d'eDonkey ont rempli la file d'attente de votre routeur, les requetes de connexion (SYN) peuvent émise vers le serveurs au bout de plusieurs secondes et cela peut se reproduire sur tous les paquets émis (i.e. la requête HTTP-GET émise par votre navigateur). C'est pour cela que les choses deviennent terriblement lente, votre routeur ne sait pas distinguer les paquets importants des autres. Une partie de votre débit d'émission (128 kb/s = 16 ko/s) est utilisé par les informations administratives (headers = entêtes) des protocoles mis en jeu. Ainsi votre débit d'emission apparant est inférieur et les envois peuvent tout remplir même s'ils semblent largement en dessous de la limite.

Que faire?

Relativement simple : vous désirez quelque chose appelé "qualité de service" (QoS : Quality of Service). Les dernières versions 2.4.x de Linux implémente déjà ce truc. Vous devez vous assurer que votre noyau a bien été compilé avec le support complet de QoS (incorporé ou comme module).

Le principe est simple : s'assurer que la file de paquets du routeur ne déborde jamais. Pour réaliser cela, vous allez mettre en file d'attente les paquets sur votre machine Linux plutot que sur le routeur (remarque : habituellement la connexion machine-routeur étant nettement plus rapide que celle routeur-internet, le noyau Linux envoi immédiatement les paquets au routeur et ils s'entassent sur ce dernier). Maintenant que la file d'attente est gérée par votre noyau Linux, vous pouvez mettre de l'ordre, par exemple donner une priorité plus élevés à une catégorie de paquets. Ainsi ces paquets seront mis en tête de la file et seront émis avant ceux de moindre importance. Personnellement, j'ai marqué les paquets du traffic vers les ports "intéractif" 21, 22, 23, 110 (mais pas 80 parce que beaucoup d'utilisateurs windows configurent eDonkey pour utiliser ce port), le traffic vers mes sites web favoris et tout les petits paquets (SYN or ACK) avec la priorité la plus élevée.

Emmanuel Roger explique bien comment mettre en place ce truc : http://www.prout.be/qos/QoS-connection-tuning-HOWTO.html.

De ma propre expérience, je vous conseille de vous tenir à l'écart des autres HOWTOs (comme : ADSL-Bandwidth-Management-HOWTO), sauf si vous souhaitez un défi. Celui-ci et la plupart des autres HOWTOs trouvés sur ce sujet nécessitent de "patcher" les sources du noyau et d'iptable (par exemple pour l'IMQ-device). La difficulté s'accroit si les patches sont incompatibles avec les dernières versions du noyau ou d'iptable.

Au cas où quelqu'un est interessé, voici un court extrait de script de démarrage ip-table

            ##########################################################
            #
            # Quality of Service (QoS)
            #
            # from http://www.prout.be/qos/QoS-connection-tuning-HOWTO-4.html
            #
            ##########################################################

            # RAZ

            tc qdisc del dev eth1 root 2>/dev/null > /dev/null

            # marquer les paquets plus petits que 500 octets (considérer comme traffic intéractif)
            #
            iptables -t mangle -A OUTPUT -m length --length 0:500 -j MARK --set-mark 3

            # marquer aussi les paquets UDP important
            #
            iptables -t mangle -A OUTPUT -p udp -j MARK --set-mark 3

            # les plus gros paquets sont marqués comme traffic de données
            #
            iptables -t mangle -A OUTPUT -m length --length 500:1500 -j MARK --set-mark 4

            # marquer aussi les paquets ssh/smtp/pop3 comme prioritaire
            # (beaucoup d'eDonkey utilisant le port 80, il est ignoré)

            for i in 22 25 110
            do
                    iptables -t mangle -A OUTPUT -p tcp --dport "$i" -j MARK --set-mark 3
                    iptables -t mangle -A OUTPUT -p tcp --dport "$i" -j TOS --set-tos Minimize-Delay
            done

            # marquer mes sites favoris comme prioritaires.
            #
            # slashdot(new) slashdot.org, www.ct.heise.de,
            #       edonkey2000, jigle.com, jabber.org
            #       google
            #
            for i in "66.35.250.150" "64.28.67.150" "193.99.144.71" \
                            "198.77.34.120" "212.249.10.246" "208.245.212.108" \
                            "216.239.39.101"
            do
                    iptables -t mangle -A OUTPUT -p tcp -d "$i/255.255.255.255" -j MARK --set-mark 3
                    iptables -t mangle -A OUTPUT -p tcp -d "$i/255.255.255.255" -j TOS --set-tos Minimize-Delay
            done

            # marquer tout un sous domaine comme important
            #
            # amazon/imdb - sourceforge.net
            #
            for i in "207.171.166.0" "216.136.171.201"
            do
                    iptables -t mangle -A OUTPUT -p tcp -d "$i/255.255.255.0" -j MARK --set-mark 3
                    iptables -t mangle -A OUTPUT -p tcp -d "$i/255.255.255.0" -j TOS --set-tos Minimize-Delay
            done

            # create root cvq qdisc for our device eth1
            # (NDT : ??)
            tc qdisc add dev eth1 root handle 10: cbq bandwidth 10Mbit avpkt 1000 mpu 64

            # debit de reception = 576 kb/s
            # debit d'emission = 288 kb/s
            #
            # Classe "interactif" = Debit de réception /20 = 29
            # Classe "donnée" = debit d'emission - classe "interactif" = 259
            # mettons ce dernier un peu en dessous par sécurité
            # (nous ne voulons pas qu'un seul paquets reste sur le routeur)
            # => 190, qui est nettement plus petit que la valeur suggérée mais marche mieux pour moi
            #
            # (le MTU de l'interface est à 1500?)
            #
            tc class add dev eth1 parent 10:0 classid 10:1 cbq bandwidth 10Mbit \
                    rate 29Kbit allot 1500 prio 1 maxburst 10 avpkt 100 isolated weight 100

            tc class add dev eth1 parent 10:0 classid 10:2 cbq bandwidth 10Mbit \
                    rate 190Kbit allot 1500 prio 8 maxburst 2 avpkt 1500 bounded weight 1500

            # expliquer au noyau quelle classe de paquets nous voulons envoyer

            tc filter add dev eth1 parent 10:0 protocol ip handle 3 fw flowid 10:1
            tc filter add dev eth1 parent 10:0 protocol ip handle 4 fw flowid 10:2

## 5.20 Message d'erreur "Couldn't create Temp File"

Ceci semble se produire avec les cores récents qui utilisent plus de descipteurs de fichiers (un descripteur pour chaque fichier ouvert ou connexion réseau active) que votre système n'en autorise à votre compte.

Vous pouvez vérifier avec

> `

>     %ulimit -n

> `

le nombre total de descripteurs de fichiers autorisés pour votre compte (prenant en compte tous les programmes et processus qui tournent en même temps).

Vous pouvez changer cette limite en modifiant le fichier /etc/security/limits.conf (sous root) et ajouter une ligne du type :

> `

>     tim     hard    nofile  4096

> `

"tim" est le compte que vous utilisez, "hard" signifie "hard limit" (ndt : limite infranchissable), "nofile" signifie nombre de descripteurs fichiers autorisés et 4096 est la valeur (vous pouvez mettre une valeur supérieure, mais 4096 devrait suffire).

Maintenant, vous devez vérifier encore une chose qui peut différer suivant la distribution. Si vous avez un fichier `/etc/pam.d/common-session`, assurez vous que la ligne suivante est présente :

> `

>     session required        pam_limits.so

> `

Si vous n'avez pas ce fichier alors ajouter la ligne ci-dessus dans `/etc/pam.d/login`. Si vous utilisez gdm/kdm/xdm pour vous connecter, vous devez vérifier si cette ligne est présente dans `/etc/pam.d/kdm` et/ou `/etc/pam.d/xdm`.

Après avoir modifié ces fichiers vous devez vous reconnecter "proprement" (sortir d'X et vous reconnecter sous la console ou xdm/kdm/gdm). Après en lançant "ulimit -n" dans une fenêtre xterm, vous devez avoir la nouvelle limite et résoudre le problème.

Sous Mac OS X, la limite par défaut est apparemment 256 descripteurs de fichiers par utilisateur et bien trop faible pour eDonkey200/overnet. Vous pouvez changer cette limite en tappant :

> `

>     limit descriptors 4096                      (c'est tcsh de MacOSX!)

> `

sur la ligne de commande et lancer depuis cet interpréteur le GUI ou le core (parce que cette limite est seulement héritée par les processus fils, cela ne change pas la limite sur tout le système). Vous pouvez vérifier votre limite en tappant "limit" sur la ligne de commande. (merci à une participation anonyme sur les forums).

La procédure exacte dépend de votre système/distribution. Merci de m'indiquer si cela necéssite des solutions différentes sur d'autres systèmes.

## 5.21 Le GUI ne reconnait pas mon core démarré manuellement!

Tout d'abord, avez vous ajouté l'option "-" (ndt: "-g" pour une version postérieure à v0.51) au lancement du core ? Avec cette option, le core attend sur le port "aport" les connexions d'un GUI. Sans celle-ci, le GUI sera incapable de se connecter, donc le GUI cherche seulement les cores tournant avec cette option.

Ensuite, le GUI s'attends à trouver le core sous un nom "donkey*", "overnet*" ou "cdonkey*". (il ne tient compte que du début du nom). Si vous avez changé le nom du programme, le GUI ne le trouvera pas (comment ferait-il ?).

## 5.22 Je veux creer un tunnel ssh pour la connexion GUI-core, mais le GUI insiste pour trouver un core tournant localement si j'utilise "localhost" ou "127.0.0.1" pour l'extrémité locale de mon tunnel.

Deux solutions simple : soit vous utilisez une adresse IP de l'une des interfaces de votre machine (par ex 192.168.0.2) ou vous ajouter une ligne comme "core.outerspace.world 127.0.0.1" à votre fichier /etc/hosts et mettez "core.outerspace.world" comme nom d'hôte dans la boite de dialogue de connexion.

Ce point ne sera pas corrigé. Le choix d'insister sur présence locale d'un core a été fait sciemment pour faciliter les débuts du newbie moyen.

Remarquez que la "détection de l'exécution d'un core local" fonctionne uniquement sous GNU/Linux avec un système de fichier /proc monté, pour le moment. Les utilisateurs pour les autres systèmes d'exploitation (par exemple *BSD, MacOSX) peuvent envoyer un correctif pour corriger ceci.

## 5.23 Il dit que je suis "firewalled"! Quels ports dois-je retransmettre sur mon routeur ?

Sous Overnet, le port TCP par défaut est 4662 et le port UDP est pris au hasard au démarrage. Toutefois, vous pouvez fixer ce port avec la commande avancée uport. Tappez "!uport 9876" sans les apostrophes dans la zone de saisie et vérifiez avec "!vo" si la configuration a été prise en compte. Après cela overnet utilisera toujours le même port. Vous devez retransmettre le port TCP (4662 par défaut) et le port UDP qui a été fixé.

Sous eDonkey, vous devez juste retransmettre le port TCP (4662 par défaut).

## 5.24 J'ai trouvé un bug - Que dois-je faire ?

Vérifier si vous pouvez le reproduire et/ou comment.

Vérifiez si le bug a déjà été mentionné et si oui s'il est déjà corrigé. Assurez-vous que vous avez regarder tous les bugs sur le système de suivi, pas seulement les bugs non-corrigés.

Si vous savez utiliser CVS, merci de vérifier la dernière version du GUI depuis CVS pour voir si le bug est toujours présent.

Soumettez le bug à project's bug-tracking system avec autant de détails que possible. Si vous avez un compte sourceforge, merci de vous identifier, je pourrai revenir vers vous avec des questions supplémentaires. Sinon, regardez de temps à autre pour voir s'il y a d'autres questions.

## 5.25 Ce GUI me plait beaucoup. Comment puis-je vous remercier ?

Envoyez moi un courriel. Les retours positifs me font toujours plaisir :-)

Autrement, j'ai maintenant une liste de souhaits amazon.co.uk et une liste de souhaits amazon.de si vous voulez me donner un petit quelque chose pour les millions d'heures de travail passées sur le GUI et le core :).

Page suivante Page précédente Table des matières