jlhal
lundi 14 avril 2008 à 19:15
Le vendredi 28 mars 2008 à 22:27 j'écrivais un post au sujet d'un problème de reconnection que je croyais réglé.
En effet ALICE, le FAI , faisait semble-t-il des travaux sur mon NRA BOU78 (dégroupage) ...
Hélas le canard est toujours vivant:
Connection : Belkin F5D7633-4 (modem adsl2+/routeur Wifi+4 ports Ethernet)
Contrat : Neuf 8Megas, prénumérotation tel chez Neuf, abonnnement ligne FT.
Aucun problème jusqu'à il y a eniron 1 mois+.
Depuis, au moins une fois par jour (parfois cela fonctionne 48h), le Belkin a la Led de droite allumée en ROUGE, ce qui signifie: problème d'obtention d'adresse IP !
Côté PC , TOUT semble normal.
Accès web au routeur: OK 192.168.2.1
Firewall : disabled (J'utilise Look'nStop)
NAT : Enabled
UPnP : Enabled
IPconfig : OK
Connection Internet (dixit Windows): OK 7,6Mb !
Connection Wifi ou Ethernet : OK : 192.168.2.2
Par contre impossible d'accèder au web que ce soit par URL classique ou par adresse IP.
J'ai tout essayé : Wifi/Ethernet, PPPoE/PPPoA, Changer d'antivirus (Karspersky/Symantec) etc...
Rien n'y fait ! Tout est OK côté réseau local!
Ceci se produit même sans activité de ma part sur le réseau la nuit : je fais du Grid computing et les accès sont peu nombreux et peu gourmands : pourtant le lendemain matin = Led rouge!.
Une seule façon de refonctionner : reset du modem/routeur : et ça repart pour un tour...
Quelqu'un a-t-il une idée chez Neuf ?
Merci d'avance
jlhal
mercredi 16 avril 2008 à 22:16
Bonsoir (ou bonjour) !
Est-ce que personne n'a déjà été confronté à ce problème ?
Je précise qu'il s'agit bien de l'adresse IP WAN (et non LAN ou WLAN), fournie par le FAI c.a.d Neuf !
Quelqu'un de chez Neuf ou affilié aurait-il(elle) l'amabilité de me répondre ?
jlhal
vendredi 18 avril 2008 à 19:13
<up>
Umarth
lundi 21 avril 2008 à 20:45
Bonjour,
J'ai le même modem (Belkin F5D7633-4 (modem adsl2+/routeur Wifi+4 ports Ethernet)) et je rencontre exactement le même problème depuis environ 1 mois...
Je suis dans le 93 et la durée maximum de fonctionnement est de 48h. Le problème arrive généralement la nuit (mais pas uniquement...)
D'avance merci
omegatron
lundi 21 avril 2008 à 21:23
Bonsoir,
Les logs du routeur disent quoi concernant la recherche de services ppp, l'établissement de la connexion pppoe et l'attribution d'ip ?
Idéalement, c'est une suite du genre: PADI/PADO, PADR/PADS, PPP, Authentification puis IPCP et enfin connexion établie...
jlhal
mercredi 23 avril 2008 à 22:44
Bonsoir !

Bien content de vous lire Omegatron !... J'ai bien fait de patienter ...
Je constate que je ne suis plus seul .
Précision : depuis SFR , en plus d'ALICE (début de mes ennuis), vient d'être dégroupé sur mon NRA !
En ce qui concerne les logs du routeur c'est le vide du moins pour le log qu'on peut obtenir sur le routeur lui-même.
Je ne sais pas si je peux obtenir un log d'une autre façon !
Voici ce que donne mon routeur (ce qui ne diffère pas de ce qui est affiché au moment du problème) ... tout est normal !
Je suis en Ethernet ,PPPoE, MTU 1492 .
DHCP enabled
Firewall disabled
NAT enabled
UPnP enabled
WiFi disabled
ADSL type Interleaved, no defect
Mesures down/up :
Data rate 7582/800
Noise margin 10,4/12
Output power 19,8/12,2
Attenuation 38/21,5
System
Date and TimeRuntime Code version F5D7633-4Av1_UK_1.00.11 Boot Code Version 1.0.37-5.15 Hardware Version V1.0J3 ADSL Modem Code Version A2pB018e.d16d Merci pour votre temps...
omegatron
mercredi 23 avril 2008 à 22:59
Dans un premier temps, je vous conseille de réactiver le firewall SPI intégré à ce routeur. Il bloquera et ignorera dès l'entrée un nombre important de scans, tentatives de connexion et autres dénis de service. C'est même peut-être parce que vous ne lui faites faire que du NAT qu'il finit par planter.
Si vous n'utilisez pas le UPnP, désactivez-le.
Vérifiez sur le site du constructeur si un nouveau firmware ne serait pas disponible pour ce modèle, adressant justement un problème de perte de connexion pppoe.
jlhal
jeudi 24 avril 2008 à 18:03
Bonsoir !
Les paramètres que je vous indique, à l'exception de lUPnP utilisé seulement depuis 2 semaines environ, ont toujours étés utilisés depuis l'origine sans problèmes...
Mais les temps changent et le réseau aussi, je vais donc suivre votre conseil mais (pardon), je n'y crois pas beaucoup car j'ai déjà essayé plusieurs combinaisons sans succès.
Il n'y a malheureusement pas de maj de mon modem/routeur chez Belkin.
Cette version a été implémentée par mes soins dès l'acquisition de ce produit .
Je serais heureux, si "urmath" nous lit (ou une autre personne possédant le même matériel), qu'il nous donne également un aperçu de sa configuration afin de pouvoir comparer ...
Cordialement
PS: Trouvé déconnecté ce matin mais pas de déco depuis...
Umarth
jeudi 24 avril 2008 à 20:20
Bonjour,
Voici les infos concernant mon equipement
Ethernet ,PPPoE
DHCP enabled
Firewall enabled
NAT enabled
UPnP disabled
WiFi enabled
ADSL type Interleaved, no defect
Mesures down/up :
Data rate 7616/800
Noise margin 21.6/13
Output power 15,8/12,2
Attenuation 11/6,5
Runtime Code version F5D7633-4Av1_UK_1.00.17
Boot Code Version 1.0.37-5.15
Hardware Version V1.0J3
ADSL Modem Code Version A2pB018e.d16f
C'est une configuration que j'utilise depuis 1 an sans aucuns problème.
Coté logs pas grand chose non plus
jlhal
jeudi 24 avril 2008 à 22:07
Bonsoir Umarth !
Merci pour votre réponse !
Il semblerait que le runtime soit en 1.00.17 sur votre matériel alors que moi je suis en 1.00.11 .
cela n'a peut-être pas d'influence .
Est-il d'origine ou l'avez vous mis à jour ?
Je n'ai pas trouvé cette version à disposition chez Belkin !
Il y a-t-il eu des FAI dégroupés sur votre NRA depuis l'apparition de votre problème ou encore : l'apparition de votre problème coïnciderait-elle avec l'arrivée d'un ou plusieurs FAI sur votre NRA ?
Pour Omegatron : Il semblerait que la configuration d'Umarth confirme ce que je disais plus haut : la configuration du modem/routeur ne semble pas en cause.
Je soupconnerais volontiers un problème de compatibilité entre FAIs sur le NRA (protocoles d'interrogation des diverses 'box' pour mise à jour ou surveillance du réseau de chacun).
Ou tout simplement coupures non détectées par le DSLAM qui feraient qu'on ne pourrait plus obtenir d' adresse IP qu'après une réinitialisation du modem ?
Cordialement
PS : Toujours pas de déco sans avoir rien changé depuis ce matin...
omegatron
jeudi 24 avril 2008 à 22:30
Vous êtes sur une ligne dégroupée ou non ? Merci de remplir votre profil avec les infos techniques... Si en effet ce n'est pas un plantage du routeur cela me paraît curieux que la session pppoe ne parvienne pas à se rétablir, sauf si problème sur votre connexion côté DSLAM ou souci d'authentification (qui serait plus probable dans le cas d'un non dégroupé) mais sans aucune log... c'est de la divination.
jlhal
vendredi 25 avril 2008 à 19:32
Bonjour !
Voici ce que disent mes infos dans mon compte Neuf (Pas de correspondance précise dans le profil...)
"
Mon forfait : ADSL illimité jusqu'à 20 Méga Vous disposez des abonnements suivants : - Téléphonie Neuf en présélection
Mes packs actuels Vous n'avez pas de pack"
Je ne sais pas dire si je suis dégroupé ou semi dégroupé ou autre chose...
Si je suis en ADSL2+ je devrais être en dégroupé il me semble ?
Toujours est-t-il que je me demande bien pourquoi, si je suis en 20Megas max, je n'ai pas plus de 7,7Mb de bande passante
Cela voudrait dire qu'en fait je suis toujours en ADSL classique ?
D'après degrouptest je devrais pouvoir atteindre 11 à 12Mbps en ADSL2+ ...
J'avais à l'origine un contrat 8Mb ADSL classique avec un modem USB ECI...
Depuis je n'ai changé que le modem USB pour le modem ADSL2+ /routeur Wifi actuel.
Pour info mon login de connexion est de la forme xxxxxxxxx@9veloce512.fr , ce qui ne date pas d'hier !
A propos, j'ai essayé il y quelques minutes de remettre le pare-feu du modem :

3 décos en 5 minutes !
Cordialement
jlhal
lundi 05 mai 2008 à 13:04
Toujours en vacances ?
Umarth ou
Omegatron, si vous êtes là merci de vous manifester
omegatron
lundi 05 mai 2008 à 21:19
Bonsoir,
Si vous êtes sur une ligne non dégroupée, vous ne pouvez pas avoir l'asdl2+ chez 9. Si vous êtes dégroupé partiel, ce qui semble être le cas, il est possible que l'équipement sur lequel vous êtes relié ne gère pas l'adsl2+ pour diverses raisons.
Pour savoir quel abonnement vous avez, il y a une solution pourtant simple: consulter votre facture adsl

(ligne "internet et services haut-débit" dans le paragraphe "vos abonnements, forfaits et options". A titre d'exemple, je suis en dégroupage partiel et il est noté "MaxiDSL 14,90".
jlhal
lundi 05 mai 2008 à 22:28
Bonsoir
Omegatron !
Eh bien d'après ma facture je suis comme vous en MaxiDSL à 14,90€ donc en dégroupage partiel...
Que peux-t-on alors en déduire ?
Mon modem lui peut supporter l'ADSL2+
Est ce que cela pourrait-être un problème d'équipement au niveau du NRA (DSLAM) ?
Il ya plusieurs personnes en dégroupé dans mon voisinage (je les vois lorsque je suis en Wifi, ils ont des SSID style Neuf_xxxx, ce qui est je pense caractéristique des clients Neuf Box) , et nous avons le même NRA.
Merci pour vôtre temps
jlhal
dimanche 11 mai 2008 à 13:05
Pas de problème depuis vendredi soir (date du dernier problème d'adresse IP non obtenue)
Si cela se reproduit je tenterai la MAJ du firmware :
MAJ du firmware du Belkin F5D7633-4uk (ATTENTION Annex A UNIQUEMENT)
http://www.belkin.com/uk/support/article/?...17&scid=314Je n'ai pas encore fait cette MAJ !
En tout état de cause si les pbs perdurent je pense
très fortement à changer de FAI !
jlhal
dimanche 11 mai 2008 à 22:43
MAJ du firmware effectuée !
Firmware 1.00.25
Boot Code 1.0.37-8.7
Cette fois ci il ya un log : (connection normale)
May 11 22:31:07 syslog: User from 192.168.2.2 login success !
May 11 22:31:07 pppd[534]: Clear IP addresses. Connection DOWN.
May 11 22:31:07 pppd[534]: Clear IP addresses. PPP connection DOWN.
May 11 22:31:10 pppd[963]: PPP: Start to connect ...
May 11 22:31:10 pppd[963]: PPP: Sending PADI.
May 11 22:31:10 pppd[963]: PPP: PADO received.
May 11 22:31:10 pppd[963]: PPP server detected.
May 11 22:31:13 pppd[963]: PPP: PADS received.
May 11 22:31:13 pppd[963]: PPP session established.
May 11 22:31:13 pppd[963]: PPP LCP UP.
May 11 22:31:13 pppd[963]: Received valid IP address from server. Connection UP.
J'attends donc maintenant de voir si le problème se reproduit...
jlhal
lundi 12 mai 2008 à 17:07
Pour Umarth :
Mettez à jour votre firmware 1.00.17 : il est bogué : voyez le lien plus haut.
Pour Omegatron :
après la MAJ en 1.00.25, voici un log plus causant car il semble y avoir eu un problème très tôt ce matin à 00:48:55 mais le modem m'a reconnecté à 08:40:34 sans avoir eu besoin de le remettre à zéro : problème d'identification login/mot de passe !
System log:
Jan 1 00:00:28 kernel: ADSL G.994 training
Jan 1 00:00:28 kernel: ADSL G.992 started
Jan 1 00:00:28 kernel: ADSL G.992 channel analysis
Jan 1 00:00:28 kernel: ADSL G.992 message exchange
Jan 1 00:00:28 kernel: ADSL link up, interleaved, us=800, ds=7616
Jan 1 00:00:32 pppd[444]: PPP: Start to connect ...
Jan 1 00:00:32 pppd[444]: PPP: Sending PADI.
Jan 1 00:00:32 pppd[444]: PPP: PADO received.
Jan 1 00:00:32 pppd[444]: PPP server detected.
Jan 1 00:00:58 pppd[444]: PPP: Sending PADI.
Jan 1 00:00:58 pppd[444]: PPP: PADO received.
Jan 1 00:00:58 pppd[444]: PPP server detected.
Jan 1 00:00:58 pppd[444]: PPP: PADS received.
Jan 1 00:00:58 pppd[444]: PPP session established.
Jan 1 00:00:58 pppd[444]: PPP LCP UP.
Jan 1 00:00:58 pppd[444]: Received valid IP address from server. Connection UP.
May 12 00:15:40 syslog: User from 192.168.2.2 login success !
May 12 00:15:40 pppd[444]: Clear IP addresses. Connection DOWN.
May 12 00:15:41 pppd[444]: Clear IP addresses. PPP connection DOWN.
May 12 00:15:43 pppd[1038]: PPP: Start to connect ...
May 12 00:15:43 pppd[1038]: PPP: Sending PADI.
May 12 00:15:45 pppd[1038]: PPP: PADO received.
May 12 00:15:45 pppd[1038]: PPP server detected.
May 12 00:15:45 pppd[1038]: PPP: PADS received.
May 12 00:15:45 pppd[1038]: PPP session established.
May 12 00:15:46 pppd[1038]: PPP LCP UP.
May 12 00:15:46 pppd[1038]: Received valid IP address from server. Connection UP.
May 12 00:27:35 syslog: User from 192.168.2.2 time out
May 12 00:48:46 pppd[1038]: Clear IP addresses. Connection DOWN.
May 12 00:48:46 pppd[1038]: Clear IP addresses. PPP connection DOWN.
May 12 00:48:55 pppd[1038]: PPP: Sending PADI.
May 12 00:48:55 pppd[1038]: PPP: PADO received.
May 12 00:48:55 pppd[1038]: PPP server detected.
May 12 00:48:55 pppd[1038]: PPP: PADS received.
May 12 00:48:55 pppd[1038]: PPP session established.
May 12 00:48:55 pppd[1038]: PPP LCP UP.
May 12 00:48:55 pppd[1038]: User name and password authentication failed.
May 12 08:40:31 syslog: User from 192.168.2.2 login success !
May 12 08:40:33 pppd[6008]: PPP: Start to connect ...
May 12 08:40:33 pppd[6008]: PPP: Sending PADI.
May 12 08:40:33 pppd[6008]: PPP: PADO received.
May 12 08:40:33 pppd[6008]: PPP server detected.
May 12 08:40:33 pppd[6008]: PPP: PADS received.
May 12 08:40:33 pppd[6008]: PPP session established.
May 12 08:40:33 pppd[6008]: PPP LCP UP.
May 12 08:40:34 pppd[6008]: Received valid IP address from server. Connection UP.
=> Depuis ce moment là pas de problème...
Firewall log:
May 12 00:24:54 kernel: Intrusion detected from 218.6.8.227. Source port is 6000, and destination port is 135 which use the TCP protocol.
May 12 00:36:07 kernel: Intrusion detected from 84.99.61.142. Source port is 50199, and destination port is 135 which use the TCP protocol.
May 12 00:36:10 kernel: Intrusion detected from 84.99.61.142. Source port is 50199, and destination port is 135 which use the TCP protocol.
May 12 00:36:16 kernel: Intrusion detected from 84.99.61.142. Source port is 50199, and destination port is 135 which use the TCP protocol.
May 12 00:40:39 kernel: Intrusion detected from 84.99.61.142. Source port is 12587, and destination port is 135 which use the TCP protocol.
May 12 00:40:42 kernel: Intrusion detected from 84.99.61.142. Source port is 12587, and destination port is 135 which use the TCP protocol.
Omegatron, vous aviez raison de dire qu'il y a un problème d'authentification !
Que faire ?
omegatron
lundi 12 mai 2008 à 17:27
Bonjour,
Votre log est curieuse mais pour d'autres raisons que celles évoquées
CODE
May 12 00:48:55 pppd[1038]: User name and password authentication failed.
May 12 08:40:31 syslog: User from 192.168.2.2 login success !
May 12 08:40:33 pppd[6008]: PPP: Start to connect ...
Dans les paramètres de la connexion pppoe , "dial on demand" est-il bien
décoché et "idle time" à
0 ? Parce que à ce que j'en déduis de ce que vous copiez ici, ce n'est pas le cas.
jlhal
lundi 12 mai 2008 à 19:06
Bonjour Omegatron !
Dans cette version de firmware, le dial-on-demand n'est pas affiché dans le menu wan (il l'était dans l'ancienne) , et n'apparait pas dans le fichier de config dont voici un extrait (idle time out est lui bien à 0 dans le fichier et apparait dans le menu).
Toutefois, le time out concerne ma connexion par l'interface web (du moins c'est ce que je crois)
<ppp_conId1 userName="xxxxxxxxx@9veloce512.fr" password="yyyyyyyyy" serviceName="" idleTimeout="0" ipExt="disable" auth="auto" useStaticIpAddr="0" localIpAddr="0.0.0.0" Debug="disable" pppAuthErrorRetry="disable" pppToBridge="enable" />
</pppsrv_0_8_35>
<wan_0_8_35>
<entry1 vccId="1" vlanMuxId="-1" conId="1" name="pppoe_0_38_1" protocol="PPPOE" encap="LLC" firewall="enable" nat="enable" igmp="disable" vlanId="-1" service="enable" instanceId="1509949443" mtu="1492" country="na" isp="na"/>
</wan_0_8_35>
J'ai encore eu ce problème pendant que je rédigeais cette réponse mais la reconnection a éffacé le log!
omegatron
lundi 12 mai 2008 à 19:10
Le time-out indique au routeur au bout de combien de minutes il doit couper la connexion adsl s'il ne détecte aucun trafic wan sortant. En mettant "0", la fonction de déconnexion est désactivée, par conséquent cette valeur doit toujours être à zéro.
Ceci
CODE
pppAuthErrorRetry="disable"
est aussi curieux car cela signifie que en cas d'erreur de connexion ppp par rejet d'identification, le routeur n'essaie jamais de se reconnecter. C'est "enable" que vous devriez avoir ici.
jlhal
lundi 12 mai 2008 à 22:07
Nouvelle déconnection :
May 12 22:35:12 pppd[1050]: Clear IP addresses. Connection DOWN.
May 12 22:35:12 pppd[1050]: Clear IP addresses. PPP connection DOWN.
May 12 22:35:21 pppd[1050]: PPP: Sending PADI.
May 12 22:35:21 pppd[1050]: PPP: PADO received.
May 12 22:35:21 pppd[1050]: PPP server detected.
May 12 22:35:21 pppd[1050]: PPP: PADS received.
May 12 22:35:21 pppd[1050]: PPP session established.
May 12 22:35:21 pppd[1050]: PPP LCP UP.
May 12 22:35:21 pppd[1050]: User name and password authentication failed.
Je tente de modifier le paramètre pppAuthErrorRetry="disable" en "enable" !
omegatron
lundi 12 mai 2008 à 22:16
"@9veloce512.fr" c'est bien le suffixe complet ? parce que si j'avais à m'en servir, le mien est "@9onlineadsl512.ipadsl" (qui n'a pas changé bien que je ne sois plus en ipadsl depuis plus de 4 ans).
jlhal
lundi 12 mai 2008 à 22:37
Oui, je pense que vous avez raison, ce problème pourrait bien venir de là.
J'ai modifié le paramètre en enable" mais de plus je vais maintenant modifier le préfixe du kogin...
Mais pourquoi cela aurait-il fonctionné pendant aussi longtemps sans problème et justement plus à partir d'il y a a 2 mois maintenant ?
Je vous tiens au courant...
jlhal
mardi 13 mai 2008 à 17:53
Hélas !
La modification du préfixe n'y a rien fait , pas plus que d'autoriser les reprises !<pppsrv_0_8_35>
<ppp_conId1 userName="xxxxxxxx@9onlineadsl512.ipadsl" password="yyyyyyyyy" serviceName="" idleTimeout="0" ipExt="disable" auth="auto" useStaticIpAddr="0" localIpAddr="0.0.0.0" Debug="disable" pppAuthErrorRetry="enable" pppToBridge="enable" />
</pppsrv_0_8_35>
<wan_0_8_35>
<entry1 vccId="1" vlanMuxId="-1" conId="1" name="pppoe_0_38_1" protocol="PPPOE" encap="LLC" firewall="enable" nat="enable" igmp="disable" vlanId="-1" service="enable" instanceId="1509949444" mtu="1492" country="na" isp="na"/>
</wan_0_8_35>
May 13 13:59:26 pppd[443]: Clear IP addresses. Connection DOWN.
May 13 13:59:26 pppd[443]: Clear IP addresses. PPP connection DOWN.
May 13 13:59:35 pppd[443]: PPP: Sending PADI.
May 13 13:59:35 pppd[443]: PPP: PADO received.
May 13 13:59:35 pppd[443]: PPP server detected.
May 13 13:59:35 pppd[443]: PPP: PADS received.
May 13 13:59:35 pppd[443]: PPP session established.
May 13 13:59:35 pppd[443]: PPP LCP UP.
May 13 13:59:36 pppd[443]: User name and password authentication failed.
=> Connection manuelle (bouton 'connect' dans l'interface web) :
May 13 18:39:05 pppd[30524]: PPP: Start to connect ...
May 13 18:39:05 pppd[30524]: PPP: Sending PADI.
May 13 18:39:10 pppd[30524]: PPP: PADO received.
May 13 18:39:10 pppd[30524]: PPP server detected.
May 13 18:39:10 pppd[30524]: PPP: PADS received.
May 13 18:39:10 pppd[30524]: PPP session established.
May 13 18:39:10 pppd[30524]: PPP LCP UP.
May 13 18:39:11 pppd[30524]: Received valid IP address from server. Connection UP.
Je tente de revenir en MTU 1432 (c'est la valeur par défaut du modem pour PPPoE LLC)
Mais là je crois qu'il y a VRAIMENT un problème chez NEUF (même si mon modem ne retente pas d'authentification)
omegatron
mardi 13 mai 2008 à 18:03
Je ne vous demandais pas de changer le suffixe @xxxxxxxxxx mais de simplement vérifier s'il n'était pas incomplet

Si l'authentification échoue, nous sommes désormais à peu près sûrs que c'est dû à une surcharge ou un autre problème sur le radius ou le BAS.
jlhal
mardi 13 mai 2008 à 18:44
Bonjour
Omegatron !
Pardon pour l'inversion suffixe/préfixe
Pouvez vous faire quelque chose vous-même : intervention auprès de Neuf ?
Je ne crois pas que les intervenants hotline soient aussi compétents que vous

: je présente d'avance mes excuses à ceux qui ne reconnaitront pas dans cette affirmation
De plus , par ces dialogues vous avez déjà les infos sur le problème et sa manifestation.
J'ai envoyé un mail à Belkin par l'intermédiare de leur page de MAJ firmware (c'est une pré-release du 21/02/2008) en leur signalant les défauts que j'ai constatés
omegatron
mardi 13 mai 2008 à 19:14
Je suis un client, comme vous, rien de plus.
En revanche, il y a une ultime chose à tester: l'emploi d'identifiants génériques comme sur les 9box => "0123456789@neufpnp" comme utilisateur et ce que vous voulez comme mot de passe. Profitez-en pour mettre le MTU soit à 1400 soit à 1492... Un MTU à 1432 ça n'apporte rien.
jlhal
mardi 13 mai 2008 à 19:25
Je vous tiens au courant pour la manip login/mot de passe.
Le MTU 1432 est recommandé par Belkin sauf si le FAI demande explicitement un MTU particulier...
En dernier recours j'appellerai la hotline et si je n'obtiens pas de solution alors...
omegatron
mardi 13 mai 2008 à 20:05
1492 est la valeur normale en pppoe. Les valeurs inférieures sont destinées à contourner certains soucis réseau (MSN par exemple ou AOL avec son MTU de 1400 pour en citer les plus célèbres). En tout état de cause, le réseau 9 est parfaitement standard sur ce point et ne nécessite normalement pas de diminuer le MTU.
jlhal
mardi 13 mai 2008 à 22:29

Re-déconnection vers 21h00 :
je viens de me reconnecter en utilisant <monnumtel>@neufpnp et mon mot de passe habituel.
J'ai remis le MTU à 1492.
Je vous tiens au courant du dénouement
jlhal
mercredi 14 mai 2008 à 18:14

Pas plus de réussite cette fois-ci avec le login générique :
CODE
System log:
Jan 1 00:00:27 kernel: ADSL G.994 training
Jan 1 00:00:27 kernel: ADSL G.992 started
Jan 1 00:00:27 kernel: ADSL G.992 channel analysis
Jan 1 00:00:28 kernel: ADSL G.992 message exchange
Jan 1 00:00:28 kernel: ADSL link up, interleaved, us=800, ds=7424
Jan 1 00:00:31 pppd[448]: PPP: Start to connect ...
Jan 1 00:00:31 pppd[448]: PPP: Sending PADI.
Jan 1 00:00:32 pppd[448]: PPP: PADO received.
Jan 1 00:00:32 pppd[448]: PPP server detected.
Jan 1 00:00:47 pppd[448]: PPP: PADS received.
Jan 1 00:00:47 pppd[448]: PPP session established.
Jan 1 00:00:47 pppd[448]: PPP LCP UP.
Jan 1 00:00:47 pppd[448]: Received valid IP address from server. Connection UP.
May 14 00:18:32 kernel: ADSL link down
May 14 00:20:00 pppd[448]: Clear IP addresses. Connection DOWN.
May 14 00:20:00 pppd[448]: Clear IP addresses. PPP connection DOWN.
May 14 00:20:09 pppd[448]: PPP: Sending PADI.
May 14 00:20:35 pppd[448]: PPP: Sending PADI.
May 14 00:21:01 pppd[448]: PPP: Sending PADI.
May 14 00:21:27 pppd[448]: PPP: Sending PADI.
May 14 00:21:53 pppd[448]: PPP: Try to connect to PPP server ...
May 14 00:21:53 pppd[448]: PPP: Sending PADI.
May 14 00:22:20 pppd[448]: PPP: Sending PADI.
May 14 00:22:46 pppd[448]: PPP: Sending PADI.
May 14 00:23:12 pppd[448]: PPP: Sending PADI.
May 14 00:23:38 pppd[448]: PPP: Sending PADI.
May 14 00:23:53 kernel: ADSL G.994 training
May 14 00:23:58 kernel: ADSL G.992 started
May 14 00:24:00 kernel: ADSL G.992 channel analysis
May 14 00:24:04 pppd[448]: PPP: Try to connect to PPP server ...
May 14 00:24:04 pppd[448]: PPP: Sending PADI.
May 14 00:24:05 kernel: ADSL link up, interleaved, us=800, ds=7456
May 14 00:24:06 pppd[448]: PPP: PADO received.
May 14 00:24:06 pppd[448]: PPP server detected.
May 14 00:24:06 pppd[448]: PPP: PADS received.
May 14 00:24:06 pppd[448]: PPP session established.
May 14 00:24:06 pppd[448]: PPP LCP UP.
May 14 00:24:06 pppd[448]: Received valid IP address from server. Connection UP.
May 14 01:11:46 kernel: ADSL link down
May 14 01:13:24 kernel: ADSL G.994 training
May 14 01:13:28 kernel: ADSL G.992 started
May 14 01:13:31 kernel: ADSL G.992 channel analysis
May 14 01:13:35 kernel: ADSL G.992 message exchange
May 14 01:13:36 pppd[448]: Clear IP addresses. Connection DOWN.
May 14 01:13:36 kernel: ADSL link up, interleaved, us=800, ds=7456
May 14 01:13:36 pppd[448]: Clear IP addresses. PPP connection DOWN.
May 14 01:13:45 pppd[448]: PPP: Sending PADI.
May 14 01:13:45 pppd[448]: PPP: PADO received.
May 14 01:13:45 pppd[448]: PPP server detected.
May 14 01:13:45 pppd[448]: PPP: PADS received.
May 14 01:13:45 pppd[448]: PPP session established.
May 14 01:13:45 pppd[448]: PPP LCP UP.
May 14 01:13:45 pppd[448]: Received valid IP address from server. Connection UP.
May 14 07:28:15 pppd[448]: Clear IP addresses. Connection DOWN.
May 14 07:28:18 pppd[5612]: PPP: Start to connect ...
May 14 07:28:18 pppd[5612]: PPP: Sending PADI.
May 14 07:28:18 pppd[5612]: PPP: PADO received.
May 14 07:28:18 pppd[5612]: PPP server detected.
May 14 07:28:44 pppd[5612]: PPP: Sending PADI.
May 14 07:28:45 pppd[5612]: PPP: PADO received.
May 14 07:28:45 pppd[5612]: PPP server detected.
May 14 07:29:11 pppd[5612]: PPP: Sending PADI.
May 14 07:29:11 pppd[5612]: PPP: PADO received.
May 14 07:29:11 pppd[5612]: PPP server detected.
May 14 07:29:51 pppd[6536]: PPP: Start to connect ...
May 14 07:29:51 pppd[6536]: PPP: Sending PADI.
May 14 07:29:51 pppd[6536]: PPP: PADO received.
May 14 07:29:51 pppd[6536]: PPP server detected.
May 14 07:29:51 pppd[6536]: PPP: PADS received.
May 14 07:29:51 pppd[6536]: PPP session established.
May 14 07:29:51 pppd[6536]: PPP LCP UP.
May 14 07:29:51 pppd[6536]: Received valid IP address from server. Connection UP.
May 14 07:29:54 pppd[6536]: Clear IP addresses. Connection DOWN.
May 14 07:29:54 pppd[6536]: Clear IP addresses. PPP connection DOWN.
May 14 07:29:58 pppd[6688]: PPP: Start to connect ...
May 14 07:29:58 pppd[6688]: PPP: Sending PADI.
May 14 07:29:58 pppd[6688]: PPP: PADO received.
May 14 07:29:58 pppd[6688]: PPP server detected.
May 14 07:29:58 pppd[6688]: PPP: PADS received.
May 14 07:29:58 pppd[6688]: PPP session established.
May 14 07:29:58 pppd[6688]: PPP LCP UP.
May 14 07:29:58 pppd[6688]: Received valid IP address from server. Connection UP.
May 14 17:55:58 pppd[6688]: Clear IP addresses. Connection DOWN.
May 14 17:55:58 pppd[6688]: Clear IP addresses. PPP connection DOWN.
May 14 17:56:07 pppd[6688]: PPP: Sending PADI.
May 14 17:56:07 pppd[6688]: PPP: PADO received.
May 14 17:56:07 pppd[6688]: PPP server detected.
May 14 17:56:08 pppd[6688]: PPP: PADS received.
May 14 17:56:08 pppd[6688]: PPP session established.
May 14 17:56:08 pppd[6688]: PPP LCP UP.
May 14 17:56:08 pppd[6688]: User name and password authentication failed.
=> Sil n'y a pas de perte de synchro avant la tentative de connection (ADSL link DOWN et non pas connection Down !) alors il n'y a plus d'authentification: un CORP-9 pourrait-il répondre à ça ?
Je suis revenu à mon login d'origine...
jlhal
lundi 19 mai 2008 à 18:30
Je ne suis pas déconnecté lorsque je ne fais rien (et encore...)
Hier au soir , pas loin de 10 déconnections en quelques heures avec refus d'authentification à suivre !
Alors
Désolé Neuf ! Je RESILIE ! (Après plusieurs années d'abonnement)En effet, après un appel à la hotline (coupé au bout d'une demi-heure : c'est la loi sauf que le temps d'attente est compris !), un 2ème appel pour obtenir un nouvel identifiant et nouveau mot de passe ,
les problèmes ont empiré
Je vais donc prendre une box mais chez Free
Je sais qu'on n'embauche pas des ingénieurs réseau ni même des titulaires de BTS dans les hotlines, mais le jour où les FAI (en général) auront compris que la compétence (et donc le salaire !!!!) sont plus rentables à long terme, alors peut-être aurons nous des assistances dignes de ce nom.
Etant informaticien moi-même je sais de quoi je parle...
Merci
Omegatron pour votre aide

, n'étant qu'un client comme moi vous ne pouvez pas faire grand chose de plus (Ceci est absolument sincère et pas ironique).
jlhal
lundi 26 mai 2008 à 20:59
Voilà, c'est fait.
J'attends ma Frebox HD.
En attendant je suis connecté avec mon modem/routeur Belkin F5D7633-4av.
Pour ceux que cela intéresse:
Free dégroupé TOTAL (Freebox HD):
VPI/VCI 8/36 (8/35 en non dégroupé) , VC/MUX
static IP : entrer l'IP donnée par Free ainsi que le gateway(passerelle) et les DNS,
pas besoin de login/mot de passe
Et ça fonctionne...
Dommage Neuf...
Umarth
mercredi 10 septembre 2008 à 14:50
Bonjour,
De retour après une longue période hors de nos frontières, je pensais (naïvement) que le problème serait résolu ... Hélas il n'en est rien!
Pire que ca je constate que Jihlal a baissé les bras et j'envisage de le suivre de près...
Existe t il, à votre avis, la moindre chance pour que ce problème soit pris en charge par quelqu'un de chez Neuf sans passer par la "hotline"? Depuis mon retour (1 semaine environ) j'en suis à 3-4 reboot de routeur par soirée (soit 3-4heures d'utilisation)
Je suis désespéré, j'ai même essayé d'appeler la hotline un jour de grosse déprime (ha ha , au moins j'ai bien ri

)
D'avance merci
Umarth
mercredi 10 septembre 2008 à 22:39
Re-bonjour,
Par acquis de conscience je me suis tout de même fait prêté un autre modem / routeur (Netgear DG834G)
... le résultat est le même. Malheureusement les logs de ce dernier sont encore moins clairs que le Belkin
CODE
Wed, 2008-09-10 21:14:06 - LCP down.
Wed, 2008-09-10 21:14:16 - Initialize LCP.
Wed, 2008-09-10 21:14:16 - LCP is allowed to come up.
Wed, 2008-09-10 21:15:00 - LCP down.
Wed, 2008-09-10 21:15:06 - Initialize LCP.
Wed, 2008-09-10 21:15:06 - LCP is allowed to come up.
Wed, 2008-09-10 21:15:07 - CHAP authentication failed
Wed, 2008-09-10 21:15:07 - LCP down.
Wed, 2008-09-10 21:15:15 - Initialize LCP.
Wed, 2008-09-10 21:15:15 - LCP is allowed to come up.
Wed, 2008-09-10 21:15:15 - CHAP authentication failed
Wed, 2008-09-10 21:15:15 - LCP down.
Wed, 2008-09-10 21:15:24 - Initialize LCP.
Wed, 2008-09-10 21:15:24 - LCP is allowed to come up.
Wed, 2008-09-10 21:15:36 - LCP down.
Wed, 2008-09-10 21:15:45 - Initialize LCP.
Wed, 2008-09-10 21:15:45 - LCP is allowed to come up.
Wed, 2008-09-10 21:15:46 - CHAP authentication success
Mais bon on retrouve tout de même ce problème d'identification
Je commence sérieusement à penser que le salut est dans la fuite!
Ceci est une version "bas débit" de Justneuf. Pour voir la version complète avec plus d'information, la mise en page et les images, veuillez
cliquer ici.