Reprise du message précédent :
Bon en suivant la page à la lettre : http://www.da-silva.nom.fr/adsl/linux/pppoatm/, j'ai quasiement réussi. Je posterai ici pour expliquer 2 ou 3 trucs une fois que j'y serai arrivé, mais il me reste un problème : le modprobe unicorn_pci passe sans problème, mais la connexion avec pppd plante car celui-ci tente de se connecter en utilisant comme paramètres vpi.vci 15.16 au lieu de 8.35. D'où ma question : où modifie t-on ces paramètres ? La page Da Silva parle du fichier /etc/ppp/options, mais comment déclare t-on ces paramètres ? (si c bien dans ce fichier qu'ils faut déclarer ça, ce serait interessant que qqn poste ici un exemple de ce fichier pour le bewan)
Sinon j'ai bien essayé le script unicorn-pppoatm où les vpi.vci sont passés en paramètres à pppd mais ça ne marche pas non plus.
Merci pour votre aide !

 
Sur le site da-silva, il y a son fichier /etc/ppp/option (c vrai que ses liens non soulignés ne sont pas top visibles). La valeur 8.35 est sur la derniere ligne en parametre du plugin pppoatm.
 
Par contre chez moi meme avec ce parametre je vois passer des erreur dans la log a propos de mauvaises valeur du vpi.vci mais ca connecte toujours apres.
 
De plus j'ai un autre probleme (pas insurmontable mais bizar qd meme) : le module pppoatm du noyau ne se charge pas automatiquement. Quand j'essaye de le charger manuellement j'ai des erreurs de dependances. Si j'essaie d'abord de lancer pppd (qui echouera) j'arrive ensuite a charger le module puis a relancer pppd qui me connecte bien. Ensuite tout roule.

[edtdd]--Message édité par JeromeV--[/edtdd]

Yahooooooooo !!!
 
Je poste ce message depuis ma Mandrake 8.1 via mon Bewan ADSL PCI ST, ce qui prouve que tout marche impec
Bon quelques remarques quand même : j'ai suivi à la lettre la page de Faust (http://www.da-silva.nom.fr/adsl/linux/pppoatm/) sous Mandrake 8.1 (full install, mais je réessaierai ce week-end sur une linux-box avec le moins d'espace disque possible utilisé). Sur la page de Faust donc, il n'y a qu'une seule minuscule faute de frappe qui ne devrait pas trop gêner (/bin/rpm -evppp -> il manque un espace avant ppp). Si on suit sa doc à la lettre l'installation ne pose pas de problème particulier.
 
J'ajouterai qu'il ne faut pas utiliser le script unicorn-pppoatm du répertoire unicorn/script car le lancement de pppd n'a pas les bons paramètres.
 
Et de même que toi Jerome V, j'ai une erreur vpi.vci dans mes logs de connexion quand tout se passe bien :

 
 
Par contre que veux-tu dire par "le module pppoatm du noyau ne se charge pas automatiquement" ? (c'est quelle commande pour faire ça ? -> j'aimerais bien savoir si j'ai le même problème)

[citation]....
Par contre que veux-tu dire par "le module pppoatm du noyau ne se charge pas automatiquement" ? (c'est quelle commande pour faire ça ? -> j'aimerais bien savoir si j'ai le même problème)  
[/citation]
Je suis obligé de faire insmod /lib/modules/2.4.9-13/kernel/net/atm/pppoatm.o (apres une tentative echouee de pppd) sinon ca ne passe pas automatiquement.

ah ben là non, moi j'ai pas besoin de faire ca : c'est automatique. Je ne sais pas si c'est lié (je ne pense pas), mais à l'installation de ma mandrake j'ai spécifié avoir un modem adsl alcatel usb (qui marche en pppoatm aussi) -> je me suis dit que ca ne pouvais pas faire de mal. Mais bon comme mon noyau actuel n'est plus le même je pense que ce n'est pas lié.

Autre probleme : je ne suis pas sûr à 100% que cela soit lié mais je prend régulierement des kernel panic et j'ai l'impression que celà se produit quand le drivers est chargé et que le modem n'est pas synchro (ligne téléphone débranchée).

 
Je n'ai pas encore essayé de me connecter sans avoir la syncro, pour l'instant je teste les perfs sur la durée. Et c'est plutôt pas mal : la connexion a tenue 24h puis s'est coupée (normal) et est repartie grâce à  l'option "persist" de /etc/ppp/options. Là je refais des tests avec la version 0.1.0 des drivers. Apparemment c'est pareil niveaux perfs. Je remarque que j'ai pas mal de loss (5 à 10 % sur une cinquantaine de pings) mais je ne sais pas si c'est sû aux pilotes.
J'ajoute encore une précision : pour pouvoir utiliser le script unicorn/scripts/unicorn-pppoatm, j'ai dû le modifier : d'une part en remplacant le sleep 10 par un sleep 15 (délai necessaire chez moi pour avoir le SHOWTIME_L0 = modem prêt), et d'autre part en remplacant l'appel à pppd par :
 $PPPD user $USER  
en ayant pris soin de déclarer $USER (nom d'utilisateur) en début de script (les déclarations de $VPI, $VCI, et $PLUGIN ne sont pas nécessaire puisque pas utilisées (ces paramètres sont dans /etc/ppp/options).
 
Voilà une fois ces modifs effectuées, c'est vraiment trop bien ce script, à utiliser bien sûr avec les paramètres stop, start, ou restart.
 
J'aurais juste 2 questions qui s'adressent à n'importe quel linuxien (pas seulement les bewanophiles) :

• comment faire pour que ce script soit appellé avec le paramètre start au démarrage de la machine, et avec le paramètre stop à l'arrêt ? je sais que ca se passe du côté de rc.d mais je n'en sais pas plus
• comment faire pour executer la commande unicorn-pppoatm restart tous les jours à 4h du mat ? là ca doit être avec cron ou at, mais idem j'en sais pas plus ?

Merci

1> place le script dans /etc/rc.d/init.d
Ensuite utilise chkconfig pour creer les liens de démarrage dans  
/etc/rc.d/rc*.d ou bien créé les à la main :
ln -s /etc/rc.d/init.d/unicorn_pppoatm /etc/rc.d/rc3.d/S99pppoatm
ln -s /etc/rc.d/init.d/unicorn_pppoatm /etc/rc.d/rc3.d/K99pppoatm
 
2> crontab -e (lance vi sur un fichier temporaire)
ajoute la ligne
00 04 * * * service unicorn-pppoatm restart
esc : wq pour quitter en sauvant (vi quoi).

[edtdd]--Message édité par JeromeV--[/edtdd]

 
OK, ca marche, merci . J'ai juste dû rajouter une entête (que j'ai repompé sur le service internet) à mon script pour qu'il soit reconnu en tant que service :
 
#
# unicorn-pppoatm       Bring up/down ADSL internet connection
#
# chkconfig: 2345 11 89
# description: Activates/Deactivates the Bewan ADSL PCI ST interfaces
#  
 
mais j'avoue ne pas comprendre le 2345 11 89
2345 = runlevels où le pilote doit être activé ?
11 = ?
89 = ?
 

 
Là par contre j'ai un problème :
j'ai fait plusieurs essais (en changeant l'heure à chaque fois bien sur ), et dans mon fichier /var/log/messages j'ai bien la ligne suivante :
 Jan  5 16:41:00 F crond[1506]: (root) RELOAD (cron/root)  
Jan  5 16:41:00 F CROND[2321]: (root) CMD (service unicorn-pppoatm restart)  
Mais par contre la connexion ne bouge pas. Pourtant la commande  service unicorn-pppoatm restart lancée manuellement marche très bien et relance bien la connexion.

Essaye de replacer la commande service ... par
/etc/rc.d/init.d/unicorn-pppoatm restart
dans ton fichier cron.

[edtdd]--Message édité par JeromeV--[/edtdd]

Ca marche merci

bon alosr chez moi ca connecte tout bien, la connexion à l'air de tenir mais la machine plante systématiquement au delà de moins de 20 heures d'uptime.
 
Comme je l'ai expliqué dans cet autre post :  
[link]http://forum.hardware.fr/forum2.php3?post=5883&cat=11&config=&interface=0&cache=cache&p=1&sondage=&owntopic=[/link]
je soupconne le probleme de memoire mais j'ai tout de meme un doute : cela pourrait il etre lié au drivers unicorn ?
Quelqu'un a reussi a tenir une connexion disons au moins 24h ?

[edtdd]--Message édité par JeromeV--[/edtdd]

Arf, ca m'inquiètes ce que tu me dis là, parce que j'ai retrouvé mon pc planté en rentrant ce soir. Je n'ai essayé qu'une fois et il est très possible que ce soit la surchauffe qui ait fait planter la machine (j'avais un peu abusé sur l'étanchéité de l'uc pour réduire le bruit), donc je réessaye ce soir.
Réponse demain soir. Si ca replante c'est que le driver est buggé.
 
Autre chose, là je suis passé en 0.1.0, mais de mémoire j'avais tenu plus de 24h avec le pilote 0.0.8 lors de mes essais du week-end dernier.

J'ai quelques messages d'erreur à la c*n dans /var/log/messages a cause des drivers (je suis néanmoins connecté):
 
an  6 20:33:58 levant kernel: unicorn_atmdrv.c : aal5_decode: readjusting illegal skb->len 144 -> 96
Jan  6 20:34:16 levant kernel: unicorn_atmdrv.c : aal5_decode: readjusting illegal skb->len 144 -> 96
Jan  6 20:34:51 levant kernel: 193.251.123.34 sent an invalid ICMP error to a broadcast.
Jan  6 20:45:44 levant kernel: Pilot tracking error !  
Jan  6 20:45:44 levant kernel:  
Jan  6 20:45:49 levant kernel: Pilot tracking error !  
Jan  6 20:45:49 levant kernel:  
Jan  6 20:45:54 levant kernel: Pilot tracking error !  
Jan  6 20:45:54 levant kernel:  
Jan  6 20:45:59 levant kernel: Pilot tracking error !  
Jan  6 20:45:59 levant kernel:  
Jan  6 20:46:04 levant kernel: Pilot tracking error !  
Jan  6 20:46:04 levant kernel:  
Jan  6 20:46:09 levant kernel: Pilot tracking error !  
Jan  6 20:46:09 levant kernel:  
Jan  6 20:46:14 levant kernel: Pilot tracking error !  
Jan  6 20:46:14 levant kernel:  
Jan  6 20:46:19 levant kernel: Pilot tracking error !  
Jan  6 20:46:19 levant kernel:  
Jan  6 20:46:24 levant kernel: Pilot tracking error !  
Jan  6 20:46:24 levant kernel:  
Jan  6 20:46:29 levant kernel: Pilot tracking error !  
...
 
Quand ça commence, ça ne s'arrête plus...
 
(details de l'install là : http://arsunik.free.fr/bewan )
Est-ce que qq'un a les memes ?
Bewan ne m'a tjrs pas repondu a ce sujet...

[edtdd]--Message édité par ArSuniK--[/edtdd]

> Jan  6 20:46:14 levant kernel: Pilot tracking error !  
 
Exactement le même problème chez moi avec les pilotes 0.0.8. En passant aux 0.1.0 ca ne me le fait plus (par contre j'ai toujours le message wrong vpi.vci 15.16).

Bon, ben deuxième soir de suite ou je rentre pour retrouver ma machine lamentablement plantée, donc ca ne fait aucun doute : les pilotes 0.1.0 sont buggés (le matériel n'est pas en cause c certain). Je vais essayer avec les 0.0.8 mais j'y crois pas trop, et j'envoie dès maintenant un mail au mec qui développe les drivers chez Bewan pour lui notifier le problème et récupérer au passage la dernière version du pilote.

Je possède également ce modem et c'est un peu la merde ...
 
Les drivers 0.1.0 font définitivement planter la machine.
 
J'ai eu aussi des problèmes pour compiler unicorn_pci, il manquait en effet la référence vers assert_fail : j'ai donc linker avec la libc et j'ai modifié linrapi.c (j'ai passé stderr et ernno en extern).

Tiens nous au courant ... pour le moment la seul solution que j'ai trouvée c'est un reboot automatique toutes les 8heures ... quelle misère d'être obligé d'en arriver là sous linux (((

Il reste une voie que nous n'avons pas explorée : la connexion Bridged avec pppoe :
 
>Bridged (RFC2684) and PPP over Ethernet:
>Depending on your kernel, you may need to patch the kernel and enable the option
"RFC1483/2684 Bridged protcols" under "Networking options". Also ATM support needs
to be enabled.
>Also the user space daemon "brctl" is needed. Instructions on how to apply the
patch and the brctl and patch sources can be found at http://www.zoftware.org/adsl-pppoe.
 
Si qqun se sent le courage ...

g aussi retrouvé mon linux planté hier soir...
c'est vraiment de la merde ce driver.
enfin de la part d'un driver ki se link avec la libm, on ne pouvait que s'attendre a avoir des pb.
 
la soluc avec pppoe offre parait-il des performances moindres et j'ai pas trop envie d'en arriver là.
 
et bewan ne m'a tjrs pas repondu.
J'aurais mieux fait de garder mon modem usb eci.
Maintenant il parait qu'il marche sous linux

[edtdd]--Message édité par ArSuniK--[/edtdd]

a mon avis les performances moindres, ce doit etre un poil de conso cpu en plus, rien de bien grave si cela résoud les plantages journaliers !!
du pppoe par dessus de l'atm c'est ce que font tous les autres modem ... donc au pir on perd le gain (negligeable) du pci sur l'ethernet.

[edtdd]--Message édité par JeromeV--[/edtdd]

Message et reponse du developpeur du driver (je l'avais prevenu dans un mail precedant que mon anglais etait deplorable).
 
> Hello
>  
> I've got big problem with these drivers.
> They make the system hang after 15 to 20 operating hours.
> I used the method indicated here to configure the system
> http://www.da-silva.nom.fr/adsl/linux/pppoatm/
> It seems I am not only one to encounter this problem.
>  
> Is there a new release for the drivers ?
> How can I help you ?
I have tried to reproduce the probleme without any success so far. What I
suspect is that the driver allocates memory without releasing it in some
cases.
What I would like to have is the message printed on syslog just before the
driver is unloaded after running some hours. The message is
"tot_mem=xxx,max_mem=yyy"
The first number is the memory allocated and the 2nd is the max amount of
memory allocated.

OK, je voudrais bien regarder chez moi, mais comment faire pour afficher le syslog ? (et peut-on le consulter après un reboot de la machine ?)
J'ai pensé à un truc aussi : si le problème vient d'une mauvaise gestion de la mémoire, il est très possible que le problème intervienne plus tôt sur une machine qui n'a pas beaucoup de mémoire. Or moi (et toi aussi il me semble) je n'ai que 32 MO sur cette machine qui me sert juste de linux box. Alors que sur la machine de développement du développeur des drivers y'en a sans doute plus. Ca expliquerait peut-être pourquoi il n'a pas rencontré ce problème.

Non, les pilotes 0.0.8 ne resolvent pas le problème chez moi. Je veux bien essayer avec les 0.0.6 mais là honnêtement j'y crois plus du tout.

Bon, je crois avoir compris que le syslog etait le fichier /var/log/syslog, mais par contre je n'ai pas du tout de ligne qui ressemble à ca dedans : "tot_mem=xxx,max_mem=yyy"
J'ai pensé qu'il fallait sans doute activer le mode debug, donc j'ai relancé le pilote du modem avec les paramètres MswDebugLevel=1 et DebugLevel=9 mais toujours rien (enfin si, des centaines de ligne par minute dans mon syslog, mais dixit grep, pas de tot_mem ou de max_mem. Je ne sais pas quoi faire pour aider le développeur.

Pareil, je ne sais pas ou capturer ces valeurs ...

Bon idem avec les 0.0.6, ca fait planter le système au bout d'une dizaine d'heures. J'essaye ce soir avec les 0.0.5 histoire d'avoir fait le tour de la question, mais j'y crois pas.

Recu dans mon mail ce matin :  
 

Frode Isaksen m'a envoyé les nouveaux drivers.
Je les ai placés ici :  
 
http://ummagumma.org/unicorn-0.1.1.tar.gz
 
Je ne les ai pas encore essayés.

 
mais vous allez devoir attendre que je le fasse : ma machine semble plantée une fois de plus, malgrès un  
 
killall pppd
modprobe -r unicorn_pci
modprone unicorn_pci ActivtionMode=1
pppd user ...
 
toutes les 3 heures.

[edtdd]--Message édité par JeromeV--[/edtdd]

 
Ouin !!!
 
faut faire un site bewan ADSL PCI st avec un HOWTO et les derniers drivers.

Arghhh, vert...
C'est clair que du côté de Bewan ca assure pas du tout, ils pourraient faire un ftp pour mettre les différents drivers...
Bon j'espère que ton problème sera résolu sous peu

Je viens de récupérer les 0.1.1, merci bcp JeromeV  
Je viens de relancer ma connexion, premier bilan demain matin, si la connexion est toujours debout (cette fois j'y crois) !!!

heu
 
y'en a ic iqui run avec le 2.4.17 ?
 
j'arrive pas a faire tourner pppd avec patch pppoatm

Nokbilong > nope chez moi, le seul moyen de faire marcher ce modem a été de suivre la doc de Faust, donc noyau 2.8.4.
 
Bon, j'ai donc laissé tourner les 0.1.1 toute la nuit, et ce matin mon pc n'est toujours pas planté. Par contre en voulant relancer la connexion ce matin (crontab), problème :

J'ai ressayé manuellement, mais j'ai eu le même problème. La seule solution pour pouvoir relancer ma connexion a été de rebooter. Ce problème a t-il lieu aussi chez vous ?

Nokbilong > oui, moi, avec une slack 7 mais ça a été difficile.
http://arsunik.free.fr/bewan
c koi l'erreur que tu as ?
 
Bon c cool, le 0.1.1 est autant buggué que le reste donc...
J'ai envoyé un mail à bewan pour leur dire ce que je pensais de leur support de linux (aucune doc, des truc en beta ki marchent mal) et de leur driver qui est vraiment super mal programmé :
 
> Il est linké avec la libm.
> Outre le fait que ce n'est pas très propre et que ça donne un noyau
> énorme, la libm n'est pas conçue pour tourner en mode noyau.
> Elle utilise notamment le FPU, ce qui est déconseillé
> dans le noyau.
> Il utilise du c++. Le C++ n'est pas sensé être utilisé dans le noyau
> (pas de support/runtime C++ dans le noyau).
> Il lance 4 threads [UNICORN-SAIF] [UNICORN-INTR] [UNICORN-SM00]
> [UNICORN-AMU0] qui tournent en mode noyau, ce qui est encore une fois
> très propre.
> Une partie du driver est un module compilé avec un compilateur C++ !
> Impossible de débugguer donc.
 
J'ai peur qu'il ne se passe beaucoup de temps avant que l'on puisse avoir un truc stable

[edtdd]--Message édité par ArSuniK--[/edtdd]

j'ai plein d'erreur de code sur dans les soruces du pppd patched, apparemment surtout dans chat.c, docn je peux pas compiler, vé essayer ton url ce soir thx

Envoi plutot un rapport de bug à Frode Isaksen <fisaksen@bewan.com> qui developpe le driver. Cela sera plus util pour faire avancer les choses.

En fait g envoyé 2 mails :
1 pour leur dire que c'était pas bien de dire que ça marche sous linux alors que ça n'est pas vraiment au point
1 autre avec des details ki commencait par "pouvez-vous transmettre ça au developpeur du driver). Maitenant que j'ai son email ya plus de pb .
Ce qui ferait surtout avancer les choses, c'est d'avoir toutes les sources du driver (et pas un truc .o). Kom ça yaurait ptet moyen de virer la libm, tt les modules ki servent pas et de convertir tout en c . Au vu des précédentes version, je n'ai pas trop l'impression que Frode ai l'intention de trop modifier son code.

A mon avis le module compilé est celui du chip ST qui est indépendant de bewan ...

 
Arg, ça serait pas cool ça...