je me rend compte que c'est encore pire la nuit !!!
les serveurs de free serait il en veille passer minuit ???
voici le log de pppoe :
Aug 15 02:43:40 bart pppd[2573]: LCP terminated by peer
Aug 15 02:43:40 bart pppd[2573]: Modem hangup
Aug 15 02:43:40 bart pppd[2573]: Connection terminated.
Aug 15 02:43:40 bart pppd[2573]: Connect time 78.2 minutes.
Aug 15 02:43:40 bart pppd[2573]: Sent 38276826 bytes, received 40943793
bytes.
Aug 15 02:43:40 bart pppd[2573]: Using interface ppp0
Aug 15 02:43:40 bart pppd[2573]: Connect: ppp0 <--> /dev/pts/57
Aug 15 02:43:46 bart pppd[2573]: PAP authentication succeeded
Aug 15 02:43:46 bart pppd[2573]: Cannot determine ethernet address for
proxy ARP
Aug 15 02:43:46 bart pppd[2573]: local IP address 81.56.255.58
Aug 15 02:43:46 bart pppd[2573]: remote IP address 192.168.254.254
Aug 15 02:43:46 bart pppd[2573]: primary DNS address 213.228.0.23
Aug 15 02:43:46 bart pppd[2573]: secondary DNS address 212.27.39.1
Aug 15 02:43:46 bart pppd[2573]: Cannot determine ethernet address for
proxy ARPAug 15 03:00:40 bart pppd[2573]: LCP terminated by peer
Aug 15 03:00:40 bart pppd[2573]: Modem hangup
Aug 15 03:00:40 bart pppd[2573]: Connection terminated.
Aug 15 03:00:40 bart pppd[2573]: Connect time 17.0 minutes.
Aug 15 03:00:40 bart pppd[2573]: Sent 33870027 bytes, received 3748086
bytes.
Aug 15 03:00:41 bart pppd[2573]: Using interface ppp0
Aug 15 03:00:41 bart pppd[2573]: Connect: ppp0 <--> /dev/pts/59
Aug 15 03:00:46 bart pppd[2573]: PAP authentication succeeded
Aug 15 03:00:47 bart pppd[2573]: Cannot determine ethernet address for
proxy ARP
Aug 15 03:00:47 bart pppd[2573]: local IP address 81.56.255.58
Aug 15 03:00:47 bart pppd[2573]: remote IP address 192.168.254.254
Aug 15 03:00:47 bart pppd[2573]: primary DNS address 213.228.0.23
Aug 15 03:00:47 bart pppd[2573]: secondary DNS address 212.27.39.1
Aug 15 03:53:46 bart pppd[2573]: No response to 4 echo-requests
Aug 15 03:53:46 bart pppd[2573]: Serial link appears to be disconnected.
Aug 15 03:53:47 bart pppd[2573]: Connection terminated.
Aug 15 03:53:47 bart pppd[2573]: Connect time 53.1 minutes.
Aug 15 03:53:47 bart pppd[2573]: Sent 120101202 bytes, received 13022816
bytes.
Aug 15 03:53:47 bart pppd[2573]: Using interface ppp0
Aug 15 03:53:47 bart pppd[2573]: Connect: ppp0 <--> /dev/pts/61
Aug 15 03:53:53 bart pppd[2573]: PAP authentication succeeded
Aug 15 03:53:53 bart pppd[2573]: Cannot determine ethernet address for
proxy ARP
Aug 15 03:53:53 bart pppd[2573]: local IP address 81.56.255.58
Aug 15 03:53:53 bart pppd[2573]: remote IP address 192.168.254.254
Aug 15 03:53:53 bart pppd[2573]: primary DNS address 213.228.0.23
Aug 15 03:53:53 bart pppd[2573]: secondary DNS address 212.27.39.1
Aug 15 04:07:02 bart pppd[2573]: LCP terminated by peer
Aug 15 04:07:02 bart pppd[2573]: Modem hangup
Aug 15 04:07:02 bart pppd[2573]: Connection terminated.
Aug 15 04:07:02 bart pppd[2573]: Connect time 13.3 minutes.
Aug 15 04:07:02 bart pppd[2573]: Sent 29602584 bytes, received 2958478
bytes.
Aug 15 04:07:02 bart pppd[2573]: Using interface ppp0
Aug 15 04:07:02 bart pppd[2573]: Connect: ppp0 <--> /dev/pts/63
Aug 15 04:07:08 bart pppd[2573]: PAP authentication succeeded
Aug 15 04:07:08 bart pppd[2573]: Cannot determine ethernet address for
proxy ARP
Aug 15 04:07:08 bart pppd[2573]: local IP address 81.56.255.58
Aug 15 04:07:08 bart pppd[2573]: remote IP address 192.168.254.254
Aug 15 04:07:08 bart pppd[2573]: primary DNS address 213.228.0.23
Aug 15 04:07:08 bart pppd[2573]: secondary DNS address 212.27.39.1
Aug 15 04:36:08 bart pppd[2573]: No response to 4 echo-requests
Aug 15 04:36:08 bart pppd[2573]: Serial link appears to be disconnected.
Aug 15 04:36:08 bart pppd[2573]: Connection terminated.
Aug 15 04:36:08 bart pppd[2573]: Connect time 29.1 minutes.
Aug 15 04:36:08 bart pppd[2573]: Sent 68613942 bytes, received 6789529
bytes.
Aug 15 04:36:09 bart pppd[2573]: Using interface ppp0
Aug 15 04:36:09 bart pppd[2573]: Connect: ppp0 <--> /dev/pts/65
Aug 15 04:36:19 bart pppd[2573]: PAP authentication succeeded
Aug 15 04:36:19 bart pppd[2573]: Cannot determine ethernet address for
proxy ARP
Aug 15 04:36:19 bart pppd[2573]: local IP address 81.56.255.58
Aug 15 04:36:19 bart pppd[2573]: remote IP address 192.168.254.254
Aug 15 04:36:19 bart pppd[2573]: primary DNS address 213.228.0.23
Aug 15 04:36:19 bart pppd[2573]: secondary DNS address 212.27.39.1
Aug 15 04:43:51 bart pppd[2573]: LCP terminated by peer
Aug 15 04:43:51 bart pppd[2573]: Modem hangup
Aug 15 04:43:51 bart pppd[2573]: Connection terminated.
Aug 15 04:43:51 bart pppd[2573]: Connect time 7.7 minutes.
Aug 15 04:43:51 bart pppd[2573]: Sent 17689933 bytes, received 1713696
bytes.
Aug 15 04:43:51 bart pppd[2573]: Using interface ppp0
Aug 15 04:43:51 bart pppd[2573]: Connect: ppp0 <--> /dev/pts/67
Aug 15 04:43:57 bart pppd[2573]: PAP authentication succeeded
Aug 15 04:43:57 bart pppd[2573]: Cannot determine ethernet address for
proxy ARP
Aug 15 04:43:57 bart pppd[2573]: local IP address 81.56.255.58
Aug 15 04:43:57 bart pppd[2573]: remote IP address 192.168.254.254
Aug 15 04:43:57 bart pppd[2573]: primary DNS address 213.228.0.23
Aug 15 04:43:57 bart pppd[2573]: secondary DNS address 212.27.39.1
Aug 15 05:06:30 bart pppd[2573]: LCP terminated by peer
Aug 15 05:06:30 bart pppd[2573]: Modem hangup
Aug 15 05:06:30 bart pppd[2573]: Connection terminated.
Aug 15 05:06:30 bart pppd[2573]: Connect time 22.7 minutes.
Aug 15 05:06:30 bart pppd[2573]: Sent 53704984 bytes, received 4922019
bytes.
Aug 15 05:06:30 bart pppd[2573]: Using interface ppp0
Aug 15 05:06:30 bart pppd[2573]: Connect: ppp0 <--> /dev/pts/69
Aug 15 05:06:36 bart pppd[2573]: PAP authentication succeeded
Aug 15 05:06:36 bart pppd[2573]: Cannot determine ethernet address for
proxy ARP
Aug 15 05:06:36 bart pppd[2573]: local IP address 81.56.255.58
Aug 15 05:06:36 bart pppd[2573]: remote IP address 192.168.254.254
Aug 15 05:06:36 bart pppd[2573]: primary DNS address 213.228.0.23
Aug 15 05:06:36 bart pppd[2573]: secondary DNS address 212.27.39.1
Aug 15 05:21:06 bart pppd[2573]: No response to 4 echo-requests
Aug 15 05:21:06 bart pppd[2573]: Serial link appears to be disconnected.
Aug 15 05:21:06 bart pppd[2573]: Connection terminated.
Aug 15 05:21:06 bart pppd[2573]: Connect time 14.6 minutes.
Aug 15 05:21:06 bart pppd[2573]: Sent 33960567 bytes, received 3436567
bytes.
Aug 15 05:21:06 bart pppd[2573]: Using interface ppp0
Aug 15 05:21:06 bart pppd[2573]: Connect: ppp0 <--> /dev/pts/71
Aug 15 05:21:17 bart pppd[2573]: PAP authentication succeeded
Aug 15 05:21:17 bart pppd[2573]: Cannot determine ethernet address for
proxy ARP
Aug 15 05:21:17 bart pppd[2573]: local IP address 81.56.255.58
Aug 15 05:21:17 bart pppd[2573]: remote IP address 192.168.254.254
Aug 15 05:21:17 bart pppd[2573]: primary DNS address 213.228.0.23
Aug 15 05:21:17 bart pppd[2573]: secondary DNS address 212.27.39.1
Aug 15 05:26:56 bart pppd[2573]: LCP terminated by peer
Aug 15 05:26:56 bart pppd[2573]: Modem hangup
Aug 15 05:26:56 bart pppd[2573]: Connection terminated.
Aug 15 05:26:56 bart pppd[2573]: Connect time 5.9 minutes.
Aug 15 05:26:56 bart pppd[2573]: Sent 13811246 bytes, received 1256021
bytes.
Aug 15 05:26:56 bart pppd[2573]: Using interface ppp0
Aug 15 05:26:56 bart pppd[2573]: Connect: ppp0 <--> /dev/pts/73
Aug 15 05:27:02 bart pppd[2573]: PAP authentication succeeded
Aug 15 05:27:02 bart pppd[2573]: Cannot determine ethernet address for
proxy ARP
Aug 15 05:27:02 bart pppd[2573]: local IP address 81.56.255.58
Aug 15 05:27:02 bart pppd[2573]: remote IP address 192.168.254.254
Aug 15 05:27:02 bart pppd[2573]: primary DNS address 213.228.0.23
Aug 15 05:27:02 bart pppd[2573]: secondary DNS address 212.27.39.1
Aug 15 05:36:02 bart pppd[2573]: No response to 4 echo-requests
Aug 15 05:36:02 bart pppd[2573]: Serial link appears to be disconnected.
Aug 15 05:36:02 bart pppd[2573]: Connection terminated.
Aug 15 05:36:02 bart pppd[2573]: Connect time 9.1 minutes.
Aug 15 05:36:02 bart pppd[2573]: Sent 23468910 bytes, received 1744479
bytes.
Aug 15 05:36:02 bart pppd[2573]: Using interface ppp0
Aug 15 05:36:02 bart pppd[2573]: Connect: ppp0 <--> /dev/pts/75
Aug 15 05:36:08 bart pppd[2573]: PAP authentication succeeded
Aug 15 05:36:08 bart pppd[2573]: Cannot determine ethernet address for
proxy ARP
Aug 15 05:36:08 bart pppd[2573]: local IP address 81.56.255.58
Aug 15 05:36:08 bart pppd[2573]: remote IP address 192.168.254.254
Aug 15 05:36:08 bart pppd[2573]: primary DNS address 213.228.0.23
Aug 15 05:36:08 bart pppd[2573]: secondary DNS address 212.27.39.1
Aug 15 06:04:19 bart pppd[2573]: LCP terminated by peer
Aug 15 06:04:19 bart pppd[2573]: Modem hangup
Aug 15 06:04:19 bart pppd[2573]: Connection terminated.
Aug 15 06:04:19 bart pppd[2573]: Connect time 28.3 minutes.
Aug 15 06:04:19 bart pppd[2573]: Sent 66020483 bytes, received 6238191
bytes.
Aug 15 06:04:19 bart pppd[2573]: Using interface ppp0
Aug 15 06:04:19 bart pppd[2573]: Connect: ppp0 <--> /dev/pts/77
Aug 15 06:04:25 bart pppd[2573]: PAP authentication succeeded
Aug 15 06:04:25 bart pppd[2573]: Cannot determine ethernet address for
proxy ARP
Aug 15 06:04:25 bart pppd[2573]: local IP address 81.56.255.58
Aug 15 06:04:25 bart pppd[2573]: remote IP address 192.168.254.254
Aug 15 06:04:25 bart pppd[2573]: primary DNS address 213.228.0.23
Aug 15 06:04:25 bart pppd[2573]: secondary DNS address 212.27.39.1
Aug 15 06:15:55 bart pppd[2573]: No response to 4 echo-requests
Aug 15 06:15:55 bart pppd[2573]: Serial link appears to be disconnected.
Aug 15 06:15:58 bart pppd[2573]: Connection terminated.
Aug 15 06:15:58 bart pppd[2573]: Connect time 11.6 minutes.
Aug 15 06:15:58 bart pppd[2573]: Sent 27167660 bytes, received 2532257
bytes.
Aug 15 06:15:58 bart pppd[2573]: Using interface ppp0
Aug 15 06:15:58 bart pppd[2573]: Connect: ppp0 <--> /dev/pts/79
Aug 15 06:16:04 bart pppd[2573]: PAP authentication succeeded
Aug 15 06:16:04 bart pppd[2573]: Cannot determine ethernet address for
proxy ARP
Aug 15 06:16:04 bart pppd[2573]: local IP address 81.56.255.58
Aug 15 06:16:04 bart pppd[2573]: remote IP address 192.168.254.254
Aug 15 06:16:04 bart pppd[2573]: primary DNS address 213.228.0.23
Aug 15 06:16:04 bart pppd[2573]: secondary DNS address 212.27.39.1
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-Michel OLTRA
bonjour,
Le dimanche 15 août 2004, TRISTRAM Herve a écrit...
je me rend compte que c'est encore pire la nuit !!! les serveurs de free serait il en veille passer minuit ???
Aug 15 03:53:46 bart pppd[2573]: No response to 4 echo-requests Aug 15 03:53:46 bart pppd[2573]: Serial link appears to be disconnected.
Ce ne serait pas ici qu'il te dit ce qui ne va pas ? Mais est ce pppd qui envoie les pings ou free ? N'y aurait il pas un facteur de blocage aux echo-request ou reply ? le pare-feu ?
-- jm
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
bonjour,
Le dimanche 15 août 2004, TRISTRAM Herve a écrit...
je me rend compte que c'est encore pire la nuit !!!
les serveurs de free serait il en veille passer minuit ???
Aug 15 03:53:46 bart pppd[2573]: No response to 4 echo-requests
Aug 15 03:53:46 bart pppd[2573]: Serial link appears to be disconnected.
Ce ne serait pas ici qu'il te dit ce qui ne va pas ? Mais est ce pppd
qui envoie les pings ou free ? N'y aurait il pas un facteur de blocage
aux echo-request ou reply ? le pare-feu ?
--
jm
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le dimanche 15 août 2004, TRISTRAM Herve a écrit...
je me rend compte que c'est encore pire la nuit !!! les serveurs de free serait il en veille passer minuit ???
Aug 15 03:53:46 bart pppd[2573]: No response to 4 echo-requests Aug 15 03:53:46 bart pppd[2573]: Serial link appears to be disconnected.
Ce ne serait pas ici qu'il te dit ce qui ne va pas ? Mais est ce pppd qui envoie les pings ou free ? N'y aurait il pas un facteur de blocage aux echo-request ou reply ? le pare-feu ?
-- jm
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
TRISTRAM Herve
coucou,
J'ai pensé la meme chose que toi donc j'ai revérifier mon firewall (netfilter)
En entrée, je limite les ping a 4/s aprés la premiere seconde. Mais je pense que c'est plutot que c pppd qui ping pour vérifier l'état de la connexion car on voit dans le log que lorsqu'il se rend compte que le ping est hs, il considére que la liaison est tombée et la relance.
J'ai essayé des ping d'une de mes machines du lan et comme tu peux le voir, c'est pas brillant.
bart:~# ping -c 20 cisco.com PING cisco.com (198.133.219.25) 56(84) bytes of data. 64 bytes from www.cisco.com (198.133.219.25): icmp_seq=1 ttl#9 time8 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq=4 ttl#9 time"8 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq=5 ttl#9 time#0 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq=6 ttl#9 time'5 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq=8 ttl#9 time15 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq=9 ttl#9 time7 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq ttl#9 time)9 ms 64 bytes from 198.133.219.25: icmp_seq ttl#9 time"5 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq ttl#9 time)0 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq ttl#9 time6 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq ttl#9 time#2 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq ttl#9 time&8 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq ttl#9 time$1 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq ttl#9 time!6 ms
--- cisco.com ping statistics --- 20 packets transmitted, 14 received, 30% packet loss, time 62002ms rtt min/avg/max/mdev = 187.573/242.683/315.356/39.817 ms
Jean-Michel OLTRA wrote:
bonjour,
Le dimanche 15 août 2004, TRISTRAM Herve a écrit...
je me rend compte que c'est encore pire la nuit !!! les serveurs de free serait il en veille passer minuit ???
Aug 15 03:53:46 bart pppd[2573]: No response to 4 echo-requests Aug 15 03:53:46 bart pppd[2573]: Serial link appears to be disconnected.
Ce ne serait pas ici qu'il te dit ce qui ne va pas ? Mais est ce pppd qui envoie les pings ou free ? N'y aurait il pas un facteur de blocage aux echo-request ou reply ? le pare-feu ?
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
coucou,
J'ai pensé la meme chose que toi donc j'ai revérifier mon firewall
(netfilter)
En entrée, je limite les ping a 4/s aprés la premiere seconde. Mais je
pense que c'est plutot que c pppd qui ping pour vérifier l'état de la
connexion car on voit dans le log que lorsqu'il se rend compte que le
ping est hs, il considére que la liaison est tombée et la relance.
J'ai essayé des ping d'une de mes machines du lan et comme tu peux le
voir, c'est pas brillant.
bart:~# ping -c 20 cisco.com
PING cisco.com (198.133.219.25) 56(84) bytes of data.
64 bytes from www.cisco.com (198.133.219.25): icmp_seq=1 ttl#9 time8 ms
64 bytes from www.cisco.com (198.133.219.25): icmp_seq=4 ttl#9 time"8 ms
64 bytes from www.cisco.com (198.133.219.25): icmp_seq=5 ttl#9 time#0 ms
64 bytes from www.cisco.com (198.133.219.25): icmp_seq=6 ttl#9 time'5 ms
64 bytes from www.cisco.com (198.133.219.25): icmp_seq=8 ttl#9 time15 ms
64 bytes from www.cisco.com (198.133.219.25): icmp_seq=9 ttl#9 time7 ms
64 bytes from www.cisco.com (198.133.219.25): icmp_seq ttl#9
time)9 ms
64 bytes from 198.133.219.25: icmp_seq ttl#9 time"5 ms
64 bytes from www.cisco.com (198.133.219.25): icmp_seq ttl#9
time)0 ms
64 bytes from www.cisco.com (198.133.219.25): icmp_seq ttl#9
time6 ms
64 bytes from www.cisco.com (198.133.219.25): icmp_seq ttl#9
time#2 ms
64 bytes from www.cisco.com (198.133.219.25): icmp_seq ttl#9
time&8 ms
64 bytes from www.cisco.com (198.133.219.25): icmp_seq ttl#9
time$1 ms
64 bytes from www.cisco.com (198.133.219.25): icmp_seq ttl#9
time!6 ms
--- cisco.com ping statistics ---
20 packets transmitted, 14 received, 30% packet loss, time 62002ms
rtt min/avg/max/mdev = 187.573/242.683/315.356/39.817 ms
Jean-Michel OLTRA wrote:
bonjour,
Le dimanche 15 août 2004, TRISTRAM Herve a écrit...
je me rend compte que c'est encore pire la nuit !!!
les serveurs de free serait il en veille passer minuit ???
Aug 15 03:53:46 bart pppd[2573]: No response to 4 echo-requests
Aug 15 03:53:46 bart pppd[2573]: Serial link appears to be disconnected.
Ce ne serait pas ici qu'il te dit ce qui ne va pas ? Mais est ce pppd
qui envoie les pings ou free ? N'y aurait il pas un facteur de blocage
aux echo-request ou reply ? le pare-feu ?
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
J'ai pensé la meme chose que toi donc j'ai revérifier mon firewall (netfilter)
En entrée, je limite les ping a 4/s aprés la premiere seconde. Mais je pense que c'est plutot que c pppd qui ping pour vérifier l'état de la connexion car on voit dans le log que lorsqu'il se rend compte que le ping est hs, il considére que la liaison est tombée et la relance.
J'ai essayé des ping d'une de mes machines du lan et comme tu peux le voir, c'est pas brillant.
bart:~# ping -c 20 cisco.com PING cisco.com (198.133.219.25) 56(84) bytes of data. 64 bytes from www.cisco.com (198.133.219.25): icmp_seq=1 ttl#9 time8 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq=4 ttl#9 time"8 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq=5 ttl#9 time#0 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq=6 ttl#9 time'5 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq=8 ttl#9 time15 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq=9 ttl#9 time7 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq ttl#9 time)9 ms 64 bytes from 198.133.219.25: icmp_seq ttl#9 time"5 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq ttl#9 time)0 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq ttl#9 time6 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq ttl#9 time#2 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq ttl#9 time&8 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq ttl#9 time$1 ms 64 bytes from www.cisco.com (198.133.219.25): icmp_seq ttl#9 time!6 ms
--- cisco.com ping statistics --- 20 packets transmitted, 14 received, 30% packet loss, time 62002ms rtt min/avg/max/mdev = 187.573/242.683/315.356/39.817 ms
Jean-Michel OLTRA wrote:
bonjour,
Le dimanche 15 août 2004, TRISTRAM Herve a écrit...
je me rend compte que c'est encore pire la nuit !!! les serveurs de free serait il en veille passer minuit ???
Aug 15 03:53:46 bart pppd[2573]: No response to 4 echo-requests Aug 15 03:53:46 bart pppd[2573]: Serial link appears to be disconnected.
Ce ne serait pas ici qu'il te dit ce qui ne va pas ? Mais est ce pppd qui envoie les pings ou free ? N'y aurait il pas un facteur de blocage aux echo-request ou reply ? le pare-feu ?
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Annie D.
TRISTRAM Herve wrote:
>>Aug 15 03:53:46 bart pppd[2573]: No response to 4 echo-requests >>Aug 15 03:53:46 bart pppd[2573]: Serial link appears to be disconnected. > > Ce ne serait pas ici qu'il te dit ce qui ne va pas ? Mais est ce pppd > qui envoie les pings ou free ?
Ici c'est pppd. Il est probable que le LNS du FAI en fasse autant de son côté pour détecter les déconnexions sauvages des abonnés.
> N'y aurait il pas un facteur de blocage > aux echo-request ou reply ? le pare-feu ?
J'ai pensé la meme chose que toi donc j'ai revérifier mon firewall (netfilter)
Inutile. Les "echo-request" de pppd ne sont pas des messages ICMP/IP mais des messages LCP qui font partie du protocole PPP. Il font partie de la couche liaison, donc en-dessous et invisibles de la couche réseau (IP) et Netfilter.
bart:~# ping -c 20 cisco.com
Vous devriez choisir une destination plus proche de vous, comme un serveur de votre FAI. Le choix du routeur d'accès LNS (pair PPP) n'est pas par contre pas forcément une bonne idée, car le traitement des messages ICMP est en basse priorité sur ces équipements (ils n'ont pas que ça à faire).
20 packets transmitted, 14 received, 30% packet loss, time 62002ms
C'est pas fameux, mais la destination est tellement lointaine que vous ne pouvez pas savoir si le problème est proche de vous ou pas.
PS: ça peut être intéressant de regarder les logs de pppoe aussi.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
TRISTRAM Herve wrote:
>>Aug 15 03:53:46 bart pppd[2573]: No response to 4 echo-requests
>>Aug 15 03:53:46 bart pppd[2573]: Serial link appears to be disconnected.
>
> Ce ne serait pas ici qu'il te dit ce qui ne va pas ? Mais est ce pppd
> qui envoie les pings ou free ?
Ici c'est pppd. Il est probable que le LNS du FAI en fasse autant de son
côté pour détecter les déconnexions sauvages des abonnés.
> N'y aurait il pas un facteur de blocage
> aux echo-request ou reply ? le pare-feu ?
J'ai pensé la meme chose que toi donc j'ai revérifier mon firewall
(netfilter)
Inutile. Les "echo-request" de pppd ne sont pas des messages ICMP/IP
mais des messages LCP qui font partie du protocole PPP. Il font partie
de la couche liaison, donc en-dessous et invisibles de la couche réseau
(IP) et Netfilter.
bart:~# ping -c 20 cisco.com
Vous devriez choisir une destination plus proche de vous, comme un
serveur de votre FAI. Le choix du routeur d'accès LNS (pair PPP) n'est
pas par contre pas forcément une bonne idée, car le traitement des
messages ICMP est en basse priorité sur ces équipements (ils n'ont pas
que ça à faire).
20 packets transmitted, 14 received, 30% packet loss, time 62002ms
C'est pas fameux, mais la destination est tellement lointaine que vous
ne pouvez pas savoir si le problème est proche de vous ou pas.
PS: ça peut être intéressant de regarder les logs de pppoe aussi.
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>>Aug 15 03:53:46 bart pppd[2573]: No response to 4 echo-requests >>Aug 15 03:53:46 bart pppd[2573]: Serial link appears to be disconnected. > > Ce ne serait pas ici qu'il te dit ce qui ne va pas ? Mais est ce pppd > qui envoie les pings ou free ?
Ici c'est pppd. Il est probable que le LNS du FAI en fasse autant de son côté pour détecter les déconnexions sauvages des abonnés.
> N'y aurait il pas un facteur de blocage > aux echo-request ou reply ? le pare-feu ?
J'ai pensé la meme chose que toi donc j'ai revérifier mon firewall (netfilter)
Inutile. Les "echo-request" de pppd ne sont pas des messages ICMP/IP mais des messages LCP qui font partie du protocole PPP. Il font partie de la couche liaison, donc en-dessous et invisibles de la couche réseau (IP) et Netfilter.
bart:~# ping -c 20 cisco.com
Vous devriez choisir une destination plus proche de vous, comme un serveur de votre FAI. Le choix du routeur d'accès LNS (pair PPP) n'est pas par contre pas forcément une bonne idée, car le traitement des messages ICMP est en basse priorité sur ces équipements (ils n'ont pas que ça à faire).
20 packets transmitted, 14 received, 30% packet loss, time 62002ms
C'est pas fameux, mais la destination est tellement lointaine que vous ne pouvez pas savoir si le problème est proche de vous ou pas.
PS: ça peut être intéressant de regarder les logs de pppoe aussi.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Thomas Labourdette
Le Sun, Aug 15, 2004 at 12:33:12PM +0200, TRISTRAM Herve écrivait:
En entrée, je limite les ping a 4/s aprés la premiere seconde. J'ai essayé des ping d'une de mes machines du lan et comme tu peux le voir, c'est pas brillant.
bart:~# ping -c 20 cisco.com PING cisco.com (198.133.219.25) 56(84) bytes of data. 20 packets transmitted, 14 received, 30% packet loss, time 62002ms rtt min/avg/max/mdev = 187.573/242.683/315.356/39.817 ms
Et en enlevant la limite de 4 ping /seconde, ça donne quoi ?
@+ -- Céphée NOMENAL Comment appelle-t-on les habitants de la capitale de la France ? Les Francais. (Les bavures du maillon faible.)
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le Sun, Aug 15, 2004 at 12:33:12PM +0200, TRISTRAM Herve écrivait:
En entrée, je limite les ping a 4/s aprés la premiere seconde.
J'ai essayé des ping d'une de mes machines du lan et comme tu peux le
voir, c'est pas brillant.
bart:~# ping -c 20 cisco.com
PING cisco.com (198.133.219.25) 56(84) bytes of data.
20 packets transmitted, 14 received, 30% packet loss, time 62002ms
rtt min/avg/max/mdev = 187.573/242.683/315.356/39.817 ms
Et en enlevant la limite de 4 ping /seconde, ça donne quoi ?
@+
--
Céphée NOMENAL
Comment appelle-t-on les habitants de la capitale de la France ?
Les Francais.
(Les bavures du maillon faible.)
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le Sun, Aug 15, 2004 at 12:33:12PM +0200, TRISTRAM Herve écrivait:
En entrée, je limite les ping a 4/s aprés la premiere seconde. J'ai essayé des ping d'une de mes machines du lan et comme tu peux le voir, c'est pas brillant.
bart:~# ping -c 20 cisco.com PING cisco.com (198.133.219.25) 56(84) bytes of data. 20 packets transmitted, 14 received, 30% packet loss, time 62002ms rtt min/avg/max/mdev = 187.573/242.683/315.356/39.817 ms
Et en enlevant la limite de 4 ping /seconde, ça donne quoi ?
@+ -- Céphée NOMENAL Comment appelle-t-on les habitants de la capitale de la France ? Les Francais. (Les bavures du maillon faible.)
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
TRISTRAM Herve
J'ai enlevé la limite de ping, pas de changement. Comme Annie le conseiller dans sa réponse, j'ai pingé le premier routeur que je traverse et le ping est bon, pas de perte.
bart:/var/log# traceroute ns1.free.Fr traceroute to dial-ns1-2.free.Fr (213.228.0.168), 30 hops max, 38 byte packets 1 192.168.254.254 (192.168.254.254) 41.100 ms 39.061 ms 39.876 ms 2 vlq-6k-2.routers.proxad.net (212.27.37.61) 39.133 ms 37.825 ms 38.891 ms 3 vlq-6k-1-a6.routers.proxad.net (213.228.3.1) 40.840 ms 40.066 ms 39.560 ms 4 dnscache1-l.proxad.net (213.228.0.168) 40.174 ms 40.112 ms 39.869 ms bart:/var/log# ping -c 20 192.168.254.254 PING 192.168.254.254 (192.168.254.254) 56(84) bytes of data. 64 bytes from 192.168.254.254: icmp_seq=1 ttl%5 timeC.4 ms 64 bytes from 192.168.254.254: icmp_seq=2 ttl%5 timeA.4 ms 64 bytes from 192.168.254.254: icmp_seq=3 ttl%5 timeA.9 ms 64 bytes from 192.168.254.254: icmp_seq=4 ttl%5 timeC.2 ms 64 bytes from 192.168.254.254: icmp_seq=5 ttl%5 timeA.2 ms 64 bytes from 192.168.254.254: icmp_seq=6 ttl%5 timeB.5 ms 64 bytes from 192.168.254.254: icmp_seq=7 ttl%5 timeC.2 ms 64 bytes from 192.168.254.254: icmp_seq=8 ttl%5 timeA.0 ms 64 bytes from 192.168.254.254: icmp_seq=9 ttl%5 timeC.0 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 timeA.6 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 timeB.1 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 timeA.0 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 timeA.6 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 timeB.7 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 timeA.9 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 timeB.7 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 timeA.7 ms
--- 192.168.254.254 ping statistics --- 20 packets transmitted, 20 received, 0% packet loss, time 19016ms rtt min/avg/max/mdev = 40.399/41.933/43.459/0.952 ms
J'ai également vérifier mes logs pppd, et j'ai une quantité impressionnante de ces messages :
pppoe: Timeout waiting for PADO packets PADS: System-Error: No resources
J'ai lu sur un forum que si la modem était connecté en ethernet, il était préférable que la carte réseau soit en half-duplex. Est ce vrai ??
Merci
Thomas Labourdette wrote:
Le Sun, Aug 15, 2004 at 12:33:12PM +0200, TRISTRAM Herve écrivait:
En entrée, je limite les ping a 4/s aprés la premiere seconde. J'ai essayé des ping d'une de mes machines du lan et comme tu peux le voir, c'est pas brillant.
bart:~# ping -c 20 cisco.com PING cisco.com (198.133.219.25) 56(84) bytes of data. 20 packets transmitted, 14 received, 30% packet loss, time 62002ms rtt min/avg/max/mdev = 187.573/242.683/315.356/39.817 ms
Et en enlevant la limite de 4 ping /seconde, ça donne quoi ?
@+
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
J'ai enlevé la limite de ping, pas de changement.
Comme Annie le conseiller dans sa réponse, j'ai pingé le premier routeur
que je traverse et le ping est bon, pas de perte.
bart:/var/log# traceroute ns1.free.Fr
traceroute to dial-ns1-2.free.Fr (213.228.0.168), 30 hops max, 38 byte
packets
1 192.168.254.254 (192.168.254.254) 41.100 ms 39.061 ms 39.876 ms
2 vlq-6k-2.routers.proxad.net (212.27.37.61) 39.133 ms 37.825 ms
38.891 ms
3 vlq-6k-1-a6.routers.proxad.net (213.228.3.1) 40.840 ms 40.066 ms
39.560 ms
4 dnscache1-l.proxad.net (213.228.0.168) 40.174 ms 40.112 ms 39.869 ms
bart:/var/log# ping -c 20 192.168.254.254
PING 192.168.254.254 (192.168.254.254) 56(84) bytes of data.
64 bytes from 192.168.254.254: icmp_seq=1 ttl%5 timeC.4 ms
64 bytes from 192.168.254.254: icmp_seq=2 ttl%5 timeA.4 ms
64 bytes from 192.168.254.254: icmp_seq=3 ttl%5 timeA.9 ms
64 bytes from 192.168.254.254: icmp_seq=4 ttl%5 timeC.2 ms
64 bytes from 192.168.254.254: icmp_seq=5 ttl%5 timeA.2 ms
64 bytes from 192.168.254.254: icmp_seq=6 ttl%5 timeB.5 ms
64 bytes from 192.168.254.254: icmp_seq=7 ttl%5 timeC.2 ms
64 bytes from 192.168.254.254: icmp_seq=8 ttl%5 timeA.0 ms
64 bytes from 192.168.254.254: icmp_seq=9 ttl%5 timeC.0 ms
64 bytes from 192.168.254.254: icmp_seq ttl%5 time@.3 ms
64 bytes from 192.168.254.254: icmp_seq ttl%5 timeA.6 ms
64 bytes from 192.168.254.254: icmp_seq ttl%5 timeB.1 ms
64 bytes from 192.168.254.254: icmp_seq ttl%5 timeA.0 ms
64 bytes from 192.168.254.254: icmp_seq ttl%5 timeA.6 ms
64 bytes from 192.168.254.254: icmp_seq ttl%5 timeB.7 ms
64 bytes from 192.168.254.254: icmp_seq ttl%5 time@.7 ms
64 bytes from 192.168.254.254: icmp_seq ttl%5 timeA.9 ms
64 bytes from 192.168.254.254: icmp_seq ttl%5 timeB.7 ms
64 bytes from 192.168.254.254: icmp_seq ttl%5 time@.5 ms
64 bytes from 192.168.254.254: icmp_seq ttl%5 timeA.7 ms
--- 192.168.254.254 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19016ms
rtt min/avg/max/mdev = 40.399/41.933/43.459/0.952 ms
J'ai également vérifier mes logs pppd, et j'ai une quantité
impressionnante de ces messages :
pppoe: Timeout waiting for PADO packets
PADS: System-Error: No resources
J'ai lu sur un forum que si la modem était connecté en ethernet, il
était préférable que la carte réseau soit en half-duplex. Est ce vrai ??
Merci
Thomas Labourdette wrote:
Le Sun, Aug 15, 2004 at 12:33:12PM +0200, TRISTRAM Herve écrivait:
En entrée, je limite les ping a 4/s aprés la premiere seconde.
J'ai essayé des ping d'une de mes machines du lan et comme tu peux le
voir, c'est pas brillant.
bart:~# ping -c 20 cisco.com
PING cisco.com (198.133.219.25) 56(84) bytes of data.
20 packets transmitted, 14 received, 30% packet loss, time 62002ms
rtt min/avg/max/mdev = 187.573/242.683/315.356/39.817 ms
Et en enlevant la limite de 4 ping /seconde, ça donne quoi ?
@+
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
J'ai enlevé la limite de ping, pas de changement. Comme Annie le conseiller dans sa réponse, j'ai pingé le premier routeur que je traverse et le ping est bon, pas de perte.
bart:/var/log# traceroute ns1.free.Fr traceroute to dial-ns1-2.free.Fr (213.228.0.168), 30 hops max, 38 byte packets 1 192.168.254.254 (192.168.254.254) 41.100 ms 39.061 ms 39.876 ms 2 vlq-6k-2.routers.proxad.net (212.27.37.61) 39.133 ms 37.825 ms 38.891 ms 3 vlq-6k-1-a6.routers.proxad.net (213.228.3.1) 40.840 ms 40.066 ms 39.560 ms 4 dnscache1-l.proxad.net (213.228.0.168) 40.174 ms 40.112 ms 39.869 ms bart:/var/log# ping -c 20 192.168.254.254 PING 192.168.254.254 (192.168.254.254) 56(84) bytes of data. 64 bytes from 192.168.254.254: icmp_seq=1 ttl%5 timeC.4 ms 64 bytes from 192.168.254.254: icmp_seq=2 ttl%5 timeA.4 ms 64 bytes from 192.168.254.254: icmp_seq=3 ttl%5 timeA.9 ms 64 bytes from 192.168.254.254: icmp_seq=4 ttl%5 timeC.2 ms 64 bytes from 192.168.254.254: icmp_seq=5 ttl%5 timeA.2 ms 64 bytes from 192.168.254.254: icmp_seq=6 ttl%5 timeB.5 ms 64 bytes from 192.168.254.254: icmp_seq=7 ttl%5 timeC.2 ms 64 bytes from 192.168.254.254: icmp_seq=8 ttl%5 timeA.0 ms 64 bytes from 192.168.254.254: icmp_seq=9 ttl%5 timeC.0 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 timeA.6 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 timeB.1 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 timeA.0 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 timeA.6 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 timeB.7 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 timeA.9 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 timeB.7 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 ms 64 bytes from 192.168.254.254: icmp_seq ttl%5 timeA.7 ms
--- 192.168.254.254 ping statistics --- 20 packets transmitted, 20 received, 0% packet loss, time 19016ms rtt min/avg/max/mdev = 40.399/41.933/43.459/0.952 ms
J'ai également vérifier mes logs pppd, et j'ai une quantité impressionnante de ces messages :
pppoe: Timeout waiting for PADO packets PADS: System-Error: No resources
J'ai lu sur un forum que si la modem était connecté en ethernet, il était préférable que la carte réseau soit en half-duplex. Est ce vrai ??
Merci
Thomas Labourdette wrote:
Le Sun, Aug 15, 2004 at 12:33:12PM +0200, TRISTRAM Herve écrivait:
En entrée, je limite les ping a 4/s aprés la premiere seconde. J'ai essayé des ping d'une de mes machines du lan et comme tu peux le voir, c'est pas brillant.
bart:~# ping -c 20 cisco.com PING cisco.com (198.133.219.25) 56(84) bytes of data. 20 packets transmitted, 14 received, 30% packet loss, time 62002ms rtt min/avg/max/mdev = 187.573/242.683/315.356/39.817 ms
Et en enlevant la limite de 4 ping /seconde, ça donne quoi ?
@+
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Annie D.
TRISTRAM Herve wrote:
Comme Annie le conseiller dans sa réponse, j'ai pingé le premier routeur que je traverse et le ping est bon, pas de perte.
Oui enfin, je disais que ce n'était pas forcément la meilleure idée, le serveur DNS aurait été plus sûr.
PING 192.168.254.254 (192.168.254.254) 56(84) bytes of data.
<couic les 20 lignes>
Vous savez, ce n'était pas nécessaire de tout copier, les deux lignes de statistiques suffisaient.
J'ai également vérifier mes logs pppd, et j'ai une quantité impressionnante de ces messages :
pppoe: Timeout waiting for PADO packets PADS: System-Error: No resources
Ah, ça c'est intéressant. Ça pourrait être le BAS de FT qui est surchargé. Le premier message pourrait aussi être dû à un défaut entre vous et le BAS, mais la seconde est typique d'un problème sur le BAS. Une chose à essayer est d'augmenter le délai avant reconnexion (option 'holdoff' de pppd). Il est arrivé que ma passerelle ne puisse pas se reconnecter pendant des heurs et reçoive systématiquement ces erreurs PADS sans raison (pas de panne du BAS) ; un arrêt forcé de pppd pendant plus long que le holdoff a suffi tout remettre dans l'ordre. Ça n'a rien à voir, mais vous pouvez aussi augmenter la tolérance sur les options lcp-echo ('lcp-echo-failure' et 'lcp-echo-interval') pour essayer de limiter les déconnexions à l'initiative de votre pppd.
J'ai lu sur un forum que si la modem était connecté en ethernet, il était préférable que la carte réseau soit en half-duplex. Est ce vrai ??
Comme toujours en ethernet, il vaut beaucoup mieux que les deux côtés soient configurés dans le même mode de duplex. Le réglage auto sur la carte devrait suffire, ou forcez-la dans le même mode que le modem (voir sa notice). Le symptôme d'un mauvais duplex que j'ai pu constater est un débit inférieur à ce qu'il devrait être pendant des transferts intensifs.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
TRISTRAM Herve wrote:
Comme Annie le conseiller dans sa réponse, j'ai pingé le premier routeur
que je traverse et le ping est bon, pas de perte.
Oui enfin, je disais que ce n'était pas forcément la meilleure idée, le
serveur DNS aurait été plus sûr.
PING 192.168.254.254 (192.168.254.254) 56(84) bytes of data.
<couic les 20 lignes>
Vous savez, ce n'était pas nécessaire de tout copier, les deux lignes de
statistiques suffisaient.
J'ai également vérifier mes logs pppd, et j'ai une quantité
impressionnante de ces messages :
pppoe: Timeout waiting for PADO packets
PADS: System-Error: No resources
Ah, ça c'est intéressant. Ça pourrait être le BAS de FT qui est
surchargé. Le premier message pourrait aussi être dû à un défaut entre
vous et le BAS, mais la seconde est typique d'un problème sur le BAS.
Une chose à essayer est d'augmenter le délai avant reconnexion (option
'holdoff' de pppd). Il est arrivé que ma passerelle ne puisse pas se
reconnecter pendant des heurs et reçoive systématiquement ces erreurs
PADS sans raison (pas de panne du BAS) ; un arrêt forcé de pppd pendant
plus long que le holdoff a suffi tout remettre dans l'ordre. Ça n'a rien
à voir, mais vous pouvez aussi augmenter la tolérance sur les options
lcp-echo ('lcp-echo-failure' et 'lcp-echo-interval') pour essayer de
limiter les déconnexions à l'initiative de votre pppd.
J'ai lu sur un forum que si la modem était connecté en ethernet, il
était préférable que la carte réseau soit en half-duplex. Est ce vrai ??
Comme toujours en ethernet, il vaut beaucoup mieux que les deux côtés
soient configurés dans le même mode de duplex. Le réglage auto sur la
carte devrait suffire, ou forcez-la dans le même mode que le modem (voir
sa notice). Le symptôme d'un mauvais duplex que j'ai pu constater est un
débit inférieur à ce qu'il devrait être pendant des transferts
intensifs.
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Comme Annie le conseiller dans sa réponse, j'ai pingé le premier routeur que je traverse et le ping est bon, pas de perte.
Oui enfin, je disais que ce n'était pas forcément la meilleure idée, le serveur DNS aurait été plus sûr.
PING 192.168.254.254 (192.168.254.254) 56(84) bytes of data.
<couic les 20 lignes>
Vous savez, ce n'était pas nécessaire de tout copier, les deux lignes de statistiques suffisaient.
J'ai également vérifier mes logs pppd, et j'ai une quantité impressionnante de ces messages :
pppoe: Timeout waiting for PADO packets PADS: System-Error: No resources
Ah, ça c'est intéressant. Ça pourrait être le BAS de FT qui est surchargé. Le premier message pourrait aussi être dû à un défaut entre vous et le BAS, mais la seconde est typique d'un problème sur le BAS. Une chose à essayer est d'augmenter le délai avant reconnexion (option 'holdoff' de pppd). Il est arrivé que ma passerelle ne puisse pas se reconnecter pendant des heurs et reçoive systématiquement ces erreurs PADS sans raison (pas de panne du BAS) ; un arrêt forcé de pppd pendant plus long que le holdoff a suffi tout remettre dans l'ordre. Ça n'a rien à voir, mais vous pouvez aussi augmenter la tolérance sur les options lcp-echo ('lcp-echo-failure' et 'lcp-echo-interval') pour essayer de limiter les déconnexions à l'initiative de votre pppd.
J'ai lu sur un forum que si la modem était connecté en ethernet, il était préférable que la carte réseau soit en half-duplex. Est ce vrai ??
Comme toujours en ethernet, il vaut beaucoup mieux que les deux côtés soient configurés dans le même mode de duplex. Le réglage auto sur la carte devrait suffire, ou forcez-la dans le même mode que le modem (voir sa notice). Le symptôme d'un mauvais duplex que j'ai pu constater est un débit inférieur à ce qu'il devrait être pendant des transferts intensifs.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
TRISTRAM Herve
Merci beaucoup pour ces infos, je fais les tests et poste mes résultats.
Annie D. wrote:
TRISTRAM Herve wrote:
Comme Annie le conseiller dans sa réponse, j'ai pingé le premier routeur que je traverse et le ping est bon, pas de perte.
Oui enfin, je disais que ce n'était pas forcément la meilleure idée, le serveur DNS aurait été plus sûr.
PING 192.168.254.254 (192.168.254.254) 56(84) bytes of data.
<couic les 20 lignes>
Vous savez, ce n'était pas nécessaire de tout copier, les deux lignes de statistiques suffisaient.
J'ai également vérifier mes logs pppd, et j'ai une quantité impressionnante de ces messages :
pppoe: Timeout waiting for PADO packets PADS: System-Error: No resources
Ah, ça c'est intéressant. Ça pourrait être le BAS de FT qui est surchargé. Le premier message pourrait aussi être dû à un défaut entre vous et le BAS, mais la seconde est typique d'un problème sur le BAS. Une chose à essayer est d'augmenter le délai avant reconnexion (option 'holdoff' de pppd). Il est arrivé que ma passerelle ne puisse pas se reconnecter pendant des heurs et reçoive systématiquement ces erreurs PADS sans raison (pas de panne du BAS) ; un arrêt forcé de pppd pendant plus long que le holdoff a suffi tout remettre dans l'ordre. Ça n'a rien à voir, mais vous pouvez aussi augmenter la tolérance sur les options lcp-echo ('lcp-echo-failure' et 'lcp-echo-interval') pour essayer de limiter les déconnexions à l'initiative de votre pppd.
J'ai lu sur un forum que si la modem était connecté en ethernet, il était préférable que la carte réseau soit en half-duplex. Est ce vrai ??
Comme toujours en ethernet, il vaut beaucoup mieux que les deux côtés soient configurés dans le même mode de duplex. Le réglage auto sur la carte devrait suffire, ou forcez-la dans le même mode que le modem (voir sa notice). Le symptôme d'un mauvais duplex que j'ai pu constater est un débit inférieur à ce qu'il devrait être pendant des transferts intensifs.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Merci beaucoup pour ces infos, je fais les tests et poste mes résultats.
Annie D. wrote:
TRISTRAM Herve wrote:
Comme Annie le conseiller dans sa réponse, j'ai pingé le premier routeur
que je traverse et le ping est bon, pas de perte.
Oui enfin, je disais que ce n'était pas forcément la meilleure idée, le
serveur DNS aurait été plus sûr.
PING 192.168.254.254 (192.168.254.254) 56(84) bytes of data.
<couic les 20 lignes>
Vous savez, ce n'était pas nécessaire de tout copier, les deux lignes de
statistiques suffisaient.
J'ai également vérifier mes logs pppd, et j'ai une quantité
impressionnante de ces messages :
pppoe: Timeout waiting for PADO packets
PADS: System-Error: No resources
Ah, ça c'est intéressant. Ça pourrait être le BAS de FT qui est
surchargé. Le premier message pourrait aussi être dû à un défaut entre
vous et le BAS, mais la seconde est typique d'un problème sur le BAS.
Une chose à essayer est d'augmenter le délai avant reconnexion (option
'holdoff' de pppd). Il est arrivé que ma passerelle ne puisse pas se
reconnecter pendant des heurs et reçoive systématiquement ces erreurs
PADS sans raison (pas de panne du BAS) ; un arrêt forcé de pppd pendant
plus long que le holdoff a suffi tout remettre dans l'ordre. Ça n'a rien
à voir, mais vous pouvez aussi augmenter la tolérance sur les options
lcp-echo ('lcp-echo-failure' et 'lcp-echo-interval') pour essayer de
limiter les déconnexions à l'initiative de votre pppd.
J'ai lu sur un forum que si la modem était connecté en ethernet, il
était préférable que la carte réseau soit en half-duplex. Est ce vrai ??
Comme toujours en ethernet, il vaut beaucoup mieux que les deux côtés
soient configurés dans le même mode de duplex. Le réglage auto sur la
carte devrait suffire, ou forcez-la dans le même mode que le modem (voir
sa notice). Le symptôme d'un mauvais duplex que j'ai pu constater est un
débit inférieur à ce qu'il devrait être pendant des transferts
intensifs.
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Merci beaucoup pour ces infos, je fais les tests et poste mes résultats.
Annie D. wrote:
TRISTRAM Herve wrote:
Comme Annie le conseiller dans sa réponse, j'ai pingé le premier routeur que je traverse et le ping est bon, pas de perte.
Oui enfin, je disais que ce n'était pas forcément la meilleure idée, le serveur DNS aurait été plus sûr.
PING 192.168.254.254 (192.168.254.254) 56(84) bytes of data.
<couic les 20 lignes>
Vous savez, ce n'était pas nécessaire de tout copier, les deux lignes de statistiques suffisaient.
J'ai également vérifier mes logs pppd, et j'ai une quantité impressionnante de ces messages :
pppoe: Timeout waiting for PADO packets PADS: System-Error: No resources
Ah, ça c'est intéressant. Ça pourrait être le BAS de FT qui est surchargé. Le premier message pourrait aussi être dû à un défaut entre vous et le BAS, mais la seconde est typique d'un problème sur le BAS. Une chose à essayer est d'augmenter le délai avant reconnexion (option 'holdoff' de pppd). Il est arrivé que ma passerelle ne puisse pas se reconnecter pendant des heurs et reçoive systématiquement ces erreurs PADS sans raison (pas de panne du BAS) ; un arrêt forcé de pppd pendant plus long que le holdoff a suffi tout remettre dans l'ordre. Ça n'a rien à voir, mais vous pouvez aussi augmenter la tolérance sur les options lcp-echo ('lcp-echo-failure' et 'lcp-echo-interval') pour essayer de limiter les déconnexions à l'initiative de votre pppd.
J'ai lu sur un forum que si la modem était connecté en ethernet, il était préférable que la carte réseau soit en half-duplex. Est ce vrai ??
Comme toujours en ethernet, il vaut beaucoup mieux que les deux côtés soient configurés dans le même mode de duplex. Le réglage auto sur la carte devrait suffire, ou forcez-la dans le même mode que le modem (voir sa notice). Le symptôme d'un mauvais duplex que j'ai pu constater est un débit inférieur à ce qu'il devrait être pendant des transferts intensifs.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
TRISTRAM Herve
Ah c'est pas vrai ça !! j'ai modifie la config comme conseiller par Annie, c'est un peu mieux mais dès qu'il y a du traffic (plus en UL d'ailleur), ça tombe !!!!
Donc pour voir, j'ai installé le modem sur un W2K en ethernet j'ai installé le pppoe et ca marche nickel ! J'ai donc appliquer le paramétre sur la debian et meme résultat, ca tiens pas la route. Mieux je suis obligé d'eteindre le modem pour qu'il dégne se reconnecter !!
Maintenant je n'ai plus cette erreur : PADS: System-Error: No resources mais uniquement celle ci, ca laisse présager une amelioration : pppoe: Timeout waiting for PADO packets
Je continue mes tests !
Annie D. wrote:
TRISTRAM Herve wrote:
Comme Annie le conseiller dans sa réponse, j'ai pingé le premier routeur que je traverse et le ping est bon, pas de perte.
Oui enfin, je disais que ce n'était pas forcément la meilleure idée, le serveur DNS aurait été plus sûr.
PING 192.168.254.254 (192.168.254.254) 56(84) bytes of data.
<couic les 20 lignes>
Vous savez, ce n'était pas nécessaire de tout copier, les deux lignes de statistiques suffisaient.
J'ai également vérifier mes logs pppd, et j'ai une quantité impressionnante de ces messages :
pppoe: Timeout waiting for PADO packets PADS: System-Error: No resources
Ah, ça c'est intéressant. Ça pourrait être le BAS de FT qui est surchargé. Le premier message pourrait aussi être dû à un défaut entre vous et le BAS, mais la seconde est typique d'un problème sur le BAS. Une chose à essayer est d'augmenter le délai avant reconnexion (option 'holdoff' de pppd). Il est arrivé que ma passerelle ne puisse pas se reconnecter pendant des heurs et reçoive systématiquement ces erreurs PADS sans raison (pas de panne du BAS) ; un arrêt forcé de pppd pendant plus long que le holdoff a suffi tout remettre dans l'ordre. Ça n'a rien à voir, mais vous pouvez aussi augmenter la tolérance sur les options lcp-echo ('lcp-echo-failure' et 'lcp-echo-interval') pour essayer de limiter les déconnexions à l'initiative de votre pppd.
J'ai lu sur un forum que si la modem était connecté en ethernet, il était préférable que la carte réseau soit en half-duplex. Est ce vrai ??
Comme toujours en ethernet, il vaut beaucoup mieux que les deux côtés soient configurés dans le même mode de duplex. Le réglage auto sur la carte devrait suffire, ou forcez-la dans le même mode que le modem (voir sa notice). Le symptôme d'un mauvais duplex que j'ai pu constater est un débit inférieur à ce qu'il devrait être pendant des transferts intensifs.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Ah c'est pas vrai ça !!
j'ai modifie la config comme conseiller par Annie, c'est un peu mieux
mais dès qu'il y a du traffic (plus en UL d'ailleur), ça tombe !!!!
Donc pour voir, j'ai installé le modem sur un W2K en ethernet j'ai
installé le pppoe et ca marche nickel !
J'ai donc appliquer le paramétre sur la debian et meme résultat, ca
tiens pas la route. Mieux je suis obligé d'eteindre le modem pour qu'il
dégne se reconnecter !!
Maintenant je n'ai plus cette erreur : PADS: System-Error: No resources
mais uniquement celle ci, ca laisse présager une amelioration : pppoe:
Timeout waiting for PADO packets
Je continue mes tests !
Annie D. wrote:
TRISTRAM Herve wrote:
Comme Annie le conseiller dans sa réponse, j'ai pingé le premier routeur
que je traverse et le ping est bon, pas de perte.
Oui enfin, je disais que ce n'était pas forcément la meilleure idée, le
serveur DNS aurait été plus sûr.
PING 192.168.254.254 (192.168.254.254) 56(84) bytes of data.
<couic les 20 lignes>
Vous savez, ce n'était pas nécessaire de tout copier, les deux lignes de
statistiques suffisaient.
J'ai également vérifier mes logs pppd, et j'ai une quantité
impressionnante de ces messages :
pppoe: Timeout waiting for PADO packets
PADS: System-Error: No resources
Ah, ça c'est intéressant. Ça pourrait être le BAS de FT qui est
surchargé. Le premier message pourrait aussi être dû à un défaut entre
vous et le BAS, mais la seconde est typique d'un problème sur le BAS.
Une chose à essayer est d'augmenter le délai avant reconnexion (option
'holdoff' de pppd). Il est arrivé que ma passerelle ne puisse pas se
reconnecter pendant des heurs et reçoive systématiquement ces erreurs
PADS sans raison (pas de panne du BAS) ; un arrêt forcé de pppd pendant
plus long que le holdoff a suffi tout remettre dans l'ordre. Ça n'a rien
à voir, mais vous pouvez aussi augmenter la tolérance sur les options
lcp-echo ('lcp-echo-failure' et 'lcp-echo-interval') pour essayer de
limiter les déconnexions à l'initiative de votre pppd.
J'ai lu sur un forum que si la modem était connecté en ethernet, il
était préférable que la carte réseau soit en half-duplex. Est ce vrai ??
Comme toujours en ethernet, il vaut beaucoup mieux que les deux côtés
soient configurés dans le même mode de duplex. Le réglage auto sur la
carte devrait suffire, ou forcez-la dans le même mode que le modem (voir
sa notice). Le symptôme d'un mauvais duplex que j'ai pu constater est un
débit inférieur à ce qu'il devrait être pendant des transferts
intensifs.
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Ah c'est pas vrai ça !! j'ai modifie la config comme conseiller par Annie, c'est un peu mieux mais dès qu'il y a du traffic (plus en UL d'ailleur), ça tombe !!!!
Donc pour voir, j'ai installé le modem sur un W2K en ethernet j'ai installé le pppoe et ca marche nickel ! J'ai donc appliquer le paramétre sur la debian et meme résultat, ca tiens pas la route. Mieux je suis obligé d'eteindre le modem pour qu'il dégne se reconnecter !!
Maintenant je n'ai plus cette erreur : PADS: System-Error: No resources mais uniquement celle ci, ca laisse présager une amelioration : pppoe: Timeout waiting for PADO packets
Je continue mes tests !
Annie D. wrote:
TRISTRAM Herve wrote:
Comme Annie le conseiller dans sa réponse, j'ai pingé le premier routeur que je traverse et le ping est bon, pas de perte.
Oui enfin, je disais que ce n'était pas forcément la meilleure idée, le serveur DNS aurait été plus sûr.
PING 192.168.254.254 (192.168.254.254) 56(84) bytes of data.
<couic les 20 lignes>
Vous savez, ce n'était pas nécessaire de tout copier, les deux lignes de statistiques suffisaient.
J'ai également vérifier mes logs pppd, et j'ai une quantité impressionnante de ces messages :
pppoe: Timeout waiting for PADO packets PADS: System-Error: No resources
Ah, ça c'est intéressant. Ça pourrait être le BAS de FT qui est surchargé. Le premier message pourrait aussi être dû à un défaut entre vous et le BAS, mais la seconde est typique d'un problème sur le BAS. Une chose à essayer est d'augmenter le délai avant reconnexion (option 'holdoff' de pppd). Il est arrivé que ma passerelle ne puisse pas se reconnecter pendant des heurs et reçoive systématiquement ces erreurs PADS sans raison (pas de panne du BAS) ; un arrêt forcé de pppd pendant plus long que le holdoff a suffi tout remettre dans l'ordre. Ça n'a rien à voir, mais vous pouvez aussi augmenter la tolérance sur les options lcp-echo ('lcp-echo-failure' et 'lcp-echo-interval') pour essayer de limiter les déconnexions à l'initiative de votre pppd.
J'ai lu sur un forum que si la modem était connecté en ethernet, il était préférable que la carte réseau soit en half-duplex. Est ce vrai ??
Comme toujours en ethernet, il vaut beaucoup mieux que les deux côtés soient configurés dans le même mode de duplex. Le réglage auto sur la carte devrait suffire, ou forcez-la dans le même mode que le modem (voir sa notice). Le symptôme d'un mauvais duplex que j'ai pu constater est un débit inférieur à ce qu'il devrait être pendant des transferts intensifs.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Bertrand Delepine
Bonjour
Tout d'abord, je souhaiterai avoir une précision que je n'ai pas vu jusque là. ADSL lent, ça veut dire quoi ? Peut-on avoir des débits exemples (genre un telechargement sur kernel.org) ? J'ai vu passé un 1Mb en download, et 40 (??) en upload. Si l'unité est des patates/sec, c'est sur, c'est lent. Si c'est bien des ko/sec, ça me parait correct.
On Sun, Aug 15, 2004 at 08:48:19PM +0200, TRISTRAM Herve wrote :
pppoe: Timeout waiting for PADO packets PADS: System-Error: No resources
J'ai déja eu ces erreurs, chez Wanadoo, sur une ville de province, avec un modem Ethernet. Je me faisais déconnecté plusieurs fois par jour, et notamment aux heures de pointes.
Je pense à une surcharge des dslam FT (ou free si dégroupé hein ;), attendre me semble une bonne chose. Maintenant, si ça fait 1 an que ça dure, qu'on ne peut plus télécharger les vidéos des dernières vacances du cousin, appeler Free est possible.
Bon courage,
-- Bertrand Delepine
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Bonjour
Tout d'abord, je souhaiterai avoir une précision que je n'ai pas vu
jusque là. ADSL lent, ça veut dire quoi ? Peut-on avoir des débits
exemples (genre un telechargement sur kernel.org) ?
J'ai vu passé un 1Mb en download, et 40 (??) en upload. Si l'unité est
des patates/sec, c'est sur, c'est lent. Si c'est bien des ko/sec, ça me
parait correct.
On Sun, Aug 15, 2004 at 08:48:19PM +0200, TRISTRAM Herve wrote :
pppoe: Timeout waiting for PADO packets
PADS: System-Error: No resources
J'ai déja eu ces erreurs, chez Wanadoo, sur une ville de province, avec
un modem Ethernet. Je me faisais déconnecté plusieurs fois par jour, et
notamment aux heures de pointes.
Je pense à une surcharge des dslam FT (ou free si dégroupé hein ;),
attendre me semble une bonne chose. Maintenant, si ça fait 1 an que ça
dure, qu'on ne peut plus télécharger les vidéos des dernières vacances du
cousin, appeler Free est possible.
Bon courage,
--
Bertrand Delepine
bertrand@delepine.info
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Tout d'abord, je souhaiterai avoir une précision que je n'ai pas vu jusque là. ADSL lent, ça veut dire quoi ? Peut-on avoir des débits exemples (genre un telechargement sur kernel.org) ? J'ai vu passé un 1Mb en download, et 40 (??) en upload. Si l'unité est des patates/sec, c'est sur, c'est lent. Si c'est bien des ko/sec, ça me parait correct.
On Sun, Aug 15, 2004 at 08:48:19PM +0200, TRISTRAM Herve wrote :
pppoe: Timeout waiting for PADO packets PADS: System-Error: No resources
J'ai déja eu ces erreurs, chez Wanadoo, sur une ville de province, avec un modem Ethernet. Je me faisais déconnecté plusieurs fois par jour, et notamment aux heures de pointes.
Je pense à une surcharge des dslam FT (ou free si dégroupé hein ;), attendre me semble une bonne chose. Maintenant, si ça fait 1 an que ça dure, qu'on ne peut plus télécharger les vidéos des dernières vacances du cousin, appeler Free est possible.
Bon courage,
-- Bertrand Delepine
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
