Reconnexion automatique

par **Chirrete** » 18 Oct 2003 17:19

comment fait on pour configurer IPCOP afin qu'il se reconnecte tout seul à l'ADSL après la déconnexion quotidienne du FAI ? Merci d'avance ? PS : si vous connaissez déjà un post, merci de me l'indiquez car j'ai passé 20 minutes à chercher, et je n'ai rien trouvé.

par **Fesch** » 18 Oct 2003 17:41

Est-il si dur? "ipcop reconnexion" => <A HREF="http://www.ixus.net/modules.php?op=modload&name=Forum&file=search&sortby=p.post_time%20desc&page=1&searchboth=both&search_username=&addterms=all&forum=all" TARGET="_blank">103 résultats trouvés dans le(s) sujet(s)</A> Sur la page "Dialup" Maximum retries: 10 Maximum retries: Idle timeout (mins; 0 to disable): 0 Persistent connection: YES Dial on Demand: NO Dial on Demand for DNS: NO Connect on IPCop restart: YES ISP requires Carriage Return: NO Depuis que j'ai installé la version 1.4.0a1, plus de problèmes!

par **Chirrete** » 03 Nov 2003 13:36

ça marche pas.... Ya t'il autre chose à vérifier ou modifier ?

par **Fesch** » 03 Nov 2003 13:40

Quel FAI? Quel modem?

par **Chirrete** » 03 Nov 2003 13:58

FAI : nordnet Modem : Fast Ethernet 1100 E de chez Sagem

par **Fesch** » 03 Nov 2003 14:06

Hmmm ... tout cel aest assez étrange ... ... en fait, ce que je ne comprend pas non-plus, c'est que m^'eme maintenant que cela semble fonctionné chjez moi, il y a des jours où ça tient pas et tout tombe ... ... je me demande si c'est pas aussi dû à de mauvais signaux de FT ... mais afin de trouver cela ... <IMG SRC="images/smiles/icon_confused.gif"> <IMG SRC="images/smiles/icon_confused.gif"> <IMG SRC="images/smiles/icon_confused.gif"> Est-ce qu'il n'y a pas quelqu'un d'autre qui ait une idée???

par **Gesp** » 03 Nov 2003 15:16

Ma compréhension du problème est la suivante. Il y a plusieurs problèmes qui peuvent potentiellement se présenter représentant chacun un cas particulier : - le Speedtouch usb Il arrive qu'un bug à un niveau mal identifié provoque une réinitialisation partielle de l'usb en cas de forte charge (message EMI) Dans ce cas le modem peut se reconnecter en relançant rc.alcatelusb (ou rc.alcatelusbk pour le driver kernel) qui fait un reset de l'usb pour pouvoir relancer modem_run en rechargeant le firmware. Mais pppd se contentant de relancer pppoa3, la connexion échoue parce que modem_run n'est pas présent et les interfaces usb ne sont pas prêtes. Si le modem ne reçoit pas la synchro, il attend indéfiniment qu'elle soit rétablie quand rc.acatelusb est lancé. - le modem ECI - il arrive qu'un bug à un niveau mal identifié provoque une réinitialisation partielle de l'usb en cas de forte charge de manière similaire au speedtouch user-mode - si la synchro est perdue, le driver ne sait pas la rattraper. Dans les 2 cas, la relance par rc.eciadsl fonctionne. Dans le cas de ces 2 modems usb, il n'est pas impossible que le bug apparaisse du fait de la trop grande consommation de modems ECI et Speedtouch. Cependant le driver ECI faisait très souvent cela en PPPoE avec la version 0.7 du driver et beaucoup moins avec la V0.8 donc je pense plutôt à un problème logiciel dans la gestion de l'usb que d'alimentation. - les modems en PPPoE La capacité de reconnexion est variable et dépend de comment vous êtes déconnectés. En général, au démarrage de la connexion, le premier essai de connexion est le bon. Mais quand la connexion est interrompue, pppd relance pppoe en rencontrant de problèmes de timout (PADO ou PADS). Pour simuler le problème, vous pouvez tester quand la connexion est active en faisant ( cas 1) killall -1 /usr/sbin/pppoe la reconnexion est immédiate dans la plupart des cas au premier essai. en faisant (cas2) killall -KILL /usr/sbin/pppoe la reconnexion arrive à fonctionner mais après de nombreux essais ( très souvent plus de 4/5, quelque fois plus, essayer de mettre 20 ou plus en nombre d'essais, c'est plus sur que 10 ou moins) Dans le cas ou vous perdez la synchronisation de manière très momentanée, vous êtes comme dans le cas 2, par exemple si vous débrancher la ligne téléphonique 1mn, vous vous retrouver comme dans ce cas. Je suppose que dans le cas 1, la session est correctement terminée et que l'ouverture d'une nouvelle session ne pose pas de problème, ce qui n'est pas ce qu'il se passe dans le cas 2 malgré le fait qu'il y ait un PADT dans le log. Je suppose que l'interruption des 24 h est plutôt proche de l'essai 2 que de l'essai 1. Je ne sais pas pourquoi. Est-ce que c'est FT qui termine 'mal' la session? Ce serait étonnant. Est-ce qu'il y a un réglage du parefeu qui empêche des données de sortir/rentrer quand la session est incomplétement terminée? Il est aussi possible qu'il soit nécessaire d'attendre un timout du DSLAM quand une session n'est pas terminée complètement pour en redemander une nouvelle. Quand, avec un matériel supportant PPPoA et PPPoE, je passe d'un fonctionnement en PPPoA à un fonctionnement en PPPoE (et uniquement dans ce sens là), il est nécessaire que j'attende 5 mn avant pouvoir me reconnecter. Je suis en train de mettre en place un petit mécanisme qui permettra de se reconnecter dans tous ces cas de connexion PPP ( quand on a pas demandé d'arrêter la connexion mais qu'elle n'est plus active). Ce n'est qu'un palliatif, il eut été préférable de comprendre exactement ou le problème se pose mais au moins cela devrait bien rendre quelques services. Cela devrait fonctionner d'içi la fin de la semaine.

par **shadowman** » 03 Nov 2003 23:12

Gesp, tu es notre sauveur a tous... g moi aussi des pb de deco intempestives... ca me l'a fait avec une 1.3a5 ( au début, la reco fonctionnait, puis au bout d'une semaine rien afaire, fallait rebooter, puis ca a remarché 15 ours plus tard... ) la je suis passé sous la 1.4a1, ca a tenu les 5 premies jours, et plus maintenant, sans que je ne change rien <IMG SRC="images/smiles/icon_confused.gif"> g un modem USB Sagem Fast 800... et je suis chez mamadou...

par **Chirrete** » 04 Nov 2003 20:37

Effectivement, c'est très aléatoire, et ça doit venir du FAI..

par **Gesp** » 04 Nov 2003 23:06

>g un modem USB Sagem Fast 800... Normalement il n'y a pas de problème de reconnexion avec ce modem en PPPoA. Si tu as des problèmes de reconnexion, c'est en général un abus de peer to peer qui en est la cause.

par **Chirrete** » 05 Nov 2003 10:27

Sauf que mois, c'est un réseau d'entreprise où le p2p est interdit, et d'ailleurs bloqué par IPCOP. J'ai effectivement fait le test où on débranche la prise proposé plus haut, et c'est exactement ce qu'il se passe. Le pb est : comment le FAI coupe t'il sa connexion toutes les 24h ?

par **Gesp** » 05 Nov 2003 11:08

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD>En réponse à:<HR></TD></TR><TR><TD><BLOCKQUOTE> Sauf que mois, c'est un réseau d'entreprise où le p2p est interdit, et d'ailleurs bloqué par IPCOP. </BLOCKQUOTE></TD></TR><TR><TD><HR></TD></TR></TABLE> Je me doute parce que le PPPoE est surtout utilisé sur les modems ethernet et c'est ce qui equipe principalement les entreprises. <TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD>En réponse à:<HR></TD></TR><TR><TD><BLOCKQUOTE> J'ai effectivement fait le test où on débranche la prise proposé plus haut, et c'est exactement ce qu'il se passe. Le pb est : comment le FAI coupe t'il sa connexion toutes les 24h ? </BLOCKQUOTE></TD></TR><TR><TD><HR></TD></TR></TABLE> Je n'ai pas tracé la reconnexion, surtout que c'est assez embétant de devoir garder l'option debug pendant 24 h mais il faudrait faire l'essai (peut-être avec un disque plus gros que le 425 Mo que j'ai actuellement sinon mon log va déborder.) Et puis ce n'est pas facile de ne faire qu'un test par 24h Il y a 2 manières propres d'arrêter une connexion PPPoE : - envoyer au niveau PPP une option LCP Terminate-Request ou - envoyer au niveau PPPoE un PADT (et ne plus rien envoyer après comme indiqué là <a href="http://www.zvon.org/tmRFC/RFC2516/Output/chapter5.html)" target="_blank">http://www.zvon.org/tmRFC/RFC2516/Output/chapter5.html)</a> "Even normal PPP termination packets MUST NOT be sent after sending or receiving a PADT." Il est évident que dans le cas ou on débranche la ligne pour un test, rien n'est transmis <IMG SRC="images/smiles/icon_biggrin.gif"> et que c'est l'option LCP de 3*20s qui fait tomber la session PPP de chaque coté de la liaison. Je vais essayer de tracer pour voir la différence entre killall -KILL /usr/sbin/pppoe qui se reconnecte mal et killall -1 /usr/sbin/pppoe qui se reconnecte bien Après si on voit une différence, il faudra comprendre pourquoi et ce ne sera peut-être pas évident <IMG SRC="images/smiles/icon_confused.gif"> Peut-être qu'il y a une règle iptables qui cause problème parce qu'il semble que dans d'autres distrib ce problème ne se pose pas?

Reconnexion automatique

Qui est en ligne ?