Err, c'est pas évident du tout d'écrire une FAQ comme on le voudrait. Celle-ci sera consacrée a IRC, et les quelques trucs à savoir qui servent de temps en temps. Je ne me suis pas trop étalé sur des questions de netiquette ou des choses qui ne sont pas assez spécifiques à IRC pour être citées une fois de plus, comme le danger lié à l'exécution de programmes ou de scripts venant d'une source inconnue, etc. Pour d'éventuelles remarques, ajouts ou suggestions, mon adresse email se trouve ici, et comme je n'ai plus rien à dire dans cette sorte d'introduction et que je n'arrive de toute façon pas à écrire comme je le voudrais, voila le Contenu de cette FAQ :
  1. Mais qu'est-ce que "IRC" ?
  2. Quel est l'avantage d'IRC par rapport aux MSN, AIM et autres ?
  3. Avec quoi se connecter sur IRC ?
  4. Ou trouver une liste de serveurs ? Je débute et je ne sais pas où me connecter pour l'instant...
  5. Ce qu'il vaut mieux éviter
  6. C'est quoi ce texte entre astérisques (étoiles) ? A quoi sert la commande /me ?
  7. Les signes : et >
  8. Je suis dans un canal, mais personne ne parle, où même ne me répond !
  9. Pourquoi utiliser la commande /away au lieu de changer de nickname ?
  10. Et elle fait quoi de visible cette commande /away ? Je ne vois rien...
  11. Qu'est-ce que la notify-list ?
  12. Quel jeu de caractères dois-je utiliser ?
  13. Où en savoir plus sur le protocole IRC ?
  14. Pourquoi le serveur tente-t'il de se connecter à mon port 113 quand je me connecte ?
  15. Ça rame, il faut attendre de 20 secondes à une minute avant que la connexion se fasse !
  16. La commande /notice
  17. Qu'est-ce qu'un CTCP ?
  18. Qu'est-ce que les DCC ?
  19. Comment fonctionne un DCC SEND ?
  20. Je ne peux pas envoyer de fichiers, mais je peux en recevoir !
  21. Je ne peux pas recevoir de fichiers !
  22. Faire un DCC à l'envers pour passer la passerelle ?
  23. Mais je suis derrière un routeur, et je peux quand même envoyer des fichiers ?...
  24. Le DCC ne fonctionne toujours pas, ce n'est pas un problème de réseau!
  25. Le "DCC CHAT"
  26. Remerciments :)

  1. Mais qu'est-ce que "IRC" ?

  2. Le sigle IRC signifie "Internet Relay Chat". C'est une sorte de moyen de communication par Internet en temps réel contrairement, par exemple, à Usenet (une sorte de réseau basé sur le protocole NNTP pour transmettre les messages des newgroups)


  3. Quel est l'avantage d'IRC par rapport aux MSN, AIM et autres ?

  4. IRC est un protocole plus libre et plus ouvert, et vous n'êtes pas dépendant d'un seul serveur propriétaire dont on ne vous laisse pas le choix. Vous avez le choix du serveur pour vous connecter, c'est à dire que si demain les serveurs MSN de Microsoft plantent encore... Imaginez si demain, Microsoft décide de fermer son service, vous serez bien dans la merde (ils ont déjà fait ça pour un autre de leurs services un certain 23 février), et pareil pour AIM avec AOL. N'ayez pas confiance ;)

    Ah, au fait, pas besoin d'être forcément dans un canal pour joindre quelqu'un, il suffit de l'avoir dans sa notify-list et ça reviendra au même que dans un client d'IM (liste des personnes en ce moment connectées).


  5. Avec quoi se connecter sur IRC ?

  6. Vu que IRC est un protocole standard, vous avez aussi le choix du client (logiciel tournant sur votre machine), vous en trouverez un à coup sûr pour votre OS favori. :) Il y en a une quantité assez incroyable, et google est votre ami. Vision sous BeOS, mIRC sous Windows (shareware), X-Chat pour linux et windows, vous pouvez aussi programmer le votre ;) Il y a une liste plus complète ici, et il existe aussi Gaim et Kopete, qui sont des clients IM multi-protocole, et qui sont aussi capables de se connecter à IRC. Pour l'anecdote, ça m'est arrivé de me connecter depuis une machine sur laquelle absolument rien n'etait installé en utilisant le telnet minimaliste de Windows 98. :)


  7. Ou trouver une liste de serveurs ? Je débute et je ne sais pas où me connecter pour l'instant...

  8. Par exemple ici, à condition de comprendre cette soupe.


  9. Ce qu'il vaut mieux éviter

  10. En règle générale, un peu de bon sens suffit. Mais il vaut mieux essayer d'éviter d'écrire constamment en majuscules (cela correspond à crier), d'abuser des couleurs, d'envoyer des dessins ascii de 100 lignes dans les canaux, d'abuser des abréviations, les "lol" (je suis sûr qu'il y en a qui ne savent pas que ça signifie "Laughing Out Loud") et "mdr" à répétition, de renvoyer 10 fois la même ligne pour être certain que tout le monde l'ait lu, d'écrire en SMS, des trucs comme ça quoi... :)




  11. C'est quoi ce texte entre astérisques ? A quoi sert la commande /me ?

  12. Une autre manière de s'exprimer sur IRC est de faire une action, c'est à dire d'agir "virtuellement", et on peut aller du simple baillement jusqu'au RP integral ;) Ça peut paraître bizarre, mais si vous voyez du texte entre astérisques, c'est qu'il se passe "devant vous" quelque chose, et cette action est justement décrite par ce texte. Arrêtez de rigoler, ça se fait même parfois dans les sous-titres (Excel Saga! :)
        [Bleûten] Oui, à peine 13000 morts... *s’éloigne en riant*
    Une autre façon d'exprimer la même chose aurait été d'utiliser la commande /me. Elle existe sous pratiquement tout les clients IRC, et elle envoie en fait un ctcp "ACTION", et va afficher cela à l'écran :
        * Bleûten s’éloigne en riant "Oui, à peine 13000 morts..."
    (Cet exemple est tiré de l'épisode 1 du Survivaure, parce que je n'arrivais pas a trouver une idée correcte *va essayer de continuer a écrire cette satanée FAQ*)


  13. Les signes : et >

  14. Souvent, il y a des cas où l'on veut s'adresser à une autre personne, mais il arrive aussi parfois que l'on pose ses pattes pour passer un coucou avec la connexion IRC d'un ami. Pour faire la différence, le signe ":" veut dire que l'on s'adresse à la personne, et le signe ">" veut dire que c'est cette personne qui est en train d'écrire. Un petit exemple:
       [Bleûten] Mac_Gregor: Oui, à peine 13000 morts...
       [Mec] Nana> Bonjour les gars, je suis sa petite amie :)
       [Mec] Nana> Autre_Bonasse: Si tu touches à mon mec, je te mords!
    (j'avais dit que j'etais pas bon pour les exemples !)


  15. Je suis dans un canal, mais personne ne parle, où même ne me répond !

  16. Ils sont peut-être occupés ? Dans ce cas, soyez patient... Je suis bien en train d'écrire une FAQ stupide que personne ne lira jamais, moi ;))


  17. Pourquoi utiliser la commande /away au lieu de changer de nickname ?

  18. Si la commande away existe, ce n'est pas pour rien, et les changements de nickname sont très agaçants pour de multiples raisons, comme avoir des gens dont le nom comporte le mot "douche" ou "dodo" dans le canal, les créations de fichiers de log multiples et de répertoires dans lesquels les fichiers transmis par DCC sont sauvegardés, etc. Et je ne parle même pas de ceux qui comme moi, utilisent la notify-list et que vous allez inonder de lignes supplémentaires à chaque fois.

    Personellement, j'applique (enfin, le client) la "méthode xchat" : Commande /away "raison", puis un ctcp action dans le canal : propre et classe. En script mIRC, ça doit ressembler à ça, à mettre dans les remotes :
    alias away {
        if ($1 != $null) {
            .raw away : $+ $1-
            set %awaytime $ctime
            if ($chan(0) != 0) { 
                ame is away: $1-
            }
        }
        else {
            .raw away
            if (($chan(0) != 0) && ($away != $false)) { 
                ame is back (gone $duration($calc($ctime - %awaytime)) $+ ) 
            }
        }
    }
    Et on n'aura plus à supporter des lignes du genre "SpeedFire|Away is now known as SlowFire|Busy".
    (Edit: Ce script là est plus complet, tant qu'a faire)


  19. Et elle fait quoi de visible cette commande /away ? Je ne vois rien...

  20. Il y a sûrement eu le message "You have been marked as being away" dans votre fenêtre de status.

    Le serveur IRC renvoie un message qui va afficher un truc du genre "Toto is away: parti acheter du pain" si on essaye de vous contacter, c'est quand même assez explicite. ;) Certains clients, comme xchat, affichent même ceux qui sont "away" en grisé dans la nicklist, car l'état de chaque membre d'un canal donné peut être facilement récupéré par /who #nomducanal (espérons qu'ils le fassent tous rapidement, sinon un petit script devrait faire ça très bien)
    JOIN #france
    :User!~user@192.168.1.2 JOIN :#france
    :rontrag 353 User = #france :User Robot @cLx 
    :rontrag 366 User #france :End of /NAMES list.
    WHO #france
    :rontrag 352 User #france ~user 192.168.1.2 rontrag User H :0 User
    :rontrag 352 User #france ~clx rontrag rontrag Robot G :0 Robot
    :rontrag 352 User #france ~kou rontrag rontrag cLx G@ :0 cLx
    :rontrag 315 User #france :End of /WHO list.
    Ceci est le sniff d'un xchat rentrant dans un canal, on peut voir facilement comment il récupère l'état de chaque personne avec la commande WHO, et celles qui sont "away" sont marqués d'un G.


  21. Qu'est-ce que la notify-list ?

  22. Avec les clients de messagerie instantanée, en général on ne rentre dans aucun canal, mais on utilise une liste de personnes qui sont marquées déconnectées ou connectées. Et bien, avec IRC, on peut faire la même chose avec la notify-list. En general, on peut ajouter les gens que l'on veut à la liste avec la commande /notify nomdelapersonne (ou avec les menus du logiciel)

    Le fonctionnement original de la notify-list se servait des requetes ISON que le client faisait au serveur réguliérement, tout changement était signalé, mais ce n'était pas instantanné. Une methode plus performante est donc apparue sur certains serveurs : la requête WATCH, et dans ce cas là, c'est le serveur qui informe instannement le client.


  23. Quel jeu de caractères dois-je utiliser ?

  24. Sur ce point là, la RFC n'impose rien, mais chez nous, en france et un peu autour, c'est plutot ISO-8859-1 (latin1) qui est utilisé, MAIS on voit de l'UTF-8 de plus en plus souvent dans les canaux, et c'est un beau bordel. La version 6.17 de mIRC sait "lire" de l'UTF-8 même si on écrit en latin1.
       No specific character  set is specified. The 
       protocol  is based on a  set of  codes which 
       are composed of eight (8) bits, making up an
       octet.

  25. Où en savoir plus sur le protocole IRC ?

  26. La RFC1459 est une mine de renseignements très utile, complétée par la RFC2810, la RFC2813. Microsoft s'est aussi amusé un peu, et a donné une version un peu spéciale du protocole, appelée IRCX, mais qui reste compatible avec les clients IRC standard (en gros, il y a /prop et /access en plus (qui sont en general remplacés nickserv et compagnie sur des ircd normaux, a l'exception des bots X et W sur Undernet) et ils ont un peu pourris tout avec des trucs du genre %#canal. Ce qui etait bien, c'etait le mode "knock"... mais allez lire le document, je l'ai enfin retrouvé)


  27. Pourquoi le serveur tente-t'il de se connecter à mon port 113 quand je me connecte ?

  28. De très nombreux serveurs IRC essayent de se connecter sur le port 113 à l'adresse du client se connectant au serveur (je sens que je suis pas clair, là), pour voir si il n'y aurait pas un serveur identd qui traine, et dans ce cas, va placer l'information (qui ne fait que quelques caractères de long) juste avant l'adresse IP dans votre userhost. Sinon, l'information utilisée sera celle fournie par le client, précédée d'une tilde. Voir la RFC1413 pour plus d'infos sur le protocole d'identd.


  29. Ça rame, il faut attendre de 20 secondes à une minute avant que la connexion se fasse !

  30. Cela arrive assez souvent quand le port identd (113) de l'ordinateur client, ou de la passerelle utilisée par le client pour se connecter à internet, est bloqué (DROP) par un firewall mal configuré. Le serveur essaye de se connecter dessus (SYN) et attend la réponse, en vain, jusqu'à ce qu'il abandonne (timeout). Pour éviter ça, le port 113 peut être fermé mais pas bloqué, histoire qu'un paquet (RST) informe le serveur IRC que le client a renvoyé une indication de non connexion, et que ce n'est pas la peine d'attendre plus longtemps. On peut aussi s'amuser à faire tourner un serveur identd, ça peut être très amusant et presque tout les clients IRC en ont un integré.

    Solution au problème : ne bloquez PAS le port 113 avec votre firewall.

    Si vous avez un ircd isolé du réseau global dans votre lan, il se peut aussi qu'il essaye de faire une résolution DNS à partir de l'IP du client, pour l'host. Comme le serveur DNS n'est pas accessible, l'ircd va attendre le timeout avant de poursuivre, d'ou un délai.


  31. La commande /notice

  32. La commande /notice envoit un message privé, mais en général, le client IRC d'en face n'ouvre pas de fenetre pour ça, et l'affiche dans la fenetre qui est active, utilisé comme si on voulait chuchotter quelque chose discretement, un peu comme les Whisper sur les MUDs. Certaines personnes ne comprennent pas que l'on s'adresse à elles à la maniére de Dieu ;), et répondent publiquement dans le canal qui etait au premier plan. Il faut y faire attention, parfois. Les notices sont aussi souvent employées par les services (nickserv et compagnie) pour communiquer avec vous.


  33. Qu'est-ce qu'un CTCP ?

  34. C'est un format de message assez spécial, pour envoyer des commandes particulières aux autres clients, souvent par la commande /ctcp, par exemple PING pour tester la connexion, VERSION pour connaître le logiciel utilisé en face, ou TIME pour savoir l'heure. Au niveau de la connexion, c'est un message normal entouré de caractères 0x01 (controle-A) :
    PRIVMSG User :^AVERSION^A
    Les réponses sont à peu près identiques, mais c'est un notice et pas un privmsg qui est utilisé.


  35. Qu'est-ce que les DCC ?

  36. En général sur IRC, tous les clients se connectent au serveur (ou à plusieurs serveurs connectés entre eux), ce dernier s'occupant de faire passer tout les messages aux clients. Pour certaines actions, comme le transfert de fichiers (/dcc send username), il se produit un DCC (Direct Client to Client). Dans ce cas là, un client se connecte directement à l'autre, avec parfois les problèmes de réseaux que ça peut soulever (voir deux paragraphe au dessous). Il est aussi possible de converser en dcc en privé avec la commande /dcc chat username, comme ça ne passe pas par le serveur, il y a des chances pour que ça soit plus rapide car plus direct.


  37. Comment fonctionne un DCC SEND ?

  38. L'expéditeur décide d'envoyer un fichier à un destinataire. Ne me demandez pas pourquoi, je n'en sais rien, tout ce que je sais c'est qu'il veut lui envoyer un fichier ;) Pour se faire, il ouvre un port puis il envoie au destinataire un ctcp l'informant de son offre, et à quel port/adresse IP il faut se connecter, pour que le destinataire, tout content de recevoir un fichier, puisse venir se connecter et commencer a downloader. :)

    Le format du message CTCP est DCC SEND nom_de_fichier adresse_ip port taille. L'adresse IP est au format numérique et la taille du fichier est donnée en octets. Exemple :
    DCC SEND liste.txt 202182159 2117 11776
    Pour convertir une adresse IP a.b.c.d au format numerique, il suffit de faire a*(2^24) + b*(2^16) + c*(2^8) + d


  39. Je ne peux pas envoyer de fichiers, mais je peux en recevoir !

  40. Pas de panique, il peut y avoir deux raisons liées au réseau à ce problème. Comme on peut le voir dans le paragraphe précédent, c'est celui qui envoie le fichier qui donne au destinataire l'adresse où il doit se connecter. Si la machine a plusieurs interfaces, et donc plusieurs adresses, il n'est pas rare de voir le client donner l'adresse d'une carte réseau locale, et ça fera une belle jambe au client d'en face. :) Essayez d'activer "Lookup method: server", ou "Get my IP address from the IRC server", et déconnectez vous, puis reconnectez vous. Pensez aussi aux firewalls logiciels, celui inclu dans XP, etc. qui sont souvent configurés en mode "parano", mais qui empêcheront seulement les connexion entrantes

    L'autre principal problème peut se produire si vous êtes sur un lan et derrière une passerelle (routeur, nat, etc.) pour partager la connexion à internet, ou autre. Au lieu de tomber sur votre machine, le client destinataire essaye de se connecter sur la passerelle, qui elle n'en a pas grand chose à faire, et va refuser la connexion. La solution "propre" est de faire un port-forwarding, c'est a dire de demander à la passerelle de router les connexions vers l'adresse IP locale de l'ordinateur du client IRC. Il faudra définir une plage de ports forwardés, et il faudra configurer le client IRC pour qu'il utilise des ports dans cette même plage. Attention de ne pas prendre des ports inferieurs à 1024 car ils sont réservés à d'autres services, que sous linux il faut être root pour ouvrir ces ports, et que le client IRC d'en face pourrait ne pas être d'accord *insère sa haine envers xchat pour ça ici* ;) Pour l'exemple, on va prendre les ports de 5000 à 6000 inclus, et les router vers l'adresse locale 192.168.0.34 Avec Iptables, sous linux :
    $ iptables -t nat -A PREROUTING -i ppp0 -p tcp \
    	--dport 5000:6000 -j DNAT --to-destination 192.168.0.34
    Et si je me souviens bien, avec nat32 sous windows ça donne :
    > ppmap add tcp 5000:6000 192.168.0.34 5000
    Si tu ne peux vraiment pas toucher à la configuration de la passerelle, c'est dommage, mais il te reste un moyen : initier le DCC dans l'autre sens, ça peut dépanner mais ce n'est pas très standardisé... Et puis deux personnes comme cela (chacune protégée derrière sa passerelle) ne pourront jamais, entres elles, faire de DCC quelque soit le bout par lequel on commence. ;)


  41. Je ne peux pas recevoir de fichiers !

  42. A tout hasard, dis à ton ami de regarder le paragraphe juste au dessus, car vu que tu peux sortir pour te connecter sur le serveur IRC, je ne vois pas pourquoi tu ne pourrais pas te connecter sur lui... Peut-être une daube du genre zone-alarm mal configurée ? (ce programme est forcément mal configuré, puisque de toutes façons celui qui sait configurer un firewall n'utilise pas ce programme ;) </TROLL>

    Sinon, vérifier que l'on ne passe pas par un proxy pour sortir du lan, c'est si c'est le cas, demander au client d'inicier également les connexion DCC a travers le firewall... Vérifier également que l'endroit où vous mettez les fichiers ait de l'espace libre, et qu'il ne soit pas en read-only.


  43. Faire un DCC à l'envers pour passer la passerelle ?

  44. Quand il n'y a vraiment pas moyen de toucher à la configuration du routeur et qu'il est impossible qu'une connexion exterieure remonte dans le LAN et donc, qu'il est impossible d'envoyer un fichier par DCC SEND, il y a une derniere solution, celle de faire un DCC "à l'envers", et ainsi initier la connexion "en sortant", dans le sens avec lequel la passerelle ne posera pas de probleme. Je sais que mIRC est capable de faire ça, les autres clients, je ne sais pas. Celui qui doit recevoir le fichier doit lancer le serveur DCC integré au client (penser à changer le port par défaut au cas où) avec la commande /dccserver.
       /dccserver +sc-f on 2100
    lancera le serveur DCC sur le port 2100, pour les envois de fichiers et les tentatives de discusions, mais pas les fserves (une sorte de serveur de fichiers dont j'ai pas encore envie de parler). De l'autre coté, il suffira de taper la commande /dcc send adresseip:port fichier, dans notre cas, cette ligne suffira :
       /dcc send 12.12.12.12:2100
    Attention, en general, les adresses IP sont alloués dynamiquement par les providers, il y a donc des chances pour que celle-ci change lors de la prochaine connexion. Pour récupérer l'adresse IP d'une personne, il suffit de faire /dns nickname. Si ça ne marche pas sur votre client, faites un /userhost personne et convertissez le host (il est juste derriere le signe @) en adresse IP par une requette DNS, mais si /dns ne marche pas, ça m'étonnerait qu'un tel DCC fonctionne. 0:)


  45. Oui, mais moi, j'ai un routeur et j'ai pas eu configurer quoi que ce soit pour que je puisse envoyer des fichiers!

  46. Deux possibilitées :

    - soit, c'est un routeur UPnP qui "écoute" la connexion et se débrouille pour essayer de faire le lien, comme modifier le port, ou même l'adresse IP dans le CTCP DCC SEND avant de faire un forward temporaire vers le PC client (personnellement, je n'aime pas vraiment, ça fait bidouillage. D'ailleurs, j'ai souvent vu des routeurs casser la connexion IRC à chaque tentative de DCC... Il y a aussi un module linux qui sait faire la même chose, mais je ne l'ai pas essayé)

    - soit, le client IRC que vous utilisez n'est pas trop con et se démerde pour faire un reverse DCC s'il s'aperçoit qu'il est derriére un routeur qui ne forwarde pas. Là, rien n'est standard, mais j'ai vu un truc du genre fonctionner par hasard, avec Visual IRC caché sur un LAN, essayant d'envoyer un fichier à un mIRC. Voila ce que j'en ai reverse ingeneeré :

    "Expediteur" veut envoyer un fichier à "Destinataire". Il lui envoi donc via le réseau IRC, le CTCP suivant :

    PRIVMSG Destinataire :^ADCC SEND Fichier.Ext 3232235742 0 25054972 868^A

    3232235742 est l'adresse IP de Expediteur, soit en forme décodée 192.168.0.222, qui est l'addresse privée de la machine sur le lan. (voir ici pour codage d'une adresse IP). Il lui envoi le port 0, au lieu d'un port valide. 25054972 est la taille du fichier en octets comme pour un DCC SEND classique. On dirait bien que Expediteur sait qu'il n'a pas la possibilité de recevoir les connections de l'extérieur. Il ajoute aussi un identificateur, ici 868.

    "Destinataire" (ici un mIRC curieusement compabible), en voyant ça, ouvre un port dans sa plage autorisée, et lui envoi son adresse IP (3580302164), le port qu'il a ouvert, et recopie la taille du fichier et l'identificateur par CTCP.

    PRIVMSG :Expediteur :^ADCC SEND Fichier.Ext 3580302164 2101 25054972 868^A

    Puis "Expediteur", reconnait grâce au port différent de 0 et l'identificateur (868 dans notre cas) que ce message est relatif au fichier en attente, se connecte sur Destinataire sur le port qu'il lui a indiqué, et envoie le fichier dessus dès que la connexion TCP s'établit, comme un reversedcc un peu automatisé...


  47. Le DCC ne fonctionne toujours pas !

  48. Bon, ce n'est pas un problème de réseau, vous avez tout vérifiés, et ça ne marche toujours pas ?

    Il y a plusieurs causes possibles. Un truc qui m'était arrivé, c'est que le client (un Gaim!) d'en face rejette le DCC dès qu'il commence a recevoir. La cause etait une option, le "FAST DCC" : Le protocole original du DCC dit "on envoit un packet (de taille variable, ça n'a rien à voir avec les packets TCP/IP, ceux là peuvent aller jusqu'a 8Ko facile), on attends le ACK, et on continue à envoyer un autre packet. Pour accélérer, certains clients ont une option pour ne pas attendre le ACK pour envoyer le packet suivant. En général, ça marche, mais il semblerait que certains clients n'aiment pas ça. Solution: Désactiver le "fast dcc send" pour envoyer des fichiers à cette personne.

    Il se peut aussi que l'un de vous deux utilise un client où le DCC n'est pas encore codé (changez de client!)

    Certaines versions de mIRC (dont la 5.8 que j'ai utilisé très longtemps) ne pouvaient pas envoyer de fichier depuis un partage réseau du genre \\machine\partage\repertoire\fichier.ext, la solution est simple, il suffit de monter le disque pour qu'il ait une lettre de lecteur.

    Evidemment, vérifiez que votre disque dur (ou la partition) a encore de l'espace libre, que vous ayez les droits en écriture sur le répertoire destination, etc.


  49. Le "DCC CHAT"

  50. C'est comme un privé normal, a la différence que la connexion ne passe plus par le serveur, mais directement entre les deux clients, comme le DCC SEND. L'avantage est une rapidité plus importante, et une confidentialité plus grande (puisque la connexion ne passe pas par le serveur). L'inconvenient, c'est que on a les mêmes causes de merdages potentielles que pour le DCC SEND.


  51. Remerciments

  52. Merci à LightFox pour avoir testé le script d'away et pour m'avoir dit que mIRC n'appréciait vraiment pas les tabulations dans ses scripts, j'ai vraiment pas de veine, dans tous les autres langages c'est la méthode standard pour faire des indentations, à Hiro pour la ligne de commande Iptables et aussi pour m'avoir fait remarquer tous ces endroits auxquels j'avais oublié des tonnes d'accents (on va dire que c'est la faute aux langages de programmation anglophones tiens ;)

    Si vous avez encore une question sur IRC ou une remarque sur cette FAQ, n'hésitez pas à me contacter par email, je serai ravi de la compléter. :)

    Je jure que c'est la derniere fois que je fais un truc comme ça directement en HTML ! Au début, c'etait seulement du texte, et puis j'ai voulu faire des liens, puis des listes numérotées, et...

    -- cLx
             Dernière modification le 22/10/2010