Reprise du message précédent :

Non, ton ip fixe sera attribuée à ppp0 comme d'habitude.
 

rp-pppoe est un client pppoe pour se connecter avec ce protocole. Dans ce client, le script de lancement est adsl-start.
rp-pppoe est fourni avec certaine distributions mais tu peux eventuellement en choisir un autre (je n'en connais pas d'autre à part celui qui etait fournis sur les CD netissimo et qui ne marchait pas tres bien)
 

Non, une interface ppp0 va bien etre crée a la connexion .

Super la reactivite, merci !!!
Juste une derniere question, pour attribuer mon adresse IP a pppo, il faut bien faire 'ifconfig pppo mon_ip' ? L'adresse IP devra-telle etre reconfigurer a chaque demarrage ou bien on peut l'attribuer a pppo une bonne fois pour toute ?

 
L'IP de ppp0 est attribuée automatiquement à la connexion par ton FAI, que tu ais une IP fixe ou non.

???? Et comment il sait ou aller chercher l'IP ?? Il faut bien a un moment donner l'adresse des serveurs DNS non ?
 
Je comprends pas comment ca marche ?? Avec le cable oui vu que le modem te dirige directement chez Noos, mais la je vois pas comment il sait ou aller chercher l'IP ? Avec le numero de telephone ?

 
Ton identifiant adsl se compose ainsi : login@fai
par exemple un identifiant nerim ressemble à login@net1.nerim.nerim
Quand tu te connectes, le modem adsl en face du tiens reconnais la seconde partie de ton identifiant et te redirige vers le serveur d'identification de ton FAI qui lui t'attribue une IP.
 
Techniquement ce n'est peut etre pas rigouresement ca, mais en gros c ca.

Ok super v(moi aussi j'ai choisie Nerim );
Une derniere question et puis j'arrete. J'ai vu sur ce topic que parfois le modeactivation peut-etre 1 ou 4, je suppose que dans le cas ou on a loader une premiere fois le module qui va bien avec Activationmode=1 et que ca ne marche pas, il faut unloader (je ne sais pas si on dit exactement comme ca) le module pour le reloader a nouveau avec Activationmode=4. Comment-fait-on pour unloader un module, j'ai pas trouve la commande ?

Gaellick a écrit a écrit : Ok super v(moi aussi j'ai choisie Nerim ); Une derniere question et puis j'arrete. J'ai vu sur ce topic que parfois le modeactivation peut-etre 1 ou 4, je suppose que dans le cas ou on a loader une premiere fois le module qui va bien avec Activationmode=1 et que ca ne marche pas, il faut unloader (je ne sais pas si on dit exactement comme ca) le module pour le reloader a nouveau avec Activationmode=4. Comment-fait-on pour unloader un module, j'ai pas trouve la commande ?

 
modprobe unicorn_pci ActivationMode=1 (ou 4) pour le charger
modprobe -r unicorn_pci pour le decharger

Super, je te remercie enormement pour ton aide. Je vous dirais si j'ai reussi a tout faire marcher. Je telecharge rp-pppoe-3.3.7 et linux-atm en ce moment et let's go on essaie tout ca !
 
Merci encore.

Bon j'ai un probleme, les drivers Bewan ne veulent pas se compiler, ca plante. Si j'ai bien compris le README, je vais dans chacun des repertoire 'unicorn_atm' et 'unicorn_bus', je modifie le Makefile pour mettre le chemin vers les sources dans la variable KERNELPATH (/usr/src/linux-2.4.18-5 pour une Redhat 7.3).
 
 
Ben ca marche pas j'ai des messages d'erreur du style :
 
KERN_DEBUG undeclared (first use in this fonction)
ADSL_STATU_NOLINK undeclared (first use in this fonction)
 
et plein d'autres encore, y'en a 3 pages
Qu'est-ce qui se passe ?

Siouplait ! J'ai reussi a compiler ce qu'il y'a dans unicorn_bus, mais je n'arrive pas dans unicorn_atm.

 
a priori ton modem est synchro
regarde ce qui passe dans les log quand tu lance adsl-start

 
Du calme, ya pas le feu ...
 
Verifie qu'il n'y a qu'un seul script adsl-start et un seul edsl-setup sur ta machine : il me semble que j'avais eu un conflit a ce niveau entre le rp-pppoe preinstallé par redhat et celui que j'avais installé apres : le script adsl-setup ne generait pas le bon fichier de config.
Et sans fichier de config (pppoe.conf) adsl-start ne peux effectivement pas demarer.
 
Sinon voici un fichier pppoe.conf ou tu n'as que ton log a changer.
 
ETH='nas0'
USER='tonlogin@tonprovider'
DEMAND=no
DNSTYPE=SERVER
PEERDNS=yes
DNS1=
DNS2=
DEFAULTROUTE=yes
CONNECT_TIMEOUT=30
CONNECT_POLL=2
ACNAME=
SERVICENAME=
PING="."
CF_BASE=`basename $CONFIG`
PIDFILE="/var/run/$CF_BASE-adsl.pid"
SYNCHRONOUS=no
CLAMPMSS=1412
LCP_INTERVAL=20
LCP_FAILURE=3
PPPOE_TIMEOUT=80
FIREWALL=NONE
LINUX_PLUGIN=
PPPOE_EXTRA=""
PPPD_EXTRA=""

2 machines différentes, 2 comportements différents de unicorn_pci
 
Bonjour,
 
Je suis utilisateur de BEWAN ST depuis une semaine avec un 2.4.18 + unicorn 0.3.4.
Si les premiers essais se sont correctement déroulés je rencontre pas
mal de soucis avec un COMPAQ Evo (Celeron Coppermine 1.1GHz).
En effet, ce n'est pas systématique, mais lors d'une rénégociation (jamais lors
de la première connexion) de connexion suite à coupure (que l'on peut simuler en
débranchant) la machine se gèle.
Cela se produit sur ce COMPAQ et jamais sur un PC Assemblé (Celeron 700Mhz).
 
Le protocole de test est le même pour les 2 machines : même carte, même cordon téléphonique, même emplacement physique. Le noyau et les modules unicorn ont été compilés en 586 et en 686, même comportement.
La carte Bewan a été déplacée dans les slots : même résultat.
Même si il semble que le gel survient moins souvent lorsque la carte est proche du centre de la carte-mère cela n'a pas pu être démontré avec certitude.
 
Le résultat est que je suis bien e.....é. En effet, j'ai cette configuration chez un client et ... la machine doit être relancé (reset) tous les matins car elle s'est figée la veille au soir.
 
Encore une chose :
 le phénomène se produit seul au bout d'un certain nombre de reconnexion (pas forcément la première).
 Je peux forcer le gel de la manière suivante et sur les 2 machines cette fois !
 En lançant unicorntest lorsque la liaison ATM n'est pas établie : gel systématique au bout de quelques secondes si unicorn_pci est chargé et que donc la machine est en cours de négociation ! En revanche unicorntest lorsque la liaison ATM est établie ou lorsque unicorn_pci n'est pas chargé : pas de problème.
 
Conclusion :
Se pourrait-il qu'il y ait un phénopmène de "race condition" dans unicorn_pci dont l'apparition serait plus probable sur une machine plus rapide ?
 
Merci de vos réponses,
 
db

 
Il y avait un probleme de gel du PC avec une vieille version du driver. Pour le moment je tourne toujours avec le 0.3.3 mais il me semble que le 0.3.4 est plus une evolution d'une vieille version qu'une suite du 0.3.3.
 
Ton probleme vient donc probablement des drivers utilisés.
 
Je te conseille de tester avec les drivers 0.3.3 et de contacter le developpeur des drivers ( son mail est indiqué quelque part dans les sources des drivers, sinon il me semble qu'on l'a donné dans ce topic) pour lui indiquer ton probleme.

 
Il ne fallait pas laisser kudzu configurer la carte bewan comme une carte reseau.
Je te conseille de virer toute config qu'il a pu creer : alias dans /etc/modules.conf, script dans /etc/sysconfig/network-scripts ...
Sinon tes dns sont ils correctement configurés ?

 
A la connexion tu recupere les dns de ton FAI (DNSTYPE=SERVER PEERDNS=yes dans pppoe.conf). Ca genere un fichier resolf.conf dans /etc/ppp. Il suffit de faire un lien symbolique sur ce fichier dans /etc/resolv.conf

Merci,
j'ai réussi à trouver le 0.3.3. Je vais donc procéder à des tests.
 
En attendant je précise la chose suivante :
 sur la machine COMPAQ (la rapide à 1,1Ghz) la négociation
 est longue, longue (si ça ne gèle pas avant) :  
  alternance de SHOWTIME_L0  
  puis "Bringing down ... persistent faults
  ... NEAR_LCDI=5 ...
  FAR_LOS=5" (le reste à 0)
 
 alors que sur la machine assemblée (Célérom 700Mhz) elle quasi immédiate  
 et ce, systématiquement.
 
db

 
Merci,
j'ai réussi à trouver le 0.3.3. Je vais donc procéder à des tests.
 
En attendant je précise la chose suivante :
 sur la machine COMPAQ (la rapide à 1,1Ghz) la négociation
 est longue, longue (si ça ne gèle pas avant) :  
  alternance de SHOWTIME_L0  
  puis "Bringing down ... persistent faults
  ... NEAR_LCDI=5 ...
  FAR_LOS=5" (le reste à 0)
 
 alors que sur la machine assemblée (Célérom 700Mhz) elle quasi immédiate  
 et ce, systématiquement.
 
db

 
Tu as quoi dans /etc/sysconfig/network ?

J'ai ca
Il faut que je te dise que j'ai une carte reseau avec l'adresse IP 192.168.0.1 pour le reseau local
 
NETWORKING=yes
HOSTNAME='server'
GATEWAY=192.168.0.254

 
vire la ligne gateway
il cherche le net par cette machine

Ok je fais ca.

Faut que je reboot ou pas parceque ca marche toujours pas meme apres avoir vire la ligne, et le truc bridged quand je fais cat /proc/net/atm/UNICORN:0 c'est pas genant ??  

 
Je ne sais pas si le bridge est succeptible de gener, sinin il faut au moins relancer le service reseau ...
 
Dans le doute, reboot

Ok je reessaie apres avoir rebooter, comment on fait pour virer le bridge ?

 
Je viens de voir que  /proc/net/atm/UNICORN\:0 m'indique aussi bridged, cela ne pose donc pas de probleme avec une connexion en pppoa.

C'est pas un probleme avec le mode d'activation, j'ai essaye que le 1.

T'es plus en mode bridge ?

 
Non je suis en pppoa.
Alors ca donne quoi apres reboot ?

Ca marche toujours pas

Je comprends pas tout est bien j'ai les bons messages partout et les nav trouvent ri"en fais chier

Gaellick a écrit a écrit : Ca marche toujours pas

 
La connexion par une ip ca marche ou pas ?
Le ping sur une ip marche ?

 
Par exemple pour aller sur hardware.fr tu indique dans ton browser http://212.43.221.155.
Si ca ca marche le probleme vient des dns. Sinon ... ?

Gaellick a écrit a écrit : Le ping marche pas , c'est pas un probleme de droits ? pppd etant dans /usr/sbin, je le lance en root et mon navigateur avec mon user normal ca peut pas venir de ca ?

 
Non ce n'est pas ca. Peut etre un probleme de route mais là je n'y connais pas grand chose.
Que te donne la commande route ?

 
juste route

Bon, j'ai pas de carte ADSL (juste une Numéris) mais j'ai eu aussi un pb de route en essayant de la configurer, j'avais plusieurs route par défaut qui n'était pas bien définies.
j'ai réglé ce pb en éliminant les routes par défaut (qui je crois, seront remplacé par ton interface internet quand tu la démarres) :
 
route del default

 
comme je sais pas si j'ai bien expliqué, je te files le lien où j'avais trouvé l'info (c'est dans la deuxième moitié):
http://www.bouissou.net/isdn/Linux_Olitec_ISDN.html

 
et si tu fais >route add default ppp0  
?

 
j'ai presque pareil ... ca ne marche toujours pas ?
balance le resultat d'un ifconfig

Gaellick a écrit a écrit : Voila mon ifconfig     eth0      Lien encap:Ethernet  HWaddr 00:02:E3:02:B9:94           inet adr:192.168.0.1  Bcast:192.168.0.255  Masque:255.255.255.0           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:274 errors:0 dropped:0 overruns:0 frame:0           TX packets:396 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 lg file transmission:100           RX bytes:34356 (33.5 Kb)  TX bytes:79521 (77.6 Kb)           Interruption:10 Adresse de base:0xd000   lo        Lien encap:Boucle locale           inet adr:127.0.0.1  Masque:255.0.0.0           UP LOOPBACK RUNNING  MTU:16436  Metric:1           RX packets:538 errors:0 dropped:0 overruns:0 frame:0           TX packets:538 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 lg file transmission:0           RX bytes:41808 (40.8 Kb)  TX bytes:41808 (40.8 Kb)   ppp0      Lien encap:Protocole Point-à-Point           inet adr:XXXX.XXX.XXX.XXX  P-t-P:62.4.16.251  Masque:255.255.255.255           UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1           RX packets:3 errors:0 dropped:0 overruns:0 frame:0           TX packets:3 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 lg file transmission:3           RX bytes:30 (30.0 b)  TX bytes:30 (30.0 b)     L'adresse IP est bonne, elle correspond bien a l'IP fixe que ma donne Nerim (je la cache juste comme ca )

 
 
Bah je comprend pas pkoi ca marche pas ... t'as pas un firewall qui bloque tout ou qqchose comme ca ?
 
Essaye traceroute 62.4.16.81

 
C'est donc bien un probleme de dns ...
Es tu sûr de ton fichier /etc/resolv.conf ?