Mon blog

Le protocole PPP sert à bien d'autres choses qu'aux liaisons modem. Par exemple, il est un des plus utilisés pour les connexions ADSL, dans sa variante PPPoE, que décrit notre RFC.

Comme la plupart des technologies d'accès aujourd'hui, une connexion ADSL typique fournit un accès en Ethernet et PPP (RFC 1661) n'avait été conçu que pour le point-à-point où il n'y a que deux machines sur le réseau. L'essentiel de notre RFC est donc consacré au protocole de découverte (section 5) par lequel une machine PPPoE va pouvoir trouver son concentrateur d'accès, en demandant à la cantonade.

La section 3 décrit le principe du protocole. Le client PPPoE (PPP est pair-à-pair, pas client-serveur mais le protocole de découverte, lui, est client-serveur) émet un paquet PADI de recherche du concentrateur, celui-ci répond avec un paquet PADO (qui contient des étiquettes, décrites dans l'annexe A, pour donner des informations supplémentaires) et lui indique un numéro de session (0x2041 dans les exemples ci-dessous) qui permet de séparer les différentes sessions PPP qui coexistent sur le même Ethernet.

Ensuite, c'est LCP qui prend le relais et on fait du PPP classique (la section 7 donne quelques détails, notamment sur les problèmes de MTU mais attention, le RFC 4638 l'a mise à jour).

Voici, sur une machine Debian, un extrait du fichier de configuration /etc/ppp/peers/nerim pour se connecter au FAI Nerim. Le « modem » ADSL est configuré en simple pont pour que la machine Debian puisse joindre le concentrateur d'accès en Ethernet :

# Nerim via LDcom degroupe
pty "pppoe -I eth1 -T 80 -m 1412"
linkname nerim
# wait for PADO (3s)
connect-delay 3000
# Le reste n'est pas spécifique à PPPoE...

Pour créer le pseudo-terminal (pty) où PPP va se connecter, on lance le démon pppoe.

Voici la découverte du concentrateur d'accès avec la commande Unix pppoe :

# pppoe -A -I eth1
Access-Concentrator: SE800-CBV3-1
       Service-Name: ldcom
AC-Ethernet-Address: 00:30:88:10:3c:b9

et voici son résultat, vu avec tcpdump (sections 5.1 et 5.2 du RFC) :

% tcpdump -n -e -I eth1
22:25:39.424864 00:0c:76:1f:12:7b > ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 24: PPPoE PADI
22:25:39.469939 00:30:88:10:3c:b9 > 00:0c:76:1f:12:7b, ethertype PPPoE D (0x8863), length 60: PPPoE PADO [AC-Name "SE800-CBV3-1"] [Service-Name "ldcom"] [EOL]

Si, au lieu de regarder avec tcpdump l'interface Ethernet (ici eth1), on regarde l'interface PPP (ici ppp0), on voit passer des paquets IP classiques. Pour voir l'encapsulation PPP, il faut regarder l'interface Ethernet et le trafic ressemble à :

% tcpdump -n -e -I eth1
22:28:16.129173 00:0c:76:1f:12:7b > 00:30:88:10:3c:b9, ethertype PPPoE S (0x8864), length 62: PPPoE  [ses 0x2041] PPP-IP (0x0021), length 42: IP 213.41.181.9.35156 > 204.13.160.129.80: F 212:212(0) ack 875 win 6984
22:28:16.323916 00:30:88:10:3c:b9 > 00:0c:76:1f:12:7b, ethertype PPPoE S (0x8864), length 62: PPPoE  [ses 0x2041] PPP-IP (0x0021), length 42: IP 204.13.160.129.80 > 213.41.181.9.35156: . ack 213 win 8189

Notez que le type Ethernet a changé, passant de 0x8863 pour la découverte à 0x8864 pour la session (section 4 du RFC).