Bonjour, je me suis empressé de clore un post précédent sur l'installation
d'un modem Bewan pci st sous Mandrake officielle 10.
Effectivement la bête tourne, et j'ai réussi l'espace d'un instant à avoir
accès au web.. sans depuis avoir reproduit la chose ;-[
J'obtient une connexion, je peux pinger www.free.fr ou yahoo, j'ouvre (ds
Konqueror ou Mozilla) du ftp, mais point de http... ni de smtp.
Après avoir vérifié et revérifié les différents fichiers de conf. Je ne
trouve pas.
Au passage :
Mdk 10 kernel 2.6.4-7
IPV 6 désactivé ("alias net-pf-10 off" ds /etc/modprobe.conf)
voici un route > route.txt
________________________
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use
Iface
192.168.254.254 * 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 192.168.254.254 0.0.0.0 UG 0 0 0 ppp0
-----------------------------------------
ifconfig :
eth0 Lien encap:Ethernet HWaddr 00:00:00:00:00:00
inet adr:192.168.0.1 Bcast:192.168.0.255 Masque:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:74 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:0 (0.0 b) TX bytes:11018 (10.7 Kb)
Interruption:11 Adresse de base:0xdc00
PING www.free.fr (213.228.0.42) 56(84) bytes of data.
64 bytes from www1.free.fr (213.228.0.42): icmp_seq=1 ttl=61 time=69.6 ms
64 bytes from www1.free.fr (213.228.0.42): icmp_seq=2 ttl=61 time=68.9 ms
64 bytes from www1.free.fr (213.228.0.42): icmp_seq=3 ttl=61 time=67.9 ms
Je ne comprend pas pourquoi je peux pinger du www, qui est bien routé avec
un nom résolu et cela ne fonctionne pas depuis un navigateur... et surtout
cela a fonctionné, mais je ne sais plus sous quelle configuration ???
Le nouveau kernel 2.6 a des particularités (modprobe.preload par ex.) que je
ne maitrise pas..
Merci.
Stef.
Je ne comprend pas pourquoi je peux pinger du www, qui est bien routé avec un nom résolu et cela ne fonctionne pas depuis un navigateur...
un navigateur, ça ne pingue pas (protocole UDP); ça se connecte sur le port 80 (par défaut) du protocole TCP. A priori, ça devrait venir du parefeu. Essayer 'shorewall clear'. Si ça résout le problème, vérifier la configuration de shorewall. Par défaut shorewall ne devrait pas bloquer les connexions sortantes sur une Mandrake, à moins d'avoir demandé une configuration de type passerelle.
Gérard Patel
On Fri, 21 May 2004 10:18:17 +0200, "Stef Dahl" <5-tux@ifrance.com>
wrote:
Je ne comprend pas pourquoi je peux pinger du www, qui est bien routé avec
un nom résolu et cela ne fonctionne pas depuis un navigateur...
un navigateur, ça ne pingue pas (protocole UDP); ça se connecte sur le
port 80 (par défaut) du protocole TCP. A priori, ça devrait venir du
parefeu. Essayer 'shorewall clear'. Si ça résout le problème,
vérifier la configuration de shorewall. Par défaut shorewall ne
devrait pas bloquer les connexions sortantes sur une Mandrake,
à moins d'avoir demandé une configuration de type passerelle.
Je ne comprend pas pourquoi je peux pinger du www, qui est bien routé avec un nom résolu et cela ne fonctionne pas depuis un navigateur...
un navigateur, ça ne pingue pas (protocole UDP); ça se connecte sur le port 80 (par défaut) du protocole TCP. A priori, ça devrait venir du parefeu. Essayer 'shorewall clear'. Si ça résout le problème, vérifier la configuration de shorewall. Par défaut shorewall ne devrait pas bloquer les connexions sortantes sur une Mandrake, à moins d'avoir demandé une configuration de type passerelle.
Gérard Patel
Stef Dahl
gerard patel wrote:
On Fri, 21 May 2004 10:18:17 +0200, "Stef Dahl" wrote:
Je ne comprend pas pourquoi je peux pinger du www, qui est bien routé avec un nom résolu et cela ne fonctionne pas depuis un navigateur...
un navigateur, ça ne pingue pas (protocole UDP); ça se connecte sur le port 80 (par défaut) du protocole TCP. A priori, ça devrait venir du parefeu. Essayer 'shorewall clear'. Si ça résout le problème, vérifier la configuration de shorewall. Par défaut shorewall ne devrait pas bloquer les connexions sortantes sur une Mandrake, à moins d'avoir demandé une configuration de type passerelle.
Gérard Patel
Merci, c'est toujours bon de rappeler les bases ;)) Je suis dans la classe des "bricoleurs (qui se couchent tard)", pas dans celle des administrateurs.. La piste de shorewall n'est pas la bonne (à priori), je vais reprendre les options de ppp à tout hasard (puisque cela a fonctionné). J'ai même supprimé eth0, reinstallé avec DHCP, au cas ou il y aurait une "interdépendance" ds les outils réseaux de la MDK... J'ai retesté en configurant avec webmin.. Toujours rien :-{{ Stef.
gerard patel wrote:
On Fri, 21 May 2004 10:18:17 +0200, "Stef Dahl" <5-tux@ifrance.com>
wrote:
Je ne comprend pas pourquoi je peux pinger du www, qui est bien
routé avec un nom résolu et cela ne fonctionne pas depuis un
navigateur...
un navigateur, ça ne pingue pas (protocole UDP); ça se connecte sur le
port 80 (par défaut) du protocole TCP. A priori, ça devrait venir du
parefeu. Essayer 'shorewall clear'. Si ça résout le problème,
vérifier la configuration de shorewall. Par défaut shorewall ne
devrait pas bloquer les connexions sortantes sur une Mandrake,
à moins d'avoir demandé une configuration de type passerelle.
Gérard Patel
Merci, c'est toujours bon de rappeler les bases ;))
Je suis dans la classe des "bricoleurs (qui se couchent tard)", pas dans
celle des administrateurs..
La piste de shorewall n'est pas la bonne (à priori), je vais reprendre les
options de ppp à tout hasard (puisque cela a fonctionné). J'ai même supprimé
eth0, reinstallé avec DHCP, au cas ou il y aurait une "interdépendance" ds
les outils réseaux de la MDK... J'ai retesté en configurant avec webmin..
Toujours rien :-{{
Stef.
Je ne comprend pas pourquoi je peux pinger du www, qui est bien routé avec un nom résolu et cela ne fonctionne pas depuis un navigateur...
un navigateur, ça ne pingue pas (protocole UDP); ça se connecte sur le port 80 (par défaut) du protocole TCP. A priori, ça devrait venir du parefeu. Essayer 'shorewall clear'. Si ça résout le problème, vérifier la configuration de shorewall. Par défaut shorewall ne devrait pas bloquer les connexions sortantes sur une Mandrake, à moins d'avoir demandé une configuration de type passerelle.
Gérard Patel
Merci, c'est toujours bon de rappeler les bases ;)) Je suis dans la classe des "bricoleurs (qui se couchent tard)", pas dans celle des administrateurs.. La piste de shorewall n'est pas la bonne (à priori), je vais reprendre les options de ppp à tout hasard (puisque cela a fonctionné). J'ai même supprimé eth0, reinstallé avec DHCP, au cas ou il y aurait une "interdépendance" ds les outils réseaux de la MDK... J'ai retesté en configurant avec webmin.. Toujours rien :-{{ Stef.
TiChou
Dans le message <news:c8koha$5al$, *Stef Dahl* tapota sur f.c.o.l.configuration :
--- www.free.fr ping statistics --- 7 packets transmitted, 7 received, 0% packet loss, time 6004ms rtt min/avg/max/mdev = 64.986/67.224/69.663/1.593 ms
Je ne comprend pas pourquoi je peux pinger du www, qui est bien routé avec un nom résolu et cela ne fonctionne pas depuis un navigateur...
un navigateur, ça ne pingue pas (protocole UDP); ^^^
Petite rectification, le protocole utiliser pour le ping est l'icmp et non pas l'udp, erreur certainement involontaire de Gerard PATEL.
ça se connecte sur le port 80 (par défaut) du protocole TCP. A priori, ça devrait venir du parefeu. Essayer 'shorewall clear'. Si ça résout le problème, vérifier la configuration de shorewall. Par défaut shorewall ne devrait pas bloquer les connexions sortantes sur une Mandrake, à moins d'avoir demandé une configuration de type passerelle.
Merci, c'est toujours bon de rappeler les bases ;)) Je suis dans la classe des "bricoleurs (qui se couchent tard)", pas dans celle des administrateurs.. La piste de shorewall n'est pas la bonne (à priori), je vais reprendre les options de ppp à tout hasard (puisque cela a fonctionné). J'ai même supprimé eth0, reinstallé avec DHCP, au cas ou il y aurait une "interdépendance" ds les outils réseaux de la MDK... J'ai retesté en configurant avec webmin.. Toujours rien :-{{
Pour s'assurer qu'il n'y a pas un blocage du firewall, mis à part vérifier les règles définies qui peuvent vous paraitre incompréhensibles, vous pouvez essayer d'utiliser l'outil telnet ou netcat pour vérifier que vous vous connecter au port 80 d'un site distant ou bien utiliser l'outil nmap pour vérifier que votre machine voit le port 80 distant ouvert.
$ telnet www.free.fr 80 Trying 213.228.0.42... Connected to www.free.fr. Escape character is '^]'.
[...]
$ nmap -p 80 www.free.fr
Starting nmap 3.xx ( http://www.insecure.org/nmap/ ) Interesting ports on www1.free.fr (213.228.0.42): PORT STATE SERVICE 80/tcp open http
Ensuite, le problème peut aussi venir du MTU sur votre connexion PPP. Je n'ai pas suivis le précédent post que vous évoquiez concernant vos déboires avec la configuration de votre modem Bewan, mais ce que je remarque c'est qu'il s'agit ici d'une connexion ADSL et que dans ce cas il n'est pas forcément normal d'avoir un MTU à 1500.
-- TiChou
Dans le message <news:c8koha$5al$1@blob.linuxfr.org>,
*Stef Dahl* tapota sur f.c.o.l.configuration :
--- www.free.fr ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6004ms
rtt min/avg/max/mdev = 64.986/67.224/69.663/1.593 ms
Je ne comprend pas pourquoi je peux pinger du www, qui est bien
routé avec un nom résolu et cela ne fonctionne pas depuis un
navigateur...
un navigateur, ça ne pingue pas (protocole UDP);
^^^
Petite rectification, le protocole utiliser pour le ping est l'icmp et non
pas l'udp, erreur certainement involontaire de Gerard PATEL.
ça se connecte sur le
port 80 (par défaut) du protocole TCP. A priori, ça devrait venir du
parefeu. Essayer 'shorewall clear'. Si ça résout le problème,
vérifier la configuration de shorewall. Par défaut shorewall ne
devrait pas bloquer les connexions sortantes sur une Mandrake,
à moins d'avoir demandé une configuration de type passerelle.
Merci, c'est toujours bon de rappeler les bases ;))
Je suis dans la classe des "bricoleurs (qui se couchent tard)", pas dans
celle des administrateurs..
La piste de shorewall n'est pas la bonne (à priori), je vais reprendre les
options de ppp à tout hasard (puisque cela a fonctionné). J'ai même
supprimé eth0, reinstallé avec DHCP, au cas ou il y aurait une
"interdépendance" ds les outils réseaux de la MDK... J'ai retesté en
configurant avec webmin.. Toujours rien :-{{
Pour s'assurer qu'il n'y a pas un blocage du firewall, mis à part vérifier
les règles définies qui peuvent vous paraitre incompréhensibles, vous pouvez
essayer d'utiliser l'outil telnet ou netcat pour vérifier que vous vous
connecter au port 80 d'un site distant ou bien utiliser l'outil nmap pour
vérifier que votre machine voit le port 80 distant ouvert.
$ telnet www.free.fr 80
Trying 213.228.0.42...
Connected to www.free.fr.
Escape character is '^]'.
[...]
$ nmap -p 80 www.free.fr
Starting nmap 3.xx ( http://www.insecure.org/nmap/ )
Interesting ports on www1.free.fr (213.228.0.42):
PORT STATE SERVICE
80/tcp open http
Ensuite, le problème peut aussi venir du MTU sur votre connexion PPP. Je
n'ai pas suivis le précédent post que vous évoquiez concernant vos déboires
avec la configuration de votre modem Bewan, mais ce que je remarque c'est
qu'il s'agit ici d'une connexion ADSL et que dans ce cas il n'est pas
forcément normal d'avoir un MTU à 1500.
--- www.free.fr ping statistics --- 7 packets transmitted, 7 received, 0% packet loss, time 6004ms rtt min/avg/max/mdev = 64.986/67.224/69.663/1.593 ms
Je ne comprend pas pourquoi je peux pinger du www, qui est bien routé avec un nom résolu et cela ne fonctionne pas depuis un navigateur...
un navigateur, ça ne pingue pas (protocole UDP); ^^^
Petite rectification, le protocole utiliser pour le ping est l'icmp et non pas l'udp, erreur certainement involontaire de Gerard PATEL.
ça se connecte sur le port 80 (par défaut) du protocole TCP. A priori, ça devrait venir du parefeu. Essayer 'shorewall clear'. Si ça résout le problème, vérifier la configuration de shorewall. Par défaut shorewall ne devrait pas bloquer les connexions sortantes sur une Mandrake, à moins d'avoir demandé une configuration de type passerelle.
Merci, c'est toujours bon de rappeler les bases ;)) Je suis dans la classe des "bricoleurs (qui se couchent tard)", pas dans celle des administrateurs.. La piste de shorewall n'est pas la bonne (à priori), je vais reprendre les options de ppp à tout hasard (puisque cela a fonctionné). J'ai même supprimé eth0, reinstallé avec DHCP, au cas ou il y aurait une "interdépendance" ds les outils réseaux de la MDK... J'ai retesté en configurant avec webmin.. Toujours rien :-{{
Pour s'assurer qu'il n'y a pas un blocage du firewall, mis à part vérifier les règles définies qui peuvent vous paraitre incompréhensibles, vous pouvez essayer d'utiliser l'outil telnet ou netcat pour vérifier que vous vous connecter au port 80 d'un site distant ou bien utiliser l'outil nmap pour vérifier que votre machine voit le port 80 distant ouvert.
$ telnet www.free.fr 80 Trying 213.228.0.42... Connected to www.free.fr. Escape character is '^]'.
[...]
$ nmap -p 80 www.free.fr
Starting nmap 3.xx ( http://www.insecure.org/nmap/ ) Interesting ports on www1.free.fr (213.228.0.42): PORT STATE SERVICE 80/tcp open http
Ensuite, le problème peut aussi venir du MTU sur votre connexion PPP. Je n'ai pas suivis le précédent post que vous évoquiez concernant vos déboires avec la configuration de votre modem Bewan, mais ce que je remarque c'est qu'il s'agit ici d'une connexion ADSL et que dans ce cas il n'est pas forcément normal d'avoir un MTU à 1500.
-- TiChou
Stef Dahl
TiChou wrote:
.../...
$ nmap -p 80 www.free.fr
Starting nmap 3.xx ( http://www.insecure.org/nmap/ ) Interesting ports on www1.free.fr (213.228.0.42): PORT STATE SERVICE 80/tcp open http
Ensuite, le problème peut aussi venir du MTU sur votre connexion PPP. Je n'ai pas suivis le précédent post que vous évoquiez concernant vos déboires avec la configuration de votre modem Bewan, mais ce que je remarque c'est qu'il s'agit ici d'une connexion ADSL et que dans ce cas il n'est pas forcément normal d'avoir un MTU à 1500.
Merci, je retourne sous Mdk 10 pour retester, mais il y a une collection de pb réseau ds divers forum, avec une lenteur d'affichage des page web ou pas de connexion du tout.. donc.. pas bon. Par contre, j'ai bien vu le sous du MTU, pourtant ds mon fichier /etc/ppp/options j'ai "mtu 1200" et "mru 1200". Je ne comprend pas cette réécriture, de même il me modifie les dns ds le resolv.conf (tout en mettant de bons dns free). Je pense qu'une option ppp n'est pas bonne et recolte des infos qui perturbe cette connexion. A + tard Stef
TiChou wrote:
.../...
$ nmap -p 80 www.free.fr
Starting nmap 3.xx ( http://www.insecure.org/nmap/ )
Interesting ports on www1.free.fr (213.228.0.42):
PORT STATE SERVICE
80/tcp open http
Ensuite, le problème peut aussi venir du MTU sur votre connexion PPP.
Je n'ai pas suivis le précédent post que vous évoquiez concernant vos
déboires avec la configuration de votre modem Bewan, mais ce que je
remarque c'est qu'il s'agit ici d'une connexion ADSL et que dans ce
cas il n'est pas forcément normal d'avoir un MTU à 1500.
Merci, je retourne sous Mdk 10 pour retester, mais il y a une collection de
pb réseau ds divers forum, avec une lenteur d'affichage des page web ou pas
de connexion du tout.. donc.. pas bon.
Par contre, j'ai bien vu le sous du MTU, pourtant ds mon fichier
/etc/ppp/options j'ai
"mtu 1200" et "mru 1200". Je ne comprend pas cette réécriture, de même il me
modifie les dns ds le resolv.conf (tout en mettant de bons dns free). Je
pense qu'une option ppp n'est pas bonne et recolte des infos qui perturbe
cette connexion.
A + tard
Stef
Starting nmap 3.xx ( http://www.insecure.org/nmap/ ) Interesting ports on www1.free.fr (213.228.0.42): PORT STATE SERVICE 80/tcp open http
Ensuite, le problème peut aussi venir du MTU sur votre connexion PPP. Je n'ai pas suivis le précédent post que vous évoquiez concernant vos déboires avec la configuration de votre modem Bewan, mais ce que je remarque c'est qu'il s'agit ici d'une connexion ADSL et que dans ce cas il n'est pas forcément normal d'avoir un MTU à 1500.
Merci, je retourne sous Mdk 10 pour retester, mais il y a une collection de pb réseau ds divers forum, avec une lenteur d'affichage des page web ou pas de connexion du tout.. donc.. pas bon. Par contre, j'ai bien vu le sous du MTU, pourtant ds mon fichier /etc/ppp/options j'ai "mtu 1200" et "mru 1200". Je ne comprend pas cette réécriture, de même il me modifie les dns ds le resolv.conf (tout en mettant de bons dns free). Je pense qu'une option ppp n'est pas bonne et recolte des infos qui perturbe cette connexion. A + tard Stef
Stef Dahl
Stef Dahl wrote:
Merci, je retourne sous Mdk 10 pour retester, mais il y a une collection de pb réseau ds divers forum, avec une lenteur d'affichage des page web ou pas de connexion du tout.. donc.. pas bon. Par contre, j'ai bien vu le sous du MTU, pourtant ds mon fichier /etc/ppp/options j'ai "mtu 1200" et "mru 1200". Je ne comprend pas cette réécriture, de même il me modifie les dns ds le resolv.conf (tout en mettant de bons dns free). Je pense qu'une option ppp n'est pas bonne et recolte des infos qui perturbe cette connexion. A + tard Stef
Bon, ça y est.. testé , coupé, relancé, etc.... Le problème était apperement lié au MTU et MRU, depuis que j'ai viré le MRU du fichier /etc/ppp/options, cela fonctionne... Mais la ligne "mtu 1200" (valeur Mandrake pour Free 1024 non-dégroupé) ne sert pas à grand chose : ______________________________________
ppp0 Lien encap:Protocole Point-à-Point inet adr:82.65.40.201 P-t-P:192.168.254.254 Masque:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:9178 Metric:1 RX packets:4 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:64 (64.0 b) TX bytes:54 (54.0 b) _____________________________________
A noter également ds le fichier /sbin/unicorn-pppoatm j'ai rajouté un "$ENCAPS" ici : _____________ start() { /sbin/modprobe pppoatm [ ! "$?" = 0 ] && return $? /sbin/modprobe $UNICORN ActivationMode=$MODULATION >/dev/null 2>&1 [ ! "$?" = 0 ] && return $? sleep 10 $PPPD plugin $PLUGIN $VPI.$VCI $ENCAPS [ ! "$?" = 0 ] && return $? return 0 } __________ Bon cette fois-ci je poste depuis knode.. j'espère que cela va resisté au reboot.. pour le MTU, ma foi !! ;))
Stef
Stef Dahl wrote:
Merci, je retourne sous Mdk 10 pour retester, mais il y a une collection
de pb réseau ds divers forum, avec une lenteur d'affichage des page web ou
pas de connexion du tout.. donc.. pas bon.
Par contre, j'ai bien vu le sous du MTU, pourtant ds mon fichier
/etc/ppp/options j'ai
"mtu 1200" et "mru 1200". Je ne comprend pas cette réécriture, de même il
me modifie les dns ds le resolv.conf (tout en mettant de bons dns free).
Je pense qu'une option ppp n'est pas bonne et recolte des infos qui
perturbe cette connexion.
A + tard
Stef
Bon, ça y est.. testé , coupé, relancé, etc....
Le problème était apperement lié au MTU et MRU, depuis que j'ai viré le MRU
du fichier /etc/ppp/options, cela fonctionne...
Mais la ligne "mtu 1200" (valeur Mandrake pour Free 1024 non-dégroupé) ne
sert pas à grand chose :
______________________________________
ppp0 Lien encap:Protocole Point-à-Point
inet adr:82.65.40.201 P-t-P:192.168.254.254
Masque:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:9178 Metric:1
RX packets:4 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:64 (64.0 b) TX bytes:54 (54.0 b)
_____________________________________
A noter également ds le fichier /sbin/unicorn-pppoatm
j'ai rajouté un "$ENCAPS" ici :
_____________
start() {
/sbin/modprobe pppoatm
[ ! "$?" = 0 ] && return $?
/sbin/modprobe $UNICORN ActivationMode=$MODULATION >/dev/null 2>&1
[ ! "$?" = 0 ] && return $?
sleep 10
$PPPD plugin $PLUGIN $VPI.$VCI $ENCAPS
[ ! "$?" = 0 ] && return $?
return 0
}
__________
Bon cette fois-ci je poste depuis knode.. j'espère que cela va resisté au
reboot.. pour le MTU, ma foi !! ;))
Merci, je retourne sous Mdk 10 pour retester, mais il y a une collection de pb réseau ds divers forum, avec une lenteur d'affichage des page web ou pas de connexion du tout.. donc.. pas bon. Par contre, j'ai bien vu le sous du MTU, pourtant ds mon fichier /etc/ppp/options j'ai "mtu 1200" et "mru 1200". Je ne comprend pas cette réécriture, de même il me modifie les dns ds le resolv.conf (tout en mettant de bons dns free). Je pense qu'une option ppp n'est pas bonne et recolte des infos qui perturbe cette connexion. A + tard Stef
Bon, ça y est.. testé , coupé, relancé, etc.... Le problème était apperement lié au MTU et MRU, depuis que j'ai viré le MRU du fichier /etc/ppp/options, cela fonctionne... Mais la ligne "mtu 1200" (valeur Mandrake pour Free 1024 non-dégroupé) ne sert pas à grand chose : ______________________________________
ppp0 Lien encap:Protocole Point-à-Point inet adr:82.65.40.201 P-t-P:192.168.254.254 Masque:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:9178 Metric:1 RX packets:4 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:64 (64.0 b) TX bytes:54 (54.0 b) _____________________________________
A noter également ds le fichier /sbin/unicorn-pppoatm j'ai rajouté un "$ENCAPS" ici : _____________ start() { /sbin/modprobe pppoatm [ ! "$?" = 0 ] && return $? /sbin/modprobe $UNICORN ActivationMode=$MODULATION >/dev/null 2>&1 [ ! "$?" = 0 ] && return $? sleep 10 $PPPD plugin $PLUGIN $VPI.$VCI $ENCAPS [ ! "$?" = 0 ] && return $? return 0 } __________ Bon cette fois-ci je poste depuis knode.. j'espère que cela va resisté au reboot.. pour le MTU, ma foi !! ;))
Stef
g.patel
On Fri, 21 May 2004 14:11:22 +0200, "TiChou" wrote:
Petite rectification, le protocole utiliser pour le ping est l'icmp et non pas l'udp, erreur certainement involontaire de Gerard PATEL.
je confirme : la plupart de mes erreurs sont involontaires :-/ Encore un neurone détruit.
Gérard Patel
On Fri, 21 May 2004 14:11:22 +0200, "TiChou" <gro.uohcit@uohcit>
wrote:
Petite rectification, le protocole utiliser pour le ping est l'icmp et non
pas l'udp, erreur certainement involontaire de Gerard PATEL.
je confirme : la plupart de mes erreurs sont involontaires :-/
Encore un neurone détruit.
Le Sat, 22 May 2004 17:21:19 +0200, Stef Dahl a écrit :
Pour infos, j'ai une MTU... bizare. Et la ligne "mtu 1200" ds le fichier /etc/ppp/options n'y change rien ??? Une idée ? Sinon celà fonctionne. ifconfig : ____________________________ ppp0 Lien encap:Protocole Point-à-Point inet adr:82.64.8.96 P-t-P:192.168.254.254 Masque:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:9178 Metric:1 RX packets:4 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:64 (64.0 b) TX bytes:54 (54.0 b) ____________________________ ;-) Stef
Nota: le MRU (Maximum Receive Unit) est la taille maximale en octets d'un paquet en réception.
La taille maximale de données utiles à transporter, soit les paquets en émission (Maximum Transfert Unit; le MTU contient le paquet IP et son entête), est contrainte par la couche 2 utilisée:
* Ethernet : 1500 * ATM : 9180 ("ATM AAL5 protocol data unit size is 9188 octets" Multiprotocol Encapsulation over ATM Adaptation Layer 5 http://www.zvon.org/tmRFC/RFC1483/Output/frontpage.html mais en réalité, 9180 pour assurer la compatibilité avec le SMDS. http://www.urec.cnrs.fr/cours/Tutoriaux/ATM/IETF/sld012.htm * PPPoE : 1492 (Vous ouvrez une session PPP, qui requiert 8 octets pour sa propre gestion) * PPPoA : 1500
La valeur renvoyée par ifconfig indique que le protocole utilisé est conforme au RFC 2684 - Multiprotocol Encapsulation over ATM Adaptation Layer 5 (Ethernet -ex 1483 -).
Voici l'explication sommaire:
1- préalables:
1.1/ La connexion Free (en dégroupé) fonctionne selon le RFC mentionné (en IP routed). Les explications utiles sont données sur le site suivant: http://mon.adsl.chez.free.fr/modemdegroupe/modemdegroupe.html
1.2/ "En principe, tout modem acceptant la RFC 1483 routed ( ou sa mise à jour la RFC 2684 ) et capable de travailler en VC MUX 8/36 est adaptable. Il est malheureusement notoire que les principes ne garantissent pas le passage à la réalité dans la vie de tous les jours." "Pour une connexion routée, la donnée IP est d'abord extraite du paquet ethernet. C'est seulement la donnée IP qui est encapsulée dans l'ATM".
C'est bien le cas du modem BEWAN PCI.
2- une explication possible du mystère:
La session est bien ouverte en PPPoA => le MTU du fichier de configuration est cohérent.
Mais les paquets IP sont traités par le modem (qui s'adapte lors de la session ATM ouverte avec les équipements aval de Free) et les données sont encapsulées dans des trames ATM. Cette encapsulation s'appuie sur un MTU théorique de 9180 (voir plus haut).
ifconfig semble récupérer la valeur du MTU effectivement pratiqué au terme de l'encapsulation.
Voilà, voilà. Mais c'est encore tout théorique...
Le Sat, 22 May 2004 17:21:19 +0200, Stef Dahl a écrit :
Pour infos, j'ai une MTU... bizare. Et la ligne "mtu 1200" ds le
fichier /etc/ppp/options n'y change rien ???
Une idée ? Sinon celà fonctionne.
ifconfig :
____________________________
ppp0 Lien encap:Protocole Point-à-Point
inet adr:82.64.8.96 P-t-P:192.168.254.254 Masque:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:9178 Metric:1
RX packets:4 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:64 (64.0 b) TX bytes:54 (54.0 b)
____________________________
;-) Stef
Nota: le MRU (Maximum Receive Unit) est la taille maximale en octets
d'un paquet en réception.
La taille maximale de données utiles à transporter, soit les paquets en
émission (Maximum Transfert Unit; le MTU contient le paquet IP et son
entête), est contrainte par la couche 2 utilisée:
* Ethernet : 1500
* ATM : 9180 ("ATM AAL5 protocol data unit size is 9188
octets" Multiprotocol Encapsulation over ATM Adaptation Layer 5
http://www.zvon.org/tmRFC/RFC1483/Output/frontpage.html
mais en réalité, 9180 pour assurer la compatibilité avec
le SMDS.
http://www.urec.cnrs.fr/cours/Tutoriaux/ATM/IETF/sld012.htm
* PPPoE : 1492 (Vous ouvrez une session PPP, qui requiert 8 octets
pour sa propre gestion)
* PPPoA : 1500
La valeur renvoyée par ifconfig indique que le protocole utilisé
est conforme au RFC 2684 - Multiprotocol Encapsulation over
ATM Adaptation Layer 5 (Ethernet -ex 1483 -).
Voici l'explication sommaire:
1- préalables:
1.1/ La connexion Free (en dégroupé) fonctionne selon le RFC mentionné (en
IP routed). Les explications utiles sont données sur le site suivant:
http://mon.adsl.chez.free.fr/modemdegroupe/modemdegroupe.html
1.2/ "En principe, tout modem acceptant la RFC 1483 routed ( ou sa mise à
jour la RFC 2684 ) et capable de travailler en VC MUX 8/36 est adaptable.
Il est malheureusement notoire que les principes ne garantissent pas le
passage à la réalité dans la vie de tous les jours." "Pour une
connexion routée, la donnée IP est d'abord extraite du paquet
ethernet. C'est seulement la donnée IP qui est encapsulée dans l'ATM".
C'est bien le cas du modem BEWAN PCI.
2- une explication possible du mystère:
La session est bien ouverte en PPPoA => le MTU du fichier de configuration
est cohérent.
Mais les paquets IP sont traités par le modem (qui s'adapte lors de la
session ATM ouverte avec les équipements aval de Free) et les données
sont encapsulées dans des trames ATM. Cette encapsulation s'appuie sur un
MTU théorique de 9180 (voir plus haut).
ifconfig semble récupérer la valeur du MTU effectivement pratiqué au
terme de l'encapsulation.
Le Sat, 22 May 2004 17:21:19 +0200, Stef Dahl a écrit :
Pour infos, j'ai une MTU... bizare. Et la ligne "mtu 1200" ds le fichier /etc/ppp/options n'y change rien ??? Une idée ? Sinon celà fonctionne. ifconfig : ____________________________ ppp0 Lien encap:Protocole Point-à-Point inet adr:82.64.8.96 P-t-P:192.168.254.254 Masque:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:9178 Metric:1 RX packets:4 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:64 (64.0 b) TX bytes:54 (54.0 b) ____________________________ ;-) Stef
Nota: le MRU (Maximum Receive Unit) est la taille maximale en octets d'un paquet en réception.
La taille maximale de données utiles à transporter, soit les paquets en émission (Maximum Transfert Unit; le MTU contient le paquet IP et son entête), est contrainte par la couche 2 utilisée:
* Ethernet : 1500 * ATM : 9180 ("ATM AAL5 protocol data unit size is 9188 octets" Multiprotocol Encapsulation over ATM Adaptation Layer 5 http://www.zvon.org/tmRFC/RFC1483/Output/frontpage.html mais en réalité, 9180 pour assurer la compatibilité avec le SMDS. http://www.urec.cnrs.fr/cours/Tutoriaux/ATM/IETF/sld012.htm * PPPoE : 1492 (Vous ouvrez une session PPP, qui requiert 8 octets pour sa propre gestion) * PPPoA : 1500
La valeur renvoyée par ifconfig indique que le protocole utilisé est conforme au RFC 2684 - Multiprotocol Encapsulation over ATM Adaptation Layer 5 (Ethernet -ex 1483 -).
Voici l'explication sommaire:
1- préalables:
1.1/ La connexion Free (en dégroupé) fonctionne selon le RFC mentionné (en IP routed). Les explications utiles sont données sur le site suivant: http://mon.adsl.chez.free.fr/modemdegroupe/modemdegroupe.html
1.2/ "En principe, tout modem acceptant la RFC 1483 routed ( ou sa mise à jour la RFC 2684 ) et capable de travailler en VC MUX 8/36 est adaptable. Il est malheureusement notoire que les principes ne garantissent pas le passage à la réalité dans la vie de tous les jours." "Pour une connexion routée, la donnée IP est d'abord extraite du paquet ethernet. C'est seulement la donnée IP qui est encapsulée dans l'ATM".
C'est bien le cas du modem BEWAN PCI.
2- une explication possible du mystère:
La session est bien ouverte en PPPoA => le MTU du fichier de configuration est cohérent.
Mais les paquets IP sont traités par le modem (qui s'adapte lors de la session ATM ouverte avec les équipements aval de Free) et les données sont encapsulées dans des trames ATM. Cette encapsulation s'appuie sur un MTU théorique de 9180 (voir plus haut).
ifconfig semble récupérer la valeur du MTU effectivement pratiqué au terme de l'encapsulation.
Quelqu'un saurait d'ou vient cette valeur maxi de 1500 pour PPPoA ? La RFC 2364 (PPPoA) n'en parle pas, et la RFC 1661 (PPP) se contente de donner 1500 comme valeur par défaut, mais chaque pair peut demander plus ou moins.
1.1/ La connexion Free (en dégroupé) fonctionne selon le RFC [2684]
Sauf qu'ici, d'après le DNS inverse de l'adresse IP et le type de connexion (PPP) la ligne n'est pas dégroupée. Donc c'est PPPoE ou PPPoA.
C'est seulement la donnée IP qui est encapsulée dans l'ATM".
C'est bien le cas du modem BEWAN PCI.
En dégroupé seulement. Si on prend l'hypothèse que le protocole est PPPoA, le paquet IP est encapsulé dans PPP avant d'être envoyée sur ATM. Comme l'en-tête PPP occupe 2 octets, la MTU résultante (MTU ATM à 9180 - 2 = 9178) correspondrait pile à ce qu'indique ifconfig.
[Crosspost et suivi proposé vers fr.reseaux.telecoms.adsl]
Quelqu'un saurait d'ou vient cette valeur maxi de 1500 pour PPPoA ?
La RFC 2364 (PPPoA) n'en parle pas, et la RFC 1661 (PPP) se contente de
donner 1500 comme valeur par défaut, mais chaque pair peut demander plus
ou moins.
1.1/ La connexion Free (en dégroupé) fonctionne selon le RFC [2684]
Sauf qu'ici, d'après le DNS inverse de l'adresse IP et le type de
connexion (PPP) la ligne n'est pas dégroupée. Donc c'est PPPoE ou PPPoA.
C'est seulement la donnée IP qui est encapsulée dans l'ATM".
C'est bien le cas du modem BEWAN PCI.
En dégroupé seulement. Si on prend l'hypothèse que le protocole est
PPPoA, le paquet IP est encapsulé dans PPP avant d'être envoyée sur ATM.
Comme l'en-tête PPP occupe 2 octets, la MTU résultante
(MTU ATM à 9180 - 2 = 9178) correspondrait pile à ce qu'indique
ifconfig.
[Crosspost et suivi proposé vers fr.reseaux.telecoms.adsl]
Quelqu'un saurait d'ou vient cette valeur maxi de 1500 pour PPPoA ? La RFC 2364 (PPPoA) n'en parle pas, et la RFC 1661 (PPP) se contente de donner 1500 comme valeur par défaut, mais chaque pair peut demander plus ou moins.
1.1/ La connexion Free (en dégroupé) fonctionne selon le RFC [2684]
Sauf qu'ici, d'après le DNS inverse de l'adresse IP et le type de connexion (PPP) la ligne n'est pas dégroupée. Donc c'est PPPoE ou PPPoA.
C'est seulement la donnée IP qui est encapsulée dans l'ATM".
C'est bien le cas du modem BEWAN PCI.
En dégroupé seulement. Si on prend l'hypothèse que le protocole est PPPoA, le paquet IP est encapsulé dans PPP avant d'être envoyée sur ATM. Comme l'en-tête PPP occupe 2 octets, la MTU résultante (MTU ATM à 9180 - 2 = 9178) correspondrait pile à ce qu'indique ifconfig.
[Crosspost et suivi proposé vers fr.reseaux.telecoms.adsl]
