Bonjour,
Question pour experts !
 
Quelqu'un pourrait-il m'aider à comprendre le fonctionnement des modem ADSL.
Pour résumer le fonctionnement théorique, prenons mon exemple : mon modem-routeur ADSL, que je loue auprès de mon FAI présente plusieurs interfaces : USB+ethernet pour se raccorder à mon ordi et une prise RJ pour brancher la ligne téléphone (via filtre ADSL bien sûr).
Donc, si je ne m'abuse mon modem est un terminal ATM qui utilise le LANE de FT pour accéder en Ethernet (transportant lui-même du PPP !) au DSLAM de mon FAI.
Je connecte mon PC avec le port Eth du modem via la connectique Eth proposé par la chipset nForce4 de ma carte mère MSI.
Voici les deux interfaces sur mon PC :
 

 
La MAC inscrite au dos de mon modem est : 00-14-a4-01-77-ee (modfifiée pour confidentialité). C'est donc la MAC du coté boucle locale (pour la connexion Eth transportée via ATM).
 
J'utilise IP-Sniffer (de chez IP Tools) pour sniffer les deux interfaces ci-dessus en mode Winpcap. Voici deux trames sniffées respectivement sur l'interface Eth, puis PPP :
 

 
 
00E0FC-4D113D est donc la MAC de mon modem "coté PC". Les @MAC sont consistentes par rapport au sens des trames : si je prend une trame sortante/entrante MAC Src et Dest sont inverseés (avec les mêmes valeurs).
La présence d'Ethernet dans la capture sur l'interface PPP ne me choque pas puisque cette interface n'est en fait qu'une émanation du client natif PPPoE de W$. And now zeu questions :
 
 - Est-ce que j'ai raconté des bêtises dans ce qui précède ? (ce n'est pas peu probable   )
 - Quelle est la signification des @MAC de la capture PPP ?? L'@ MAC locale 070007-000000 m'intrigue tout particulièrement ! On devrait pas voir l'@ MAC coté FAI de mon modem (00-14-a4-01-77-ee) dans cette trame ??!
 - Comment se fait-il qu'il n'y ait pas passerelle par défaut pour l'interface Eth ? Elle n'envoie pas vers ffffffffffff mais bien vers une @MAC précise (surtout que le cache ARP est vide !). Et pi cet interface est mis en DHCP, par quel entourloupe a-t-elle obtenu son @IP 169.254.6.162 qui plus est avec un masque de classe B !!
 
Merci d'avance pour votre aide    
 

un chti UP !  

Dans ton cas, ton FAI utilise une couche PPPoE/A pour établir un lien IP.
Donc il est normal que tu ne puisses pas récupérer l'adresse IP de ton FAI directement via "Carte Ethernet Connexion au réseau local".
A la rigueur, si ton modem a une interface web, tu pourras via cette connexion, le configurer.
Pour plus de détaille sur pppoe :
http://christian.caleca.free.fr/pppoe/

Merci jlighty pour ta réponse.
Le site que tu indique est particulièrement bien fait. J'ai tout dévoré dans les moindres détails. Merci beaucoup !
 
Il me permet de répondre à la première de mes questions : il semble que ma conception de l'affaire est la bonne    
 
Mais ça ne fait que renforcer mes autres interrogations : je ne veux pas avoir l'IP de mon FAI (suffit de voir mon @IP publique qui est sur son réseau   ), juste comprendre à quoi correspond l'@MAC source de la trame Eth capturée au départ de mon client PPPoE : 070007-000000 (déjà).
 
Cette trame (transportant du PPP transportant lui-même du IP transportant lui-même du TCP) sort bien de mon port Eth (dont la MAC est 001109-D6A3EC, comme on peut le voir sur la capture au niveau de ce port même). Le 070007-000000 est une entourloupe du client PPPoE W$ ou quoi ?
 
Autrement dit, pourquoi est-ce que les @MAC visibles dans les captures au niveau du port Eth et au niveau du client PPPoE n'ont rien à voir ?    
 
Ca va dans le même sens de l'autre question : mon interface Eth n'a pas de passerelle par défaut. Pourtant elle envoie ses trames vers des @MAC bien précises. Comment les a-t-elle récupérées ? Pourquoi le cache arp est vide ? Comment a-t-elle choppé une @IP en dynamique sans même avoir de passerelle par défaut (il est où son serveur DHCP ??) ?? Son @IP est 169.254.6.162 donc certainement pas fournie par le DHCP de mon FAI !
 
Merci !

c'est des connexions point à point (PPP) donc on peut se permettre d'utiliser des adresses MAC bidons puisqu'il y aura seulement 2 équipements connectés.

si la connexion PPPoE n'est pas établie alors c'est normal que ton cache soit vide. Si ton cache est vide alors que ta connexion est établie alors il y a un sérieux problème

je t'ai dis que le lien IP se fait par dessus PPPoE donc il est normal que la pile TCP/IP située directement sur le protocole Ethernet ne récupère aucune adresse IP.
L'IP 169.254.6.162 est une IP bidon que Windows donne lorsqu'il n'arrive à contacter le serveur DHCP.

OK, donc c W$ qui met du m'importe nawak..
effectivement rechercher des @MAC au niveau PPP n'a pas trop de sens (je ne suis pas très à l'aise avec PPP comme protocole transporté par Eth, pas de pb avec IP   ), comme le montre le petit "sniffing" de Christian CALECA. C plus sympa sur Linux : la trame sniffée au niveau de l'interface PPP ne contient aucune @MAC (c plus cohérent)..
Je ne sais pas pourquoi le sniffer d'IP Tools m'en montre sous Windows !    
 
Le cache arp est effectivement vide après 225h de connexion non stop..    
Ca doit être un autre coup à la W$..
 
Je pense que mes recherches s'arrêtent ici, pour suivre la suite de cette affaire (coté boucle locale), il faudrait que je puisse sniffer des trames sur l'autres coté de mon modem, et pour cela y accéder, mais il se trouve que je le loue auprès de mon FAI..
La prochaine fois que je changerai de FAI, j'achèterai un modem-routeur (ce qui me frustre, c que les vrais -non gérés uniquement via interface http- ne courent pas les rues et sont plutôt chers)..
 
Merci jlighty    
 

Quelques petites précisions sur tout ce que tu dis :
-la liaison ATM de ton modem se fait au niveau du BAS, pas du dslam. Entre le dslam et ton modem, il y a la modulation DMT (c'est la technologie ADSL a proprement parler). Le dslam ne fait que du multiplexage de VC dans des VP (et il sépare aussi le flux de données internet du flux de données téléphonie classique à l'aide d'un filtre, tout comme chez toi). En effet, le réseau ATM de FT s'étend après le DSLAM, et s'arrête aux niveau des BAS. Le BAS est un serveur d'authentification ; il récupère les VP des différents DSLAM qui sont raccordés, demux pour obtenir ton VC. A partir de la, il redirige ensuite ton flux vers le bon FAI grace à l'authentification (CHAP/PAP) faite sur PPP. Le BAS est l'équipement du réseau qui fait l'interface entre le réseau de collecte ATM et le RBCI. Le BAS termine les VP et les VC. Il transforme le trafic ATM en trafic IP. Ta connection IP se fait de ton modem à ton FAI.  
 
Voici les étapes pour une connection à Internet en ADSL (non dégroupé bien sur):
1. Demande de connexion : ouverture de la session PPP de l'utilisateur jusqu’au BAS,
2. demande d'authentification de l'utilisateur par le BAS au serveur radius du FAI,
3. authentification de l'utilisateur par le serveur radius et attribution d'une adresse IP,
4. établissement de la session PPP, l’utilisateur est connecté
5. accès de l'utilisateur à Internet.
 
En espérant t'avoir aidé

Merci petoulachi pour tes explications précises !
 
1- Si j'ai tout compris, le DSLAM est "aveugle" par rapport au traffic des clients (des différents FAI).
Question : comment le BAS identifie-t-il le bon serveur Radius à intérroger ??    
Il "scanne" l'ensemble des FAI possibles ?    (comment savoir alors si l'authentification a échoué car on a tapé à la mauvaise porte ou à cause d'un mauvais mdp ?)
 
2- Tu dis que l'authentification du client se fait grace à CHAP/PAP, donc sur PPP, mais dans tes étapes, l'authentification a lieu avant l'établissement de la session PPP    
Comment qu'c'est possible ça ?  
Tou vé dirr ke le BAS met la connexion PPP en suspens le temps de demander au RADIUS si c bon et si c le cas, il finit l'échange CHAP/PAP ??    
(sorte de relais-authentification).
 
Merci !
 
 

non, windows ne fait qu'appliquer l'adressage privé automatique, qui est documenté dans la RFC : http://www.ietf.org/rfc/rfc3330.txt    

selon l'identifiant, il sait quel fai interroger, xxx@freeadsl      

 
Aha ! RFC 3927, section 2 pour les détails..
 

 
Pas bête ! Ca voudrais dire que le BAS fait un lookup dans une table des FAI dispos.. pas très réseau-puriste tout ça..
 
 

Là dessus je n'ai pas la réponse exacte. Je pense qu'il fait cela grace au login comme le dit LaTeX_, mais je n'en suis pas sur (en meme temps je ne vois pas d'autre solution)
 

Heu non, la session PPP est ouverte dès le début sur le BAS, ensuite l'authentification permet de l'établir : l'utilisateur a alors accès au net (le FAI se comporte d'ailleurs comme un proxy ARP : sur la session PPP, il n'y a que 2 parties par définition : le client et le serveur (FAI). Lorsque le client cherche a joindre une IP, le FAI répond toujours "c'est moi" à la requête ARP. Pour le client, le FAI c'est tout le monde).