====== Les détails ======
===== Mise en confiance =====
Ce qui va suivre peut paraître quelque peu « indigeste ». Il n'est donc peut-être pas inutile de donner quelques points de repères avant d'entamer cette descente aux enfers.
Nous savons maintenant que le but ultime est d'exploiter les possibilités de PPP sur un réseau de nature Ethernet, parce que PPP offre quelques facilités aux fournisseurs de services, comme l'identification nominative des clients, principalement. C'est nécessaire lorsqu'il y a plusieurs fournisseurs d'accès qui cohabitent sur la même structure.
Dans la page précédente, nous avons vu qu'une fois la connexion PPP établie, IP est transporté par PPP (oE), lui-même transporté par Ethernet.
Nous devons donc nous attendre, lors de l'établissement de cette connexion, à observer comment PPPoE va s'y prendre pour mettre en place le lien PPP entre notre machine et celle de notre fournisseur de services. Nous nous arrêterons lorsque PPP sera établi, ça suffira. Le reste concernerait le protocole PPP lui-même, ce qui n'est pas l'objectif de cet exposé.
* Nous sommes sur un réseau Ethernet, donc en architecture de réseau, plusieurs hôtes sont présents sur ce réseau et parmi eux, il y a celui avec lequel il faut mettre en place le lien PPP. Il va donc falloir identifier cet interlocuteur sur ce réseau. Le seul moyen connu au niveau Ethernet, c'est un « broadcast ARP » (Diffusion sur toutes les adresses MAC présentes). Une au moins des machines du fournisseur d'accès devrait répondre.\\ Une fois les deux interlocuteurs mutuellement reconnus, il n'y aura plus de broadcast ARP. Comme nous allons le voir, la reconnaissance mutuelle va aboutir à l'octroi d'un identifiant de session qui restera valide tout le temps de la session.\\
* PPP, au moyen du sous-protocole LCP (Link Control Protocol, protocole spécialisé dans la négociation et la maintenance de la connexion PPP), va identifier le client (Nom d'utilisateur et mot de passe).\\
* Si cette identification réussit, LCP va fournir au client les paramètres nécessaires pour le bon fonctionnement d'IP:
* Adresse IP du client
* Serveur DNS pour la résolution des noms
* Passerelle par défaut. (Ici, cette passerelle est symbolique, puisque sur la connexion PPP, il n'y a que deux protagonistes : Vous et l'équipement de votre FAI à l'autre bout. C'est forcément lui la passerelle).
* Si l'identification échoue, la ligne sera « raccrochée » (par analogie avec un modem RTC). Il faudra donc reprendre la connexion à son début.
Voici donc en quelques mots, ce que nous devrions vérifier dans la suite immédiate. Accrochez-vous, on y va.
===== RFC... =====
==== Les « Request For Comment » sont une très grande chose : ====
- Elles décrivent généralement dans le détail les divers protocoles utilisés sur l'Internet (dont PPPoE, bien entendu) et toute personne mettant en œuvre un protocole de l'internet se doit de le faire en respectant les RFCs qui le décrivent, c'est l'assurance que ce protocole sera utilisable par tous.
- Elles sont initialement rédigées en Anglais, par des spécialistes au langage particulièrement obscur.
- A cause de toutes les propriétés citées plus haut, elles servent d'argument « massue » à ceux qui veulent à tout prix montrer qu'ils sont les plus compétents et qu'ils planent bien au dessus des foules ignares (Une réponse communément trouvée sur les newsgroups : « Va d'abord lire les RFC... »).
- A cause du point 1 (le seul positif), elles sont tout de même d'une utilité inestimable.
Par chance pour nous, plusieurs personnes se sont attelées à l'ingrate tâche de la traduction de ces RFCs. Toutes ne le sont pas encore, mais la RFC 2516, celle qui décrit le protocole PPPoE, [[http://abcdrfc.free.fr/rfc-vf/rfc2516.html|est traduite]].
Lisez cette RFC, vous constaterez combien le point 2, même affranchi de la langue Anglaise, reste vérifié. Lisez la quand même si vous voulez vraiment connaître le détail de ce protocole.
==== Pour vous aider un peu dans cette lecture... ====
Voici la manipulation proposée:
* Une machine Linux Mandrake 8.1 ((oui, ça date un peu, mais ça reste vrai)) est connectée à une liaison Netissimo (France Télécom) via un modem Ethernet SpeedTouch Home (Alcatel).
* Le client PPPoE utilisé est rp-pppoe.
* Nous ouvrons une session PPPoE, un renifleur est à l'écoute, qui récupère tout ce qu'il se passe au niveau Ethernet.
* Nous comparons ce que nous voyons avec ce qui est dit dans les RFC.
=== Ce que disent les Textes ===
**L'étape de découverte **
l'étape de découverte s'effectue en quatre étapes. Quand elle s'achève, chaque vis à vis connaît le PPPOE SESSION_ID ainsi que les adresses Ethernet ; cela suffit pour définir une session PPPOE. Les étapes sont :
* Emission d'un paquet broadcast d'initiation par l'hôte ;
* Emission de paquets d'offres par un concentrateur d'accès ou plus ;
* Emission d'un paquet de demande de session unicast par l'hôte ;
* Et émission d'un paquet de confirmation par le concentrateur d'accès.
Après avoir envoyé le paquet de confirmation et dès que l'hôte le reçoit, la connexion passe alors à l'étape suivante : la session PPP.
Toutes les trames de découvertes Ethernet ont le champ ETHER_TYPE à 0x8863.
=== Ce que nous pouvons observer ===
== Etablissement de PPPoE ==
Dans un premier temps, juste le résumé des trames qui passent:
No. Source Destination Protocol Info
4 3Com_50:f0:df ff:ff:ff:ff:ff:ff PPPoED Active Discovery Initiation (PADI)
5 Redback_00:4f:7d 3Com_50:f0:df PPPoED Active Discovery Offer (PADO)
6 3Com_50:f0:df Redback_00:4f:7d PPPoED Active Discovery Request (PADR)
7 Redback_00:4f:7d 3Com_50:f0:df PPPoED Active Discovery Session-confirmation (PADS)
8 Redback_00:4f:7d 3Com_50:f0:df PPP LCP PPP LCP Configuration Request
Et voici, exprimée dans toute sa beauté, la magie des systèmes bien normalisés : Ca va se passer exactement comme c'est dit dans les textes.
Exactement ? Voyons ça de plus près...
**Le paquet PADI ( PPPoE Active Discovery Initiation) :**\\
Les hôtes envoient en broadcast un paquet PADI. Le champ CODE est mis à 0x09 et le champ SESSION_ID à 0x0000.
Le paquet PADI doit contenir un TAG de type Service-Name, indiquant le service que l'hôte demande ainsi que d'autres numéros correspondant à d'autres types de TAG. Un paquet PADI entier (incluant l'en-tête PPPoE) ne doit pas dépasser 1484 octets afin de laisser la place suffisante pour qu'un agent relais puisse ajouter un TAG Relay-Session-Id.
>**__Note:__** A l'usage, j'ai pu constater que les rapports d'analyse de trames affichés « en français » peuvent induire en erreur. Ces rapports sont générés par le renifleur (sniffer), parce qu'il connaît par cœur le format des trames qu'il capture et qu'il les interprète de façon plus « lisible ». Dans la pratique, les données capturées ne sont rien de plus que la suite d'octets, ici surlignés.Dans la trame qui suit, il n'y en a que 32, qui génèrent 24 lignes « d'explications ».
0000 ff ff ff ff ff ff 00 60 8c 50 f0 df 88 63 11 09 Ce sont les information effectivement capturées
0010 00 00 00 0c 01 01 00 00 01 03 00 04 3d 53 00 00 ...............................................
Frame 4 (32 on wire, 32 captured) Ceci n'est que du calcul réalisé par le sniffer
Arrival Time: Dec 3, 2001 15:12:09.426679 ces informations ne correspondent à aucune donnée
Time delta from previous packet: 10.824602 seconds écrite dans la trame
Time relative to first packet: 11.398184 seconds
Frame Number: 4
Packet Length: 32 bytes
Capture Length: 32 bytes ................................................
Ethernet II Les informations capturées commencent ici
Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff) ff ff ff ff ff ff
*** La destination est bien un « broadcast »
sur les adresses MAC
Source: 00:60:8c:50:f0:df (3Com_50:f0:df) 00 60 8c 50 f0 df
*** La source est l'adresse MAC
de l'interface Ethernet
*** connectée au modem ADSL
Type: PPPoE Discovery (0x8863) 88 63
*** ETHER_TYPE est bien à 8863H
PPP-over-Ethernet Discovery
Version: 1
Type: 1 11
Code: Active Discovery Initiation (PADI) 09
*** C'est bien une trame PADI Le champ « code » est à 9
Session ID: 0000 00 00
*** Le champ « Session_ID » est bien à 0
Payload Length: 12 00 0c
PPPoE Tags
Tag: Service-Name 01 01 00 00
*** Le Tag « Service-Name, comme indiqué
Tag: Host-Uniq 01 03 00 04
*** Et un autre Tag: Host-Uniq 3d 53 00 00
Binary Data: (4 bytes)
Remarquez la similitude avec ''DHCP discovery'' dans le prococole DHCP. Le client qui se « réveille » envoie un broadcast ARP pour trouver un interlocuteur qui devra lui indiquer ses paramètres de configuration.
Le Tag « Host-Uniq » est décrit dans l'annexe A:
**0x0103 Host-Uniq**\\
Ce Tag est utilisé par un hôte pour associer de façon unique la réponse d'un concentrateur d'accès (PADO ou PADS) à la requête d'un hôte particulier (PADI ou PADR). Sa valeur est une donnée binaire de n'importe quelle valeur et de n'importe quelle longueur, choisies par l'hôte. Cette valeur n'est pas interprétée par le concentrateur d'accès
Un hôte PEUT inclure un Tag « Host-Uniq » dans un paquet PADI ou PADR. Si le concentrateur d'accès reçoit ce Tag, il DOIT inclure ce Tag sans le modifier dans la réponse PADO ou PADS associée.
Ce Tag (0x0103) est suivi du nombre d'octets qu'il contient (0x0004) et des octets de données (0x3d530000). Nous devrions donc théoriquement retrouver ce Tag dans son intégralité dans la réponse PADO qui suit
Il n'y a pas ici d'agent de relais. Pour l'instant, tout est donc bien conforme.
>**__Note__**: Le « Payload » est assez difficile à bien traduire, peut-être par « Données utiles » (mais elles sont toutes utiles). Comme en mot-à-mot, ça donne : « la charge qui paye », nous dirons « charge utile ». En s'appuyant sur cette analyse de trames, on constate que le « payload length » n'est autre que le nombre d'octets qui suivent, ce qui sera confirmé dans la suite.\\ Ce payload contient des « tags », un peu plus facile à traduire...
**Le paquet PADO (PPPoE Active Discovery Offer)**\\
Quand le concentrateur d'accès reçoit un PADI qu'il peut servir, il répond en envoyant un paquet PADO. l'adresse de destination est l'adresse unicast de l'hôte envoyé dans le PADI. Le champ CODE est fixé à 0x07 et le champ SESSION_ID à 0x0000.
Le paquet PADO doit contenir un TAG AC-Name : c'est le nom du concentrateur d'accès, un TAG Service-Name identique à celui contenu dans le PADI. Les autres numéros correspondent aux autres services qui peuvent être offerts par le concentrateur d'accès. Si le concentrateur d'accès ne peut pas servir le PADI alors celui-ci ne répond pas avec un PADO.
Le client qui a démarré sa connexion PPPoE vient d'essayer de découvrir un interlocuteur, le ou les interlocuteurs présents vont maintenant lui répondre.
0000 00 60 8c 50 f0 df 00 02 3b 00 4f 7d 88 63 11 07
0010 00 00 00 2b 01 01 00 00 01 03 00 04 3d 53 00 00
0020 01 02 00 17 36 32 30 33 32 30 33 30 31 30 38 33
0030 37 36 2d 42 53 4d 41 52 31 30 32 01 01 00 00
Frame 5 (63 on wire, 63 captured)
Arrival Time: Dec 3, 2001 15:12:09.479615
Time delta from previous packet: 0.052936 seconds
Time relative to first packet: 11.451120 seconds
Frame Number: 5
Packet Length: 63 bytes
Capture Length: 63 bytes
Ethernet II
Destination: 00:60:8c:50:f0:df (3Com_50:f0:df) 00 60 8c 50 f0 df
*** La destination est ici le client
Source: 00:02:3b:00:4f:7d (Redback_00:4f:7d) 00 02 3b 00 4f 7d
*** Et la source, l'équipement
du gestionnaire du réseau
Type: PPPoE Discovery (0x8863) 88 63
*** C'est toujours un type « Discovery »
PPP-over-Ethernet Discovery
Version:1 11
Type: 1
Code: Active Discovery Offer (PADO) 07
*** Mais ici, c'est un « Offer »
Session ID: 0000 00 00
Payload Length: 43 00 2b 00 2b
PPPoE Tags
Tag: Service-Name 01 01 00 00
*** Nous retrouvons, comme prévu,
le Tag « Host-Uniq »
Tag: Host-Uniq 01 03 00 04
Binary Data: (4 bytes) 3d 53 00 00
*** Le Tag « AC_NAME »...
Tag: AC-Name 01 02 00 17
*** Et sa valeur (nom du concentrateur d'accès)
String Data: 62032030108376-BSMAR102 36 32 30 33 32 30 33 30 31 30 38 33
37 36 2d 42 53 4d 41 52 31 30 32
Tag: Service-Name 01 01 00 00
Tout ceci devient monotone, il n'y a aucune surprise... Tant pis pour le « suspense », il n'y aura pas d'autres réponses PADO. Nous allons donc maintenant retrouver l'hôte qui envoie un paquet PADR (Session-Request).
**Le paquet PADR (PPPoE Active Discovery Request)**\\ Puisque le PADI a été envoyé en broadcast l'hôte peut recevoir plusieurs PADO. L'hôte examine les paquets PADO reçus et en choisit un. Le choix peut être basé sur le nom du concentrateur d'accès ou sur les services offerts. L'hôte envoie alors un paquet PADR au concentrateur d'accès sélectionné. Le champ DESTINATION_ADDR est l'adresse Ethernet unicast du concentrateur d'accès qui a envoyé par le PADO. Le champ CODE est 0x19 et le champ SESSION_ID est à la valeur 0x0000.
Le paquet PADR doit contenir exactement un TAG_TYPE contenant le nom du service que l'hôte demande ainsi que d'autres numéros d'autres types de TAG.
0000 00 02 3b 00 4f 7d 00 60 8c 50 f0 df 88 63 11 19
0010 00 00 00 0c 01 01 00 00 01 03 00 04 3d 53 00 00
Frame 6 (32 on wire, 32 captured)
Arrival Time: Dec 3, 2001 15:12:09.480206
Time delta from previous packet: 0.000591 seconds
Time relative to first packet: 11.451711 seconds
Frame Number: 6
Packet Length: 32 bytes
Capture Length: 32 bytes
Ethernet II
*** Vous avez compris maintenant le niveau Ethernet...
Destination: 00:02:3b:00:4f:7d (Redback_00:4f:7d) 00 02 3b 00 4f 7d
Source: 00:60:8c:50:f0:df (3Com_50:f0:df) 00 60 8c 50 f0 df
Type: PPPoE Discovery (0x8863) 88 63
*** Et je vous laisse faire la suite tout seuls...
PPP-over-Ethernet Discovery
Version: 1
Type: 1 11
Code: Active Discovery Request (PADR) 19
Session ID: 0000 00 00
Payload Length: 12 00 0c
PPPoE Tags
Tag: Service-Name 01 01 00 00
Tag: Host-Uniq 01 03 00 04
Binary Data: (4 bytes) 3d 53 00 00
Il n'y a pas de grosses différences avec le paquet PADI, si ce n'est que l'adresse du destinataire n'est plus une adresse de broadcast, mais celle du concentrateur d'accès, puisque maintenant, on la connaît.
Finalement, le Concentrateur d'accès va confirmer cette connexion :
**Le paquet PADS(PPPoE Active Discovery Session-confirmation)**\\ Quand le Concentrateur d'Accès reçoit un paquet PADR, il se prépare à commencer une session PPP. Il produit un SESSION_ID unique pour la session PPPOE et répond à l'hôte avec un paquet PADS. Le champ DESTINATION_ADDR est l'adresse Ethernet unicast de l'hôte qui a envoyé le PADR. Le champ CODE est mis à 0x65 et le SESSION_ID DOIT être mis à la valeur unique produite pour cette session PPPOE.
Le paquet PADS contient exactement un TAG_TYPE contenant le nom du service sous lequel le concentrateur d'accès a accepté la session PPPoE et d'autres numéros pour d'autres types de TAG.
Si le concentrateur d'accès n'accepte pas le service proposé dans le PADR, il doit répondre avec des PADS contenant TAG _TYPE Service-Name-Error (et d'autres numéros d'autres TAG). Dans ce cas le SESSION_ID DOIT être à la valeur 0x0000.
0000 00 60 8c 50 f0 df 00 02 3b 00 4f 7d 88 63 11 65
0010 02 f4 00 2b 01 01 00 00 01 03 00 04 3d 53 00 00
0020 01 02 00 17 36 32 30 33 32 30 33 30 31 30 38 33
0030 37 36 2d 42 53 4d 41 52 31 30 32
Frame 7 (60 on wire, 60 captured)
Arrival Time: Dec 3, 2001 15:12:09.547915
Time delta from previous packet: 0.067709 seconds
Time relative to first packet: 11.519420 seconds
Frame Number: 7
Packet Length: 60 bytes
Capture Length: 60 bytes
Ethernet II
Destination: 00:60:8c:50:f0:df (3Com_50:f0:df) 00 60 8c 50 f0 df
Source: 00:02:3b:00:4f:7d (Redback_00:4f:7d) 00 02 3b 00 4f 7d
Type: PPPoE Discovery (0x8863) 88 63
PPP-over-Ethernet Discovery
Version: 1
Type: 1 11
Code: Active Discovery Session-confirmation (PADS) 65
*** Nous récupérons ici la Session-ID
Session ID: 02f4 02 f4
Payload Length: 43 00 2b
PPPoE Tags
Tag: Service-Name 01 01 00 00
Tag: Host-Uniq 01 03 00 04
Binary Data: (4 bytes) 3d 53 00 00
Tag: AC-Name 01 02 00 17
String Data: 62032030108376-BSMAR102 36 32 30 33 32 30 33 30 31 30 38 33
37 36 2d 42 53 4d 41 52 31 30 32
Il n'y a pas eu de problèmes, la session est acceptée par les deux partenaires et elle aura l'identifiant 0x02f4. Nous retrouverons systématiquement cet identifiant dans tous les paquets qui suivront.
C'est fini pour l'établissement de la session PPPoE. Comme vous avez pu le remarquer, c'est assez simple et il n'y a pas grand chose de fait. Tout de même, faisons un petit bilan:
* L'hôte client a cherché et trouvé un Concentrateur d'accès.
* Le Concentrateur d'accès a délivré à l'hôte client:
* Son adresse MAC (ici : 00:02:3b:00:4f:7d)
* Un numéro de session PPPoE (ici : 0x02f4)
== Etablissement de PPP ==
Tout ceci est très bien, mais nous n'avons pas d'adresse IP, ni de passerelle, ni de DNS... Autant de choses nécessaires pour faire fonctionner correctement TCP/IP, sans oublier que, pour l'instant, nous ne sommes toujours pas authentifiés.
Le reste va maintenant être négocié par le protocole PPP, de la même manière qu'avec une connexion « classique » par modem RTC.
PPP est encore une autre affaire, qui dépasse le cadre de ce chapitre. Nous n'allons donc pas étudier par le détail les trames qui suivent. Nous allons tout de même regarder comment les informations qui nous manquent pour l'instant vont être récupérées. Si vous désirez absolument approfondir PPP, vous avez les [[http://abcdrfc.free.fr/rfc-vf/rfc1661.html|RFC 1661 traduites en français ici]].
Voici le sommaire des trames qui nous intéressent :
8 Redback_00:4f:7d 3Com_50:f0:df PPP LCP PPP LCP Configuration Request
9 3Com_50:f0:df Redback_00:4f:7d PPP LCP PPP LCP Configuration Request
10 3Com_50:f0:df Redback_00:4f:7d PPP LCP PPP LCP Configuration Ack
11 Redback_00:4f:7d 3Com_50:f0:df PPP LCP PPP LCP Configuration Ack
12 3Com_50:f0:df Redback_00:4f:7d PPP LCP PPP LCP Echo Request
13 Redback_00:4f:7d 3Com_50:f0:df 0xc223 PPP Cryptographic Handshake Auth. Protocol (0xc223)
14 3Com_50:f0:df Redback_00:4f:7d 0xc223 PPP Cryptographic Handshake Auth. Protocol (0xc223)
15 Redback_00:4f:7d 3Com_50:f0:df PPP LCP PPP LCP Echo Reply
16 Redback_00:4f:7d 3Com_50:f0:df 0xc223 PPP Cryptographic Handshake Auth. Protocol (0xc223)
17 Redback_00:4f:7d 3Com_50:f0:df PPP LCP PPP LCP Echo Request
18 Redback_00:4f:7d 3Com_50:f0:df PPP IPCP PPP IPCP Configuration Request
19 3Com_50:f0:df Redback_00:4f:7d PPP IPCP PPP IPCP Configuration Request
20 3Com_50:f0:df Redback_00:4f:7d PPP LCP PPP LCP Echo Reply
21 3Com_50:f0:df Redback_00:4f:7d PPP IPCP PPP IPCP Configuration Ack
22 Redback_00:4f:7d 3Com_50:f0:df PPP IPCP PPP IPCP Configuration Nak
23 3Com_50:f0:df Redback_00:4f:7d PPP IPCP PPP IPCP Configuration Request
24 Redback_00:4f:7d 3Com_50:f0:df PPP IPCP PPP IPCP Configuration Ack
25 Redback_00:4f:7d 3Com_50:f0:df IP Bogus IP header length (0, must be at least 20)
26 Redback_00:4f:7d 3Com_50:f0:df PPP LCP PPP LCP Echo Request
27 3Com_50:f0:df Redback_00:4f:7d PPP LCP PPP LCP Echo Reply
Nous n'allons pas les détailler, mais juste en extraire les points les plus importants. Déjà, nous allons sauter les LCP Echo request et reply, qui ne présentent pas un intérêt fondamental pour ce qui nous intéresse, si ce n'est qu'ils sont recommandés par les RFC.
Le protocole LCP (Link Control Protocol) est transporté par PPP. Sa fonction, comme son nom l'indique, est de maintenir le bon état du lien PPP. En particulier, c'est lui qui va permettre de négocier au départ la configuration IP du client, ce que nous allons voir tout de suite.
== Demande de configuration de la part du concentrateur d'accès ==
Frame 8 (60 on wire, 60 captured)
...
Ethernet II Ethernet
Destination: 00:60:8c:50:f0:df (3Com_50:f0:df) La cible est le client
Source: 00:02:3b:00:4f:7d (Redback_00:4f:7d) La source est le Concentrateur d'accès
Type: PPPoE Session (0x8864)
PPP-over-Ethernet Session PPPoE
...
Code: Session Data
Session ID: 02f4 Le Session-ID qui a été négocié précédemment
Payload Length: 21
Point-to-Point Protocol PPP
Protocol: Link Control Protocol (0xc021)
PPP Link Control Protocol LCP
Code: Configuration Request (0x01)
Identifier: 0x6d
Length: 19
Options: (15 bytes)
MRU: 1492 Très important!!!, nous y reviendrons.
L'identification va être cryptée**
Authentication protocol: 5 bytes (Cryptographic Handshake Auth. Protocol)
Authentication protocol: CHAP (0xc223) Le « Nombre Magique » est sans intérêt pour nous
Data (1 byte) (voir RFC 1661)
Magic number: 0x2889d071
> //MRU: Maximum Receive Unit, taille maximale en octets d'un paquet acceptable en réception. C'est la valeur qui devra être adoptée pour le MTU (Maximum Transfert Unit) de l'interlocuteur.//
== Demande de configuration de la part du client. ==
Frame 9 (36 on wire, 36 captured) Le client n'a pas grand chose à réclamer
... pour la configuration...
Ethernet II
Destination: 00:02:3b:00:4f:7d (Redback_00:4f:7d)
Source: 00:60:8c:50:f0:df (3Com_50:f0:df)
Type: PPPoE Session (0x8864)
PPP-over-Ethernet Session
Version: 1
Type: 1
Code: Session Data
Session ID: 02f4
Payload Length: 16
Point-to-Point Protocol
Protocol: Link Control Protocol (0xc021)
PPP Link Control Protocol
Code: Configuration Request (0x01)
Identifier: 0x01
Length: 14
Options: (10 bytes)
MRU: 1492 Le MRU, également à 1492.
Magic number: 0x694c9902
> //Mais pourquoi 1492 ? Une trame Ethernet ne doit pas dépasser 1500 Octets. Comme l'en-tête de PPPoE fait 6 octets et que le PPP_ID est de 2 octets, il ne reste que 1492 octets pour le PPP_MTU.//
== Acquittement du client ==
Frame 10 (41 on wire, 41 captured) Le client est d'accord pour :
...
Ethernet II
Destination: 00:02:3b:00:4f:7d (Redback_00:4f:7d)
Source: 00:60:8c:50:f0:df (3Com_50:f0:df)
Type: PPPoE Session (0x8864)
PPP-over-Ethernet Session
Version: 1
Type: 1
Code: Session Data
Session ID: 02f4
Payload Length: 21
Point-to-Point Protocol
Protocol: Link Control Protocol (0xc021)
PPP Link Control Protocol
Code: Configuration Ack (0x02)
Identifier: 0x6d
Length: 19
Options: (15 bytes)
MRU: 1492 Le MRU à 1492
Authentication protocol: 5 bytes
Authentication protocol: CHAP (0xc223) le protocole CHAP pour l'authentification
Data (1 byte)
Magic number: 0x2889d071 Et le numéro magique
== Acquittement du concentrateur d'accès ==
Frame 11 (60 on wire, 60 captured) Le concentrateur d'accès est d'accord pour:
...
Ethernet II
Destination: 00:60:8c:50:f0:df (3Com_50:f0:df)
Source: 00:02:3b:00:4f:7d (Redback_00:4f:7d)
Type: PPPoE Session (0x8864)
PPP-over-Ethernet Session
Version: 1
Type: 1
Code: Session Data
Session ID: 02f4
Payload Length: 16
Point-to-Point Protocol
Protocol: Link Control Protocol (0xc021)
PPP Link Control Protocol
Code: Configuration Ack (0x02)
Identifier: 0x01
Length: 14
Options: (10 bytes)
MRU: 1492 Le MRU à 1492
Magic number: 0x694c9902 Et le numéro magique.
== Authentification du Concentrateur ==
Frame 13 (60 on wire, 60 captured) Le concentrateur envoie au client
... un paquet de données...
Ethernet II
Destination: 00:60:8c:50:f0:df (3Com_50:f0:df)
Source: 00:02:3b:00:4f:7d (Redback_00:4f:7d)
Type: PPPoE Session (0x8864)
PPP-over-Ethernet Session
Version: 1
Type: 1
Code: Session Data
Session ID: 02f4
Payload Length: 31
Point-to-Point Protocol
Protocol: Cryptographic Handshake Auth. Protocol (0xc223)
Data (38 bytes)
0000 00 60 8c 50 f0 df 00 02 3b 00 4f 7d 88 64 11 00 .`.P....;.O}.d.. Le détail de ce paquet pourrait être
0010 02 f4 00 1f c2 23 01 01 00 1d 10 75 51 f4 58 40 .....#.....uQ.X@ décrit en étudiant le protocole CHAP...
0020 38 9b 08 c2 8f 76 9f 8e 89 81 3c 42 53 4d 41 52 8....v....<BSMAR Notez que le nom du concentrateur
0030 31 30 32 66 00 50 35 d1 cc 8f 00 00 102f.P5..... apparaît en clair
== Authentification du client ==
Frame 14 (58 on wire, 58 captured) Le client envoie au concentrateur
... un paquet de données...
Ethernet II
Destination: 00:02:3b:00:4f:7d (Redback_00:4f:7d)
Source: 00:60:8c:50:f0:df (3Com_50:f0:df)
Type: PPPoE Session (0x8864)
PPP-over-Ethernet Session
Version: 1
Type: 1
Code: Session Data
Session ID: 02f4
Payload Length: 38
Point-to-Point Protocol
Protocol: Cryptographic Handshake Auth. Protocol (0xc223)
Data (36 bytes)
0000 00 02 3b 00 4f 7d 00 60 8c 50 f0 df 88 64 11 00 ..;.O}.`.P...d.. Le détail de ce paquet pourrait être
0010 02 f4 00 26 c2 23 02 01 00 24 10 38 af 00 96 c1 ...&.#...$.8.... décrit en étudiant le protocole CHAP...
0020 b0 95 b2 b2 ee 6f be bb d4 cd 5e 66 74 69 2f xx .....o....^fti/x Notez que le nom du client apparaît
0030 xx xx xx xx xx xx 40 66 74 69 xxxxxx@fti également en clair
(les x, c'est de ma part).
== Le verdict... ==
Frame 16 (61 on wire, 61 captured)
...
Ethernet II
Destination: 00:60:8c:50:f0:df (3Com_50:f0:df)
Source: 00:02:3b:00:4f:7d (Redback_00:4f:7d)
Type: PPPoE Session (0x8864)
PPP-over-Ethernet Session
Version: 1
Type: 1
Code: Session Data
Session ID: 02f4
Payload Length: 41
Point-to-Point Protocol
Protocol: Cryptographic Handshake Auth. Protocol (0xc223)
Data (39 bytes)
0000 00 60 8c 50 f0 df 00 02 3b 00 4f 7d 88 64 11 00 .`.P....;.O}.d.. On ne sait pas exactement comment, mais...
0010 02 f4 00 29 c2 23 03 01 00 27 43 48 41 50 20 61 ...).#...'CHAP a L'authentification a réussi.
0020 75 74 68 65 6e 74 69 63 61 74 69 6f 6e 20 73 75 uthentication su
0030 63 63 65 73 73 2c 20 75 6e 69 74 20 39 ccess, unit 9
== Requête de configuration du concentrateur ==
Frame 18 (60 on wire, 60 captured) A vrai dire
... Ce n'est pas exactement une requête
Ethernet II
Destination: 00:60:8c:50:f0:df (3Com_50:f0:df) Le concentrateur n'a rien à demander
Source: 00:02:3b:00:4f:7d (Redback_00:4f:7d)
Type: PPPoE Session (0x8864)
PPP-over-Ethernet Session
Version: 1
Type: 1
Code: Session Data
Session ID: 02f4
Payload Length: 12
Point-to-Point Protocol
Protocol: IP Control Protocol (0x8021)
PPP IP Control Protocol
Code: Configuration Request (0x01) il annonce juste son IP
Identifier: 0x6e
Length: 10
Options: (6 bytes)
IP address: 217.128.147.1
== Requête de configuration du client ==
Frame 19 (44 on wire, 44 captured) Ici, c'est plus amusant.
... Le client propose une configuration
Ethernet II
Destination: 00:02:3b:00:4f:7d (Redback_00:4f:7d)
Source: 00:60:8c:50:f0:df (3Com_50:f0:df)
Type: PPPoE Session (0x8864)
PPP-over-Ethernet Session
Version: 1
Type: 1
Code: Session Data
Session ID: 02f4
Payload Length: 24
Point-to-Point Protocol
Protocol: IP Control Protocol (0x8021)
PPP IP Control Protocol
Code: Configuration Request (0x01)
Identifier: 0x01
Length: 22
Options: (18 bytes)
IP address: 0.0.0.0 Comme il se réveille juste, il propose
Primary DNS server IP address: 0.0.0.0 une configuration plutôt farfelue...
Secondary DNS server IP address: 0.0.0.0
== Acquittement de la configuration du concentrateur ==
Frame 21 (32 on wire, 32 captured)
...
Ethernet II
Destination: 00:02:3b:00:4f:7d (Redback_00:4f:7d)
Source: 00:60:8c:50:f0:df (3Com_50:f0:df)
Type: PPPoE Session (0x8864)
PPP-over-Ethernet Session
Version: 1
Type: 1
Code: Session Data
Session ID: 02f4
Payload Length: 12
Point-to-Point Protocol
Protocol: IP Control Protocol (0x8021)
PPP IP Control Protocol
Code: Configuration Ack (0x02) Le client est d'accord...
Identifier: 0x6e
Length: 10
Options: (6 bytes) Pour l'adresse IP du concentrateur
IP address: 217.128.147.1 (qui deviendra sa passerelle par défaut)
== Refus de la configuration du client ==
Frame 22 (60 on wire, 60 captured) On s'en souvient, le client avait
... proposé une configuration stupide.
Ethernet II
Destination: 00:60:8c:50:f0:df (3Com_50:f0:df) En fait, elle ne l'était pas.
Source: 00:02:3b:00:4f:7d (Redback_00:4f:7d) Ne connaissant pas sa configuration,
Type: PPPoE Session (0x8864) le client indique des adresses
PPP-over-Ethernet Session toutes à zéro.
Version: 1
Type: 1 C'est dans le but que le concentrateur
Code: Session Data lui propose à la place des adresses
Session ID: 02f4 valides
Payload Length: 24
Point-to-Point Protocol
Protocol: IP Control Protocol (0x8021)
PPP IP Control Protocol
Code: Configuration Nak (0x03)
Identifier: 0x01
Length: 22
Options: (18 bytes)
IP address: 217.128.147.4 Son IP
Primary DNS server IP address: 193.252.19.3 Et le (ici les) DNS.
Secondary DNS server IP address: 193.252.19.4
== Re-requête de configuration du client ==
Frame 23 (44 on wire, 44 captured) Un protocole, c'est parfois bête,
... mais toujours discipliné.
Ethernet II
Destination: 00:02:3b:00:4f:7d (Redback_00:4f:7d)
Source: 00:60:8c:50:f0:df (3Com_50:f0:df)
Type: PPPoE Session (0x8864)
PPP-over-Ethernet Session
Version: 1
Type: 1
Code: Session Data
Session ID: 02f4
Payload Length: 24
Point-to-Point Protocol
Protocol: IP Control Protocol (0x8021)
PPP IP Control Protocol
Code: Configuration Request (0x01)
Identifier: 0x02
Length: 22 Le client refait une requête de configuration
Options: (18 bytes) cette fois-ci avec les adresses qui lui ont été
IP address: 217.128.147.4 « suggérées » par le concentrateur...
Primary DNS server IP address: 193.252.19.3
Secondary DNS server IP address: 193.252.19.4
== Acquittement de la configuration du client ==
Frame 24 (60 on wire, 60 captured) Le concentrateur, sous peine de passer
... pour un fou,
Ethernet II ne pourra pas faire autrement (en principe)
Destination: 00:60:8c:50:f0:df (3Com_50:f0:df) que d'accepter cette configuration
Source: 00:02:3b:00:4f:7d (Redback_00:4f:7d) qu'il a proposé lui-même.
Type: PPPoE Session (0x8864)
PPP-over-Ethernet Session
Version: 1
Type: 1
Code: Session Data
Session ID: 02f4
Payload Length: 24
Point-to-Point Protocol
Protocol: IP Control Protocol (0x8021)
PPP IP Control Protocol
Code: Configuration Ack (0x02) Voilà qui est fait.
Identifier: 0x02
Length: 22
Options: (18 bytes)
IP address: 217.128.147.4
Primary DNS server IP address: 193.252.19.3
Secondary DNS server IP address: 193.252.19.4
Toute cette séquence n'aura duré que 3 secondes .
* Etablissement d'une session PPPoE entre le client et le concentrateur, avec établissement d'un identifiant de session.
* Authentification du client de la part du concentrateur par LCP (sur PPP)
* Obtention d'une configuration valide pour le client (Adresse IP, Adresses de DNS et Passerelle, la passerelle étant bien entendu le concentrateur lui-même).
===== Conclusions =====
J'espère que cet exposé vous aura éclairé sur le fonctionnement de ce protocole qui tend à devenir universel sur les connexions « haut débit ». Les points principaux à retenir me semble être les suivants:
* Etablissement d'une connexion PPP au dessus d'Ethernet avec obtention d'un identifiant de session.
* Identification du client avec LCP, protocole de gestion et de maintenance d'une connexion PPP.
* Obtention des paramètres de connexion IP par ce même protocole LCP.
* Transport des datagrammes IP par PPP, lui même transporté par Ethernet.