Fonctionnement modem ADSL

Recherche :

Dernière réponse

Sujet : Fonctionnement modem ADSL

petoulachi

p-seeker23 a écrit :

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)

p-seeker23 a écrit :

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 :pt1cable:
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 ?? :heink:
(sorte de relais-authentification).

Merci !

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).

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

petoulachi

p-seeker23 a écrit :

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)

p-seeker23 a écrit :

p-seeker23

LaTeX_ a écrit :

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

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

LaTeX_ a écrit :

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

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..

LaTeX_

p-seeker23 a écrit :

OK, donc c W$ qui met du m'importe nawak..

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

p-seeker23 a écrit :

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 ?? :pt1cable:
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 ?)

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

p-seeker23

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 ?? :pt1cable:
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 :pt1cable:
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 ?? :heink:
(sorte de relais-authentification).

Merci !

petoulachi

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 jusquau 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, lutilisateur est connecté
5. accès de l'utilisateur à Internet.

En espérant t'avoir aidé

p-seeker23

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 :D ), 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 ! :pfff:

Le cache arp est effectivement vide après 225h de connexion non stop.. :ouch:
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 :jap:

jlighty

Citation :

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 ? :??:

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.

Citation :

Pourquoi le cache arp est vide ?

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 :)

Citation :

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 !

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.

p-seeker23

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 :sol:

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 !

jlighty

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/

p-seeker23

un chti UP ! :hello:

p-seeker23

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 :

Carte Ethernet Connexion au réseau local: MAC=00-11-09-D6-A3-EC (NVIDIA nForce MCP Networking Adapter Driver)
Autoconfiguration d'adresse IP. . : 169.254.6.162
Masque de sous-réseau . . . . . . : 255.255.0.0
Passerelle par défaut . . . . . . :

Carte PPP FAI : MAC=00-53-45-00-00-00
Adresse IP. . . . . . . . . . . . : 84.102.111.240
Masque de sous-réseau . . . . . . : 255.255.255.255
Passerelle par défaut . . . . . . : 84.102.111.240

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 :

Eth : 83.135.235.67:2424->84.102.111.240:4662 ,1222 Bytes
Ethernet
MAC Dest.:00-11-09-D6-A3-EC
MAC Src.:00E0FC-4D113D
Eth. Prot.: $8864
Proto. Name: PPPoE
PPPoE
Version: 8
Type: 1
Code: 0
SessionID: $DC00
Length: 1202
IP
Version:4
Header len.:20
Total len.:1200
ID:$74C1
fragmentation :
DF=0
MF=0
TTL:114
Protocol:$06 (TCP)
Checksum:$8C65
Source IP:83.135.235.67
Dest. IP:84.102.111.240
TCP
src_port:2424
dest_port:4662
seq_number:3779383432
ack_number:3785759714
data_offset:5
flags
urgent :0
ack :1
push :1
reset :0
syn :0
fin :0
window:17142
checksum:$FD4D
urgent_pointer:$00
EDONKEY ;-)
DATA

PPP : (TCP)84.102.111.240:4662->24.90.205.75:3683 ,54 Bytes
Ethernet
MAC Dest.:12FC20-000700
MAC Src.:070007-000000
Eth. Prot.: $800
Proto. Name: IP
IP
Version:4
Header len.:20
Total len.:40
ID:$F65
fragmentation
DF=0
MF=0
TTL:128
Protocol:$06 (TCP)
Checksum:$416F
Source IP:84.102.111.240
Dest. IP:24.90.205.75
TCP
src_port:4662
dest_port:3683
seq_number:1817717899
ack_number:97807726
data_offset:5
flags
urgent :0
ack :1
push :0
reset :0
syn :0
fin :0
window:65535
checksum:$D919
urgent_pointer:$00

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 :D )
- 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 :D