Bonjour;

je cherche des documents et procédures pour le test des CPE ADSL;

Merci de votre aide.


cordialement.

Il faudrait préciser ce que vous souhaitez tester.

L’endurance ?
Le fonctionnel ?
La performances ?
Abaque de débit de sychro en fonction de la distance ?
Internet ?
la VoIP ?
le WiFI ?
le switch intégré ?
la redirection de port et l'UPnP ?

En attendant une réponse, je note que Le peer to peer est un très bon test pour stresser les box. Des centaines de connexions ouvertes en même temps. A faire bien sur au débit max donc en ADSL, avec un DSLAM au cul du modem. Bien sur je vous conseille de télécharger autre chose que des distributions linux pour pouvoir envoyer du contenu a des centaines d'autres clients.

Le débit IP entre le PC de test et le CPE doit être au moins de 80% du débit de synchro sinon il y a un souci.

Bien vérifier que pendant ce test le relais DNS et serveur DHCP intégré la box continue de répondre correctement. J'ai déjà vu des relais DNS qui ne répondent plus si le CPU est trop chargé.

PS: A propos du P2P pour les français, la Hadopi ne vise pas les professionnels, donc pas de risque à tester sur du contenu que j’appellerais pudiquement "populaire".

Le peer to peer est un très bon test pour stresser les NAT-box.

Au niveau des PPS il y a parfois de mauvaise surprise même sur un routeur qui ne fait ni NAPT ni suivi de connexion.

Le nombre de tests dépend du volume commandé. Je pense que la plupart des gros FAI font tous les tests.

Des tests d'endurance, consistant a laisser un CPE plusieurs jours avec du P2P ou/et avec des appels VoIP et vérifier qu'il ne reboot pas ou ne se plante pas.

Au niveau de la VoIP ils vérifient la qualité MOS mais aussi la priorisation sur la data (la priorisation dans le sens montant est fait sur le CPE, dans le sens descendant sur le DSLAM)

Toutes les fonctions sur l'interface (notamment ce qui concerne l'ouverture de port sur l'ensemble des ports proposé) doit être fonctionnel. Si il n'est pas possible d'ouvrir certains ports (par exemple car utilisé par TR-69, il faut alors le signaler au client)

Pour le WiFI, des test de compatibilité / performances avec de nombreux PC et clé WiFi seront réalisées.

Des abaques vont être réalisées avec un simulateur de ligne pour voir le comportement sur différentes longueur de ligne et différentes qualité (en injectant du bruit impulsionnel ou continu sur la ligne). Si des fonctionnalités de retransmission de paquet couche basse sont proposées (type PhyR pour Broadcom), elles seront testées.

Une dernière chose qui sera bien testé : IPv6. On n’achète pas une box en 2013 sans vérifier sa compatibilité IPv6 et ses performances IPv6 (ne pas oublier les requêtes AAAA vers le relaie DNS du CPE)

Oui, bug corrigé depuis il me semble.

La capture wireshark parle :


les requêtes "AAAA" (nom de domaine IPv6) obtiennent systématiquement pour réponse "Flags: 0x8104 (Standard query response, Not implemented)"

J'ai déjà rencontré ce bug sur un matériel Sagem en cours de test. Cela a immédiatement été classé en anomalie bloquante.

Je suis clairement déçu par les process de validation d'Orange...

Il y a encore du chemin pour l'IPv6 chez Orange vu que les DNS IPv4 ne répondent même pas aux requêtes AAAA.

Linux envoie deux requêtes simultanèment ou presque : une requête A (IPv4) et une requête AAAA (IPv6).
Si le premier à répondre est IPv6 avec "Not implemented" alors linux va faire une nouvelle demande en ignorant la réponse IPv4 qui arrive : il rajoute le nom de domaine obtenu en DHCP soit "home".

Cette seconde requête "www.google.fr.home" pour www.google.fr va être en échec : On aura "Not implemented" pour la requête AAAA et "No such name" pour la requête A.
=> Échec complet à chaque fois que la réponse AAAA arrive avant celle de A (soit à peu près une fois sur deux)

Merci beaucoup pour toutes les réponses,

est ce possible d'avoir une explication pratique (branchements, commandes, ...) pour chaque élèment testé ?

Cordialement.