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é.
Voici donc en quelques mots, ce que nous devrions vérifier dans la suite immédiate. Accrochez-vous, on y va.
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.
Voici la manipulation proposée:
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 :
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.
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 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:
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 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 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 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:
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.
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.
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.
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
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.
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
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).
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
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
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
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)
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
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
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 .
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: