Salut à tous !
 
j'essaie de me faire un script perso de reconnexion, parce qu'il me semble qu'il faille recompiler le noyau apres avoir patcher le module... et ça j'ai jamais trop fait, en plus c'est pas vraiment détaillé sur le site de benoit papillaut, et j'ai rien trouvé ailleurs...
 
donc, je me suis dit que je pourrais me faire un script de reconnexion...
 
j'ai déjà l'idée du code, sauf pour :
 
1) la boucle infinie...
 
2) faire que je puisse lancer mon script... une fois que j'ai créé le fichier texte, il doit lui appliquer quelque chose qui fasse qu'il devienne un script...
 
 
Vous avez une idée, et surtout des remarques ?
 
Merci...

 
enregistre le fichier sous "reconnexion" par exemple, puis fais : "chmod +x reconnexion" pour lui donner les droits d'éxécution
 
ajoute-le dans ton /etc/rc.local par exemple pour qu'il soit éxécuté au démarrage de la machine.... ce que je faisais dans mon script avant, c'était pinger une adresse sûre, si j'avais "host unreachable" je refaisais un ping sur une autre adresse sûre, si ça me retournait encore une fois "host unreachable", je faisais un "killall pppd" et je lançais la fin du script de Benoît Papillaux, celle où il lance l'autentification, je vérifiais si pppd était bien chargé, si oui ça reprenait la boucle

Boucle infinie = mauvaise idée. Ca risque de te bouffer de la mémoire. Vaut mieux utiliser un script de demarrage executé... au demarrage et un script de verification executé via la crontab. Ce sera mieux p'têt.

PAS BESOIN DE FAIRE UN SCRIPT POUR LA RECONNEXION AUTOMATIQUE !
Il suffit de mettre "persist" dans le fichier /etc/ppp/options et d'avoir bien activé le module n_hdlc dans son kernel.
Et ce sujet a déjà été abordé moultes fois, la fonction "recherche" n'est pas là pour faire joli.

Excellent ! C'est à peu ce que je voulais faire, mais comment tu codes le test du ping ? est ce que le ping te renvoir une valeur particulière quand il y a "network unreachable" ?
 
Petite question parce que je suis curieux... à quoi sert : #!/bin/sh ? parce que comme il y a un # je croyais que ça ne faisait rien... mais comme c'est quelque chose de particulier après peut etre que ça fait quelque chose....
 
pour le chmod +x reconnexion, ça c'est bon j'ai compris
 
Euh... ah oui, au démarrage, j'effectue ma connexion dans le script du firewall au début, ça m'arrangeait parce que j'etais sur que le script du firewall se fait juste après... Mais comment etre sur que mon script reconnexion va etre lancé après rc.firewall ??? Est ce qu'il y a un ordre dans rc.local ?
 
 
encore un truc (désolé...) quand tu parles de "la fin du script de Benoît Papillaux, celle où il lance l'autentification", est ce que tu parles de ça : pppd call adsl ?
 
 
En fait, ce à quoi j'avais pensé, c'etait carrément de démonter le port usb et de le remonter... puis de relancer mon script rc.firewall qui me reconnectera et repartagera ma connexion sur mon LAN... D'ailleurs avec ta méthode est ce qu'il est nécessaire de relancer le firewall ?
 
Encore merci !  

 
 
En fait, j'ai lu ça sur le How to de sourceforge... mais le probleme c'est qu'il parle de recompiler le noyau et ça c'est pas encore de mon ressort...  
 
C'est sur que ce que tu me dis me semble bien bien plus simple... mais comment vérifié si n_hdlc est dans mon kernel ? S'il l'est et que je tape "persist" dans /etc/ppp/options ça marchera à coup sur ? Et avec tout ça, il sera tout seul retrouvé comment relancer la connexion ?  
 
Ca a l'air super en tous cas !

zytrahus5 a écrit a écrit : Excellent ! C'est à peu ce que je voulais faire, mais comment tu codes le test du ping ? est ce que le ping te renvoir une valeur particulière quand il y a "network unreachable" ?   Petite question parce que je suis curieux... à quoi sert : #!/bin/sh ? parce que comme il y a un # je croyais que ça ne faisait rien... mais comme c'est quelque chose de particulier après peut etre que ça fait quelque chose....   pour le chmod +x reconnexion, ça c'est bon j'ai compris

 
ca s appelle le shebang , en gros ton shell lis cette ligne dans le cas
d un fichier executable ( avec le "bit" a x ) puis lance l interpreteur
que tu y a mis genre perl , sh , bash python ...

 
merci

zytrahus5 a écrit a écrit :       En fait, j'ai lu ça sur le How to de sourceforge... mais le probleme c'est qu'il parle de recompiler le noyau et ça c'est pas encore de mon ressort...     C'est sur que ce que tu me dis me semble bien bien plus simple... mais comment vérifié si n_hdlc est dans mon kernel ? S'il l'est et que je tape "persist" dans /etc/ppp/options ça marchera à coup sur ? Et avec tout ça, il sera tout seul retrouvé comment relancer la connexion ?     Ca a l'air super en tous cas !

 
 
  UP

------------> lucaramel
 
Voilà ce que j'ai vu sur le site sourceforge ;
 

 
est ce qu'il me faut recompiler mon noyau ou pas ??? et en ce qui concerne le patch est ce qu'il le faut le patcher ?

tu as quelle version du noyau ?

c'est une red hat 7.2... je crois que c'est un noyau 2.4.9

cat /proc/version pour avoir la version du noyau

c'est clair que l'utilisation de persist est bien meilleure qu'un script....
 
il faut simplement simplement l'activer dans le noyau et le recompiler (>=2.4.18) sinon il faut chopper les sources du speedtouch et patcher les sources du noyau (< 2.4.18) avec le patch n_hdlc (car il y a un bug dans les noyaux antérieurs au 2.4.18)
 
sinon quand je dis qu'il faut utiliser la fin du script de Benoit Papillaux, c'est carrément dans le script /usr/local/bin/startmodem à partir de l'endroit où il y a la ligne : echo "connect modem...";
 
donc pas besoin de couper l'usb (c'est ce que je faisais avant ce script )
 
autrement je n'utilise plus de script pour la reconnexion, j'ai plus de problème de déconnexion intenpestive avec konqueror depuis que j'ai réinstallé la distro (ce qui fait déjà un bail)
sinon j'ai changé de noyau ce week end sur la machine qui a le modem, passé d'un 2.4.7-10 patché n_hdlc à un 2.4.18 de base et le script ne sert juste qu'à reconnecter plus rapidement qd j'ai eu une perte de connexion
 
bref si tu peux utiliser persist (donc avoir un n_hdlc non buggé), fais-le

tu peux m'en dire un peu plus sur comment tu as patché n_hdlc s'il te plait ?
 
Merci beaucoup  

tu as un noyau 2.4.7-10 si j'ai bien compris (le noyau d'origine de la red hat 7.2)  
 
tu n'as pas besoin de patcher si tu prends un noyau récent, je te conseille le 2.4.18 car il y a tout de même quelques petits problèmes avec 2.4.19
 
car de toutes façons, si tu gardes le même noyau il te faudra dans les deux cas recompiler, donc tant qu'à faire autant prendre un nouveau noyau, puis le 2.4.7 "y put l'paté"  
 
tu pourras trouver les sources du noyau...... ici en cliquant là
 
ensuite il te faudra le configurer  
ça c'est le plus difficile au début, mais pas mal de sites expliquent comment le faire, ça peut se trouver sur lea-linux et sur le site de Dark, sinon google et compagnie sont tes amis

qu'est ce qu'il en devient de tout ce que j'ai fait sur ma machine ? ma connexion, le reseau, samba, et tout ça, ça marchera encore ?
 
ou est ce que de recompiler va impliquer la perte de données ???

pour la 2° question : non
 
pour les 1° : ça va pas bouger, c'est pas stocké au même endroit (et oui pas comme dans windows avec la base de registre...)
 
sinon, j'ai uploadé les pages correspondantes du manuel de la Mandrake qui sont très bine faites :
http://mjules.free.fr/compiling-kernel.html

 
merci c'est super sympa !    
je vais lire ça et si je m'en sens capable je tenterai...

de toutes façons, quand tu compiles un noyau c'est bien simple, les commandes générales sont :
 
make menuconfig
(là tu tripotes les réglages, tu sors en enregistrant la config)
make clean dep modules
make modules_install
make bzImage
cp arch/i386/boot/bzImage /boot/vmlinux-X.Y.Z
 
si tu utilises grub, t'as juste 3 lignes à rajouter dans le grub.conf et a redémarrer puis choisir le nouveau noyau au boot, pour lilo faut pas un initrd, modifier le lilo.conf, relancer lilo, puis redémarrer, bref c'est là que grub est bien plus pratique

je sais meme pas si c'est lilo ou grub... tout ce que je sais, c'est que je n'ai pas d'interface graphique ! je suis en mode console, en plus j'ai pas d'ecran de brancher, je configure tout en https://192.168.1.1:81/ là j'ai aussi un shell très pratique !

Pour info, je n'ai jamais appliqué ce patch sur mon kernel (et ce depuis un an, on en était au ... je sais plus) et j'ai toujours pû me reconnecter. Maintenant, le patch est intégré donc il n'y (vraiment) plus rien à faire, juste un modprobe n_hdlc pour être sûr que le module est chargé.

donc si j'ai bien compris, avec ma version du driver (la derniere a l'heure actuelle) je peux certainement me reconnecter sans avoir à recompiler le noyer ou patcher quoi que se soit, et ce sans aucun script de reconnexion ?    

Oui. Tu dois juste faire un modprobe n_hdlc et mettre persist dans /etc/ppp/options. C'est comme ça que j'ai fait et ça marche très bien.

 
dans mon fichier options, y a qu'une ligne avec juste écrit : lock ????     c'est pas plutot louche ça ???  

faut il que j'enleve lock ? ou je rajoute simplement persist ?

UP......

N'enlève pas lock. Mon fichier contient :
 
lock
noauth
noipdefault
usepeerdns
persist

 
est ce qu'il faut que j'ajoute aussi ce que tu as, ou bien c'est pas nécessaire ?

UP...   mais qui saute le plus haut ?

g les meme ds le mien, met les aussi

ça permet de se reconnecter plus rapidement ?
 
parce que sans, je me reconnectais aussi, mais est ce que ça va plus vite avec ?

persist la reco est instantané
 
EDIT: les autres je c pas mais kom tt le monde  al'air de les avoir

 
je les ai ajouté, et plus moyen de se connecter !!! je les ai enlevé un à un... et y a fallu tous les enlevés pour que ça remarche :-(
 
Que faire ?

 
sé po

en fait, il me semble avoir localisé le problème...
 
ça vient pas d'internet... c'est qu'il se déconnecte du réseau local... je sais pas pourquoi no comment...
 
ou est ce que s'initialise le réseau ?
c'est possible de faire qu'il se déconnecte pas du LAN ?

 
il se deco du lan :? alors la je c pas, il se passe koa exactment? ya pas un conflit kkonk? tu as fait un ifconfig pour etre sur ke eth0 est down?

pas c'est pas évident parce que pas d'ecran, mon seul control c'est sur le port 81 de https donc depuis le LAN...

je suppose qu'il est down car pas de ping depuis le LAN