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 :

  1. 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.
  2. Elles sont initialement rédigées en Anglais, par des spécialistes au langage particulièrement obscur.
  3. 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… »).
  4. 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, 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 1) 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 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.
1)
oui, ça date un peu, mais ça reste vrai
Dernière modification:: le 03/03/2009 à 19:48
   
 
Cette création est mise à disposition sous un contrat Creative Commons. Creative Commons License