-------------------------------------------------------------------------------
NoRoute #1  Recuperer des comptes PPP         4767    Hotcode    NoRoute #1
-------------------------------------------------------------------------------



                     Comment recuperer des comptes PPP
                               Par HoTCoDe
                 -----------------------------------------


 J'ai decouvert tout ce qui va suivre sous ma distrib Linux RedHat 4.0, mais
je pense qu'elle doit marcher dans le cas d'autres distributions, voire meme
avec d'autres UN*X. Cependant, j'ai constate que cela ne marchait visiblement
pas pour MkLinux :(

[Sorcery: Voui.. Tout depend du script de connection... =) Si chat est appele
 avec l'option -v lors de la connection, alors toutes ces infos sont loggees
 dans le fichier en question. Remarquez rien ne vous empeche de chopper le 
 root et de lire le script de connection =)] 


-METHODE UN-

 Voila donc... Le probleme se situe au niveau des permissions du fichier
/var/log/messages (ou /var/adm/log/messages, ca depend) qui est en world
readable (o+r). PPP (ma version est la 2.2) notifie toutes ses actions durant
la connexion, et si on regarde bien, on voit qu'il envoie au modem le numero
de telephone du provider, le login et le password correspondant a l'account.
Voici donc ce qui se passe chez moi...

 % cat /var/log/messages | grep "chat"
 (j'ai decoupe ici une seule sequence de connexion, il y en a plusieurs
 dizaines sinon... J'ai aussi modifie les infos, histoire de quand meme
 garder mon compte confidentiel :)

   Feb  9 20:23:40 HoTMaCHiNe chat[924]: expect (OK)
   Feb  9 20:23:40 HoTMaCHiNe chat[924]: ^M
   Feb  9 20:23:40 HoTMaCHiNe chat[924]: ATH0^M^M
   Feb  9 20:23:40 HoTMaCHiNe chat[924]: OK -- got it
1> Feb  9 20:23:40 HoTMaCHiNe chat[924]: send (ATDT0140354512^M)
   Feb  9 20:23:40 HoTMaCHiNe chat[924]: expect (CONNECT)
   Feb  9 20:23:40 HoTMaCHiNe chat[924]: ^M
   Feb  9 20:24:01 HoTMaCHiNe chat[924]: ATDT0140354512^M^M
   Feb  9 20:24:01 HoTMaCHiNe chat[924]: CONNECT -- got it
   Feb  9 20:24:01 HoTMaCHiNe chat[924]: send (^M)
   Feb  9 20:24:01 HoTMaCHiNe chat[924]: expect (ogin:)
   Feb  9 20:24:01 HoTMaCHiNe chat[924]:  115200^M
   Feb  9 20:24:11 HoTMaCHiNe chat[924]: ^M
   Feb  9 20:24:11 HoTMaCHiNe chat[924]: Login: -- got it
2> Feb  9 20:24:11 HoTMaCHiNe chat[924]: send (foo^M)
   Feb  9 20:24:12 HoTMaCHiNe chat[924]: expect (assword:)
   Feb  9 20:24:12 HoTMaCHiNe chat[924]: foo^M
   Feb  9 20:24:12 HoTMaCHiNe chat[924]: Password: -- got it
3> Feb  9 20:24:12 HoTMaCHiNe chat[924]: send (bar^M)

 On voit donc en (1) le numero de telephone envoye (0140354512). En (2), le
login (ici, "foo") et enfin en (3) le pass correspondant, "bar".
 C'est aussi con que ca ! On peut egalement chercher ces infos avec un

 % cat /var/log/messages | grep "send"

 Et on verra toutes les informations envoyees au modem.

-METHODE DEUX-

 La methode deux est plus hypothetique, mais jouable quand meme. J'ai trouve
des becanes ou elle fonctionnait... Hehe !
 Il faut deja trouver les scripts de connexions PPP (ppp-on en general) a l'
aide d'un `find -name "ppp-on" -print'. Sinon, il arrive qu'il soit dans
/etc/ppp ou dans /sbin (ou encore /usr/sbin). Enfin bon, je vais pas vous
macher tout le travail quand meme !
 Il suffit des les recuperer, et si votre cerval fonctionne correctement, vous
aurez compris que toutes les informations de connexion sont a l'interieur, vu
que c'est un script. Donc, vous le dissequez, et la, Oh joie...

 TELEPHONE=0140354512    # The telephone number for the connection
 ACCOUNT=foo             # The account name for logon (as in 'George Burns')
 PASSWORD=bar            # The password for this account (and 'Gracie Allen')
   
 Je vous ai mis ici les scripts d'exemple que j'ai trouve dans
`/usr/doc/ppp<version>/scripts', et que j'utilise pour me connecter, mais je
me doute que vous en avez plutot rien a cirer :)

-CONCLUSiON-

 Voila deux methodes tres simples a mettre en oeuvre, qui ne coutent rien et
qui permettent de recuperer facilement des comptes PPP, ce qui est toujours
utile quand on veut hacker sans trop se faire reperer, en utilisant la
connexion d'un illustre inconnu.
 Enjoy diz phile, continue loving Bernard Menez and have phun !

[Nota deux: =) Dans le deuxieme cas il faut etre root sur la machine en general
 pour avoir acces a ce script ultra confidentiel... Ces deux methodes vous 
 permettent de chopper des logins dans tout cybercafe connecte par telephone
 au net et tournant sous linux... (pratique pour gerer les abos...)]
-------------------------------------------------------------------------------
NoRoute #1  TCP/IP                            4768    Kewl       NoRoute #1
-------------------------------------------------------------------------------

--== Ben kesako c le tcpip ??? ==--


Intro.
=====

Hello tout le monde!

Tout le monde entend parler de TCPIP partout, donc j'y met mon grain de sel 
aussi... (attention faut avoir ca en tete pour capter des choses ki vont 
sortir dans certains numeros de Norout)
En fait, c un protocole qui a ete cree pour pouvoir partager des ressources 
a travers un reseau. Son interet est qu'il peut etre utilise par tout 
type de machine (Sparc, Alpha, Silicon, etc...) et tout type de 
support (X25, Hyperchannel, PPP, FDDI, Ultranet, ...). Nous verrons 
l'exemple d'utilisation d'un pc sous Linux avec un support ethernet.

Protocoles
==========

Ben en fait, on dit toujours TCP/IP mais en fait les protocoles TCP et IP 
sont les plus utilises, si c'etait ICMP et UDP p'etre kon appellerai 
ca ICMP/UDP :o) En fait c pas par hasard, c car il existe une 
hierarchie entre les protocoles.. dont voila un petit dessin ki 
montre ke les RAW sockets permettent l'interfacage a la couche IP, 
ceux du type DGRAM a UDP, ainsi que ceux du type STREAM a la couche TCP.

|------------------|--------------|   Les protocoles utilises sur Internet 
| TELNET      RWHO | RUSERS       |   sont bien decrits par les RFC (Requests 
| FTP         TFTP | RSTAT        |   for Documents), disponibles sur les 
|                  |              |   protocoles sur la gauche de ce texte, 
|                  |              |   et quand on dit pas mal, c pas faux :o)
| RLOGIN      TALK | WALL         |   ftp.ibp.fr/pub/rfc, il decrivent avec 
| RSH          DNS | RQUOTA       |   pas mal de precision. Donc je vais 
|                  |              |   decrires maintenant les principaux 
|                  |              |   protocoles ..
| REXEC       SMNP | NIS          |   
| SMTP             | NFS          |   1. IP
|                  |--------------|      Ben c'est celui a qui on doit le 
|                  |              |      routage et la fragmentation des 
|                  |              |      paquets, il est sans connection.
|                  | XDR          |      Quand on dit routage, en fait on va 
|                  |              |      dir que son boulot est de trouver
|                  |--------------|      trouver le routeur qu'il faut pour 
|                  |              |      atteindre la destination, alors 
|                  |              |      c'est grace a lui que la bonne
|                  | RPC          |      interface est choisie. Donc aussi 
|                  |              |      il gere la fragmentation des
|---------------------------------|      paquets, ben ouais il faut bien, car 
|                                 |      les protocoles superieurs (TCP/UDP) 
|                                 |      sont coupes en fragments IP de tailles
| Socket STREAM      Socket DGRAM |      maximale qui depend de l'interface 
|                                 |      utilisee. En reception, IP reassemble
|---------------------------------|      les fragments. Cette taille depend
|                                 |      (pc de cod4 plante) du support utilise
| RCP                         UDP |      (1500 octets sur l'ethernet et 4352 
|                                 |      sur une fibre optique FDDI).
|---------------------------------|   
|      Interface RAW Socket       |   2. ARP et RARP
|---------------------------------|      ARP = Adress Resolution Protocol, 
|                                 |      il permet de faire une correspondance 
|                                 |      entre une adresse IP de 4 octets 
| ARP            ICMP <------> IP |      (A.B.C.D) vers une forme ethernet 
|                                 |      en 6 octets (A:B:C:D:E:F) et de savoir
|---------------------------------|      quelle carte est sur quelle IP. 
|                                 |      RARP, (Reverse ARP), ben soyons pas 
| ETHERNET   ISO 8802.3     X25-3 |      bete, tout le monde a devine son 
|                                 |      utilite !
-----------------------------------   

3. ICMP
   (cod4 a fait un restore de copine, mouahahahahha top).. Bon disons plutot 
   que ICMP c Internet Control Message Protocol.
   En bref il permet d'analyser les blemes de communications. Grace a lui, 
   on peut aussi savoir si une machine est en marche (ex : ping -s 65000 -f 
   warez.2-go.com). Encore, un routeur peut donner des directives a une
   machine pour lui donner une meilleure route pour atteindre une
   machine (ICMP redirect). ICMP c le protocole regged en tant ke # 1.

4. UDP
   C'est le protocole numero 17. Il est oriente datagramme qui achemine 
   les messages tels quels, sans ouverture de connection, et sans garantie 
   de port egalement. Il peut etre utilise en point a point 
   (vers un seul destinataire), ou en mode diffusion. (arf le pc de cod4
   lui dit kil a un 386sx) En mode diffusion, UDP est utilise par talkd, 
   tftpd et encore NFS.

5. TCP
   TCP = Transmission Control Protocol, il est oriente connexion, dont la 
   vie est l'etablissement de la connection, la transmission des donnees et 
   enfin la liberation de la connection. TCP ramene les segments sans decoupage
   ni regroupement, et garantie le bon port. En cas d'erreur de transmission, 
   ben c'est tout simplement retransmi :), biensur grace a un controle de
   flux. TCP est utilise par les protocoles ftp, telnet, rlogin, lpd, X11.
   TCP est le protocole #6.

Le niveau TCP
=============

Donc TCP est le responsable de la fracture de messages en datagrammes, 
les reassemblant a l'autre bout, dans le meme ordre. IP est le responsable du 
routage de chaque datagramme. On pourrait dire que TCP fait tout le travail, 
dans les petits reseaux cela est vrai, mais sur Internet, envoyer un 
datagramme vers une autre machine n'est pas un simple boulot. Une connection 
peut forcer le datagramme a passer a travers toute une serie de reseaux, 
tels qu'une ligne Serie a 56 kbit/s, ensuite un reseau ethernet pour enfin 
arriver sur une FDDI, etc.. Garder la piste du chemin vers toutes les 
destinations et transporter les incompatibilites de differents medias de 
transport sont un travail pas tres simple... Notons que l'interface entre 
TCP et IP est quand meme assez simple. TCP fait simplement un datagramme 
avec une destination. 

Il ce peut (surement meme), qu'il manque quelque chose ici. On a tous parle 
d'adresses Internet, mais jamais comment gerer des multiples connections 
vers un systeme donne. Clairement, ca suffit pas de faire des datagrammes
vers la bonne destination. TCP doit savoir quel datagramme fait parti ce
cette connection (merci cod4 pour cette phrase). Cette tache est le
demultiplexage. En fait, il y a toute une serie de de demultiplexages
qui vont sur TCP/IP. Les informations dont on a besoin pour ce
demultiplexage sont contenues dans des series de headers. Un header est
simplement quelques tout petit octets places au debut de chaque datagramme
par quelques protocoles dans le but de garder une piste de lui. 
C'est un peu comme mettre une lettre dans une enveloppe et mettre une
adresse a l'exterieur de l'enveloppe. Sauf avec les reseaux modernes
cela arrive souvent. C'est comme quand tu veux mettre une lettre a 
l'interieur d'une enveloppe, ta secretaire la met dans quelque chose
plus gros qu'une enveloppe, puis le service du courier met encore ce truc
plus gros qu'une enveloppe dans un encore plus gros.. Voici un appercu des 
headers qui font coller un message ki passe a travers un reseau TCP/IP :

On commence par une simple donnee, par exemple tu essaies (oui je dis bien 
essaies :>) d'envoyer un fichier vers un autre ordinateur : 

   ...................................................................

TCP lui casse ca en morceaux dont il peut s'occuper. (biensur pour pouvoir 
le faire, il doit savoir quelle taille maximum un datagramme peut avoir sur
ton type de reseau)

   ....   ....   ....   ....   ....   ....   ....   ....   ....   ....

TCP met un header au debut de chaque datagramme. Ce header contient au moins
20 octets, mais les plus importants sont les numeros de ports d'emission
et de destination et le sequence number. Les numeros de port sont
utilises pour garder une piste de differentes conversations. Suppose
voir que trois personnes transferent des fichiers. Ton TCP peut etre leur
donnera les ports numero 1000, 1001 et 1002 pour ces transferts.
Quand tu envoies un datagramme, ca devient le port de source, puisque tu es 
sur la source du datagramme. Et biensur TCP de l'autre extremite a assigne un 
port des siens pour la conversation. Ton TCP doit aussi savoir quel port est
utilise sur l'autre extreme. (Il le trouve quand la communication commence.)
Il envoie ca dans le "champ" port de destination. Biensur si de l'autre cote
est rerenvoye vers toi, les ports de source et de destination seront inverses,
ensuite il sera le source et toi tu seras la destination. Chaque datagramme 
a un sequence number. Ceci est utilise alors l'autre fin afin d'etre sur que
la datagramme a ete recu dans le bon ordre, et qu'en en a loupe aucun. TCP
ne numerote pas les datagrammes (bon cod4 arretes un peu l'irc ca rend fou :),
mais les octets. Donc s'il y a 500 octets de donnees dans chaque datagramme, 
le premier sera "numerote" 0, le second 500, le suivant 1000, le suivant 1500,
etc........ Finalement, on va parler du Checksum (somme de controle). 
C'est un nombre qui est calcule en ajoutant tout les octets du datagramme. 
Le resultat est mit dans le header. TCP de l'autre cote verifie ce checksum
aussi, et si ils ne sont pas d'accord, c'est que kelke chose de mauvais est
apparu lors de la transmission, et il est jete au loin. Voila a quoi
ressemble un petit datagramme :


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Port Source         |      Port de Destination      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Sequence Number                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Acknowledgment Number                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Data |           |U|A|P|R|S|F|                               |
     | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
     |       |           |G|K|H|T|N|N|                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Checksum            |         Urgent Pointer        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   donnees ... prochains 500 octets                            |
     |   ......                                                      |

Si on abregeait l'entete TCP par "T", le fichier ressemblairait a ceci :

    T....   T....   T....   T....   T....   T....   T....

Tu noteras qu'il y a des choses dont j'ai pas parle dans le header..
Ils sont generalement invoques avec la gestion de la connection.
Pour etre sur qu'un datagramme est arrive a sa destination, le receveur as a
renvoyer un "acknowledgement". C'est un datagramme dans lequel le champ
"Acknowledgement number" est rempli. Par exemple, envoyer un paquet avec un 
acknowledgement de 1500 indique que tu as recupere toutes les donnees
jusqu'a 1500. Si l'envoyeur ne recoit pas un acknowledgement dans un delais
raisonnable, il renvoie les donnees. La fenetre (Window) est utilisee pour
controler combien de donnees peuvent transiter a un moment. Il n'est pas
pratique d'attendre que chaque datagramme soit acknowledged avant
d'envoyer le suivant. Et aussi faut dire que ca ralentisserait, et pas qu'un
peu, n'est ce pas sorcery ? D'autre part, tu ne peux pas que envoyer, ou
un ordinateur rapide pourrait subir des indigestions a un plus petit qui
recoit les donnees. Alors il y a un champ "Window", et des qu'un ordinateur
a envoye des donnees, ce champ diminue, et s'il est vide, il arrete d'envoyer.
Quand le recepteur recoit les donnees, il augmente sa fenetre (Window), en
indiquant qu'il est pret a recevoir plus de donnees.

Le niveau IP
============

TCP envoie chaqun de ces datagrammes a la couche IP. Biensur on doit dire a
IP l'adresse de la machine de l'autre bout. Note quand meme que c'est tout ce
qu'IP est concerne de faire. Il s'en fiches de ce qu'il y a dans le datagramme,
ou meme dans le header TCP. Son boulot est simplement de trouver le chemin pour
que le datagramme arrive jusqu'a sa destination. Pour permettre aux routeurs
intermediaires d'envoyer le datagramme, il ajoute son propre header.
La principale chose qu'on y trouve sont les IPs de source et de destination
(adresses 32 bit, comme 128.6.4.194), le numero du protocole, et un autre
cheksum. L'adresse source est simplement l'adresse de ta machine, c'est
necessaire pour que l'autre sache d'ou ca vient. L'adresse de la machine de
destination est l'adresse de l'autre machine, ce qui est necessaire aux
routeurs entre pour connaitre ou tu veux que le datagramme ailles. En debit
du fait que le trafic IP utilise TCP, il y a d'autres protocoles qui peuvent
etre utilises avec IP, donc il faut dire a IP quel protocole il faut envoyer
sur le datagramme. Finalement, le checksum permettra a IP de l'autre cote de
verifier que le header n'a pas etre bousille lors du voyage. Note aussi que
TCP et IP ont des checksums independants. IP a besoin d'etre capable de
verifier que le header (entete) n'a pas etre endommage durant le transport,
sinon il pourrait envoyer un message a un mauvais endroit. Pour des raisons
que je ne vais pas expliquer, il est plus efficace et plus sur d'avoir TCP
qui calcule son cheksum separement pour le header TCP et les donnees TCP.
Quand IP a mit son header, voila a quoi le message ressemble : 

 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Version|  IHL  |Type of Service|          Total Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Identification        |Flags|      Fragment Offset    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Time to Live |    Protocol   |         Header Checksum       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Source Address                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Destination Address                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  TCP header, then your data ......                            |
     |                                                               |

Si on represente le header IP par un "I", ton fichier ressemblerait a ca :

    IT....   IT....   IT....   IT....   IT....   IT....   IT....

(Bon CoD4 est banni de #france, mort de rire !! :)) Aussi, le header
contient des autres champs sont j'ai pas cause avant.. Le "flag" et 
"Fragment Offset" sont utilises pour garder une piste des pieces quand un 
datagramme doit merder. Ca peut arriver quand les datagrammes sont envoyes 
a travers un reseau pour lequel ils sont trop gros. La duree de vie "Time 
to Live" est un numero qui decroit lorsque que le datagramme passe a travers 
un systeme. Quand il devient nul, il datagramme est detruit. Ceci est fait en 
cas de deplacement en boucle du paquet.

A ce point, c'est possible qu'il y ait plus de headers necessaires, si ton 
ordinateur est parfois connecte via une ligne modem vers l'ordinateur de 
destination, ou via un routeur, il pourrait simplement envoyer les 
datagrammes hors de la ligne..

Descriptions generales
======================

ben ouais, si la c'est pas clair, relit depuis le debut :).. Bon aller
rapidement.. TCP/IP est une serie de protocoles. On va voir un petit
exemple plutot que d'expliquer encore la meme chose. Avant tout, il y a un
mail. Donc des commandes a envoyer vers une autre machine, par exemple les
commandes qui disent qui est l'envoyeur, a ki il va et le texte du message.
Ben euh, ce protocole n'assume pas le chat entre les 2 machines ? Et ben,
c'est que le Mail, comme un autre protocole utilise sur le net, utilise
simplement des commandes et de messages a etre envoyes. Il est
concu pour etre utilise avec TCP et IP, et TCP est responsable de faire
passer les commandes vers l'autre bout, puis IP de les envoyer... voila en
bref. (compris maintenant ???)    Dit tu aimes le mail ?

Sockets et Applications
=======================

Avant on a cause de la decomposition des donnees en paquets, pour etre envoye
ailleurs, et reassemble de l'autre cote. Avant de continuer, je vais boire 
un coup, puis donner quelques detail sur des applications. Suppose voir que 
tu veuilles envoyer un fichier a ton pote qui est sur la machine dont 
l'adresse est 128.6.4.7. Pour commencer le processus, tu dois savoir plus 
qu'une adresse internet. Tu dois te connecter sur un serveur FTP a l'autre 
bout. En general, les programmes reseau sont specialises dans ce type de 
boulot. La plupart des machines ont plein de programmes qui tournent pour 
gerer le transfert de fichiers, le login a distance, courier, serveur fsp 
warez (arf), etc... Enfin quand tu te connectes sur 128.6.4.7, tu dois dire
que tu veux parler au serveur FTP. Ce qui est fait en avant des sockets
connus sur chaque serveur. Ye Rappelle que TCP utilise le numero de port pour
garder une trace des conversations en cours. Les programmes de l'utilisateur
utilisent normalement plus ou moins de ports au hasard, bienque les ports
specifiques sont assignes pour les programmes qui attendent une demande
particuliere. Par exemple. si tu veux envoyer un fichier, tu commences a
lancer ftp, il ouvriera une connection sur un port au hasard, par exemple
1234, pour le port utilise a l'autre bout. Enfin il specifiera le port 21 de
l'autre cote, qui est le port officiel des serveurs ftp. Note quand meme qu'il
y a deux differents programmes en cours.. Tu lances ftp de ton cote, Il y a
un programme dont le but est d'accepter des commandes depuis ton terminal et
qui les balances de l'autre cote, ce programme qui te cause c'est le serveur
FTP. Il a ete designe pour accepter des commandes depuis la connection reseau.
Aussi une connection est decrite par ces 4 nombres :

                    Addresses Internet         Ports TCP
     connection     128.6.4.194, 128.6.4.7      1234, 21

     ||333|o||
     |       |
     | O - O |
     |   I   |    <--- CoD4 <Da KiNG iN a WoRLD o'LaMaH>
     | \___/ | 
     |_______|

Et ben donc on peut dire FTP c nul a chier !! Il a besoin de deux connections,
il commence comme le mail, et on lui dit "connecte moi sous tel utilisateur", 
"tiens voila mon mot de passe", "envoie moi ce fichier avec ce nom"... Et des
que tout ca est fait, une seconde connection est ouverte pour les donnees
seules. Il serait certainement possible d'envoyer les donnees sur la meme 
connection, comme SMTP fait, mais bon c comme ca et c tout et arrete de poser
des questions ! :). En fait je vais dire plutot c car les transferts de files
sont souvent long (merci a billou pour son gros win97 que tout le monde
s'envoie en ftp et sature notre pov'rezo). Ceux qui ont cree le ftp ont
voulu permettre a l'utilisateur de permettre d'envoyer des commandes pendant
le transfert, tel que abandonner le transfert en cours, arf.. 

D'autres protocoles utilisent un principe plus ou moins similaire.. Et si ca
te passionne, matte toujours les RFCs...



Le rewtage facile (routage)
===========================


Bon donc c'est IP qui est responsable du routage. Et pour plus d'infos voir 
http://www.cisco.com/ si tu as besoin d'un routeur par exemple :) (non je ne
fais poa de pub!)


Adresses Internet (petite notion)
=================

Donc les adresses internet sont codees sur 32 bits, ecrites sous la forme de 
4 octets (en decimal), par ex. 128.6.4.7. Actuellement il y a 3 types 
d'adresses. Le probleme est que l'adresse doit indiquer a la fois le 
reseau ainsi que la machine a l'interieur du reseau. Donc on a les 
classes IP. La classe A, pour les reseaux immenses, tels que Arpanet, cette 
classe est limite a 126 reseaux au total. Pour les gros reseaux, il y a la 
classe B, qui correspond a tous les reseaux entre 128.1 et 191.254, ce qui 
permet d'adresses le reseau local sur 16 bits, donc d'avoir 64516 machines, 
ce qui suffit pour la plupart des organisations, en si ca ne suffit pas, 
on peut avoir plusieurs classes B :). Finalement, la classe C, dont la 
partie reseau est codee sur 3 octets, de 192.1.1 et 223.254.254, permet 
d'avoir 254 machines sur chaque reseau, mais on peut avoir beaucoup de tels
reseaux. Les adresses au dela de 223 sont reservees pour un futur usage, en 
tant que classes D et E, qui ne sont pas encore definies (enfin p'etre..)

Quelques valeurs speciales qui sont reservees dans les adresses IP, 0 
et 255 qui ont des significations particulieres, 0 pour les machines qui ne 
connaissent pas leur adresses. 255 est utilise pour le broadcast, qui est un 
message que tu veux que chaque machine sur le reseau voie, c'est utilise par 
exemple quand tu ne sais pas a qui parler, par exemple suppose que tu dois 
trouver l'adresse internet d'une machine a partir de son nom. 
Parfois tu ne sais pas quelle est l'adresse du serveur de noms le plus 
proche. Dans ce cas, p'etre tu envoie une requete au broadcast. A moins 
que ce soit une universite martienne, t'auras pas de machines en 255, arf...


To be continued..
=================

