ADSL-BC

par **Wavyx** » 17 Juin 2002 11:38

ben voilà, ça m'arrive une fois sur deux quand je poste:
Could not connect to the forums database

et si je me trompe pas c'est depuis que j'ai activé le "rester connecté"
si qqun a le même "prob" ou une idée?

par **Xavier** » 17 Juin 2002 11:51

Le 2002-06-17 11:38, Wavyx a écrit:
si qqun a le même "prob" ou une idée?

Oui, quand je surf avec ma conexion skynet...
J'ai l'impression que c'est lier a
http://forum.adsl-bc.org:80/viewtopic.p ... 84&forum=8

par **Wavyx** » 17 Juin 2002 12:22

tu crois que ça a un lien??
comment? je vois pas trop ce coup là...

par **Xavier** » 17 Juin 2002 12:28

Le 2002-06-17 12:22, Wavyx a écrit:
comment? je vois pas trop ce coup là...

Des Packets qui se perdent en sortant du reseau skym***

par **Wavyx** » 17 Juin 2002 15:40

ça fait bcp alors!
pcq un message sur deux/trois! et en parlant que du forum, le reste j'en sais rien...(le tcp/ip s'en occupe)

par **Xavier** » 17 Juin 2002 16:39

Le 2002-06-17 15:40, Wavyx a écrit:
ça fait bcp alors!
pcq un message sur deux/trois! et en parlant que du forum, le reste j'en sais rien...(le tcp/ip s'en occupe)

C'est pas des packets perdu de facon random, ce sont de packet au caractéristique bien precise qui se perdent. Genre le dernier q'un server ftp envoi pour l'authentification du client, ou alors, un de ceux qui est envoyer pour la création d'un tunel IPSEC,... mais toujour le meme...
J'ai aussi constater le phénomeme pour des requete HTTP. Mais la, un retry passe outre.

par **Xavier** » 17 Juin 2002 17:09

Je viens de faire un petit test... envoyer une requete http sur un server wedb avec un log de l'activité reseau coter client et coter server.

Premier essais:
---------------
--16:46:05-- http://www.xvl.be/cgi-bin/submit?COMMAN ... PASSW=test
=> `brol'
Connecting to http://www.xvl.be:80... connected!
HTTP request sent, awaiting response... 302 Redirect
Location: http://www.xvl.be:80/cgi-bin/submit?COM ... PASSW=test [following]
http://www.xvl.be/cgi-bin/submit?COMMAN ... PASSW=test: Redirection cycle detected.

Activité coter client:
16:46:05.902691 217.136.x.y.3033 > 212.68.194.87.80: tcp 0 (DF)
16:46:05.920931 212.68.194.87.80 > 217.136.x.y.3033: tcp 0 (DF)
16:46:05.921257 217.136.x.y.3033 > 212.68.194.87.80: tcp 0 (DF)
16:46:05.927838 217.136.x.y.3033 > 212.68.194.87.80: tcp 172 (DF)
16:46:05.959829 212.68.194.87.80 > 217.136.x.y.3033: tcp 0
16:46:05.965941 212.68.194.87.80 > 217.136.x.y.3033: tcp 512
16:46:05.966214 217.136.x.y.3033 > 212.68.194.87.80: tcp 0 (DF)
16:46:05.966584 212.68.194.87.80 > 217.136.x.y.3033: tcp 0
16:46:05.978697 217.136.x.y.3033 > 212.68.194.87.80: tcp 0 (DF)
16:46:05.993374 212.68.194.87.80 > 217.136.x.y.3033: tcp 0

Activité coter server: RIEN, NADA, SHNOL!

2eme essais:
------------
--16:46:58-- http://www.xvl.be/cgi-bin/submit?COMMAN ... PASSW=test
=> `brol'
Connecting to http://www.xvl.be:80... connected!
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]

0K @ 174.31 B/s

16:46:59 (174.05 B/s) - `brol' saved [114]

Activité coter client:

16:46:58.690388 217.136.x.y.3034 > 212.68.194.87.80: tcp 0 (DF)
16:46:58.750154 212.68.194.87.80 > 217.136.x.y.3034: tcp 0 (DF)
16:46:58.750471 217.136.x.y.3034 > 212.68.194.87.80: tcp 0 (DF)
16:46:58.755956 217.136.x.y.3034 > 212.68.194.87.80: tcp 172 (DF)
16:46:58.809760 212.68.194.87.80 > 217.136.x.y.3034: tcp 0 (DF)
16:46:58.872191 212.68.194.87.80 > 217.136.x.y.3034: tcp 285 (DF)
16:46:58.872447 217.136.x.y.3034 > 212.68.194.87.80: tcp 0 (DF)
16:46:58.881956 212.68.194.87.80 > 217.136.x.y.3034: tcp 12 (DF)
16:46:58.882210 217.136.x.y.3034 > 212.68.194.87.80: tcp 0 (DF)
16:46:58.924113 212.68.194.87.80 > 217.136.x.y.3034: tcp 12 (DF)
16:46:58.924386 217.136.x.y.3034 > 212.68.194.87.80: tcp 0 (DF)
16:46:58.943084 212.68.194.87.80 > 217.136.x.y.3034: tcp 45 (DF)
16:46:58.943338 217.136.x.y.3034 > 212.68.194.87.80: tcp 0 (DF)
16:46:59.493734 212.68.194.87.80 > 217.136.x.y.3034: tcp 27 (DF)
16:46:59.494015 217.136.x.y.3034 > 212.68.194.87.80: tcp 0 (DF)
16:46:59.508193 212.68.194.87.80 > 217.136.x.y.3034: tcp 3 (DF)
16:46:59.508452 217.136.x.y.3034 > 212.68.194.87.80: tcp 0 (DF)
16:46:59.529444 212.68.194.87.80 > 217.136.x.y.3034: tcp 15 (DF)
16:46:59.533035 217.136.x.y.3034 > 212.68.194.87.80: tcp 0 (DF)
16:46:59.565420 212.68.194.87.80 > 217.136.x.y.3034: tcp 0 (DF)

Activité coter server:

16:46:58.697637 217.136.x.y.osmosis-aeea > 212.68.194.87.http: tcp 0 (DF)
16:46:58.697637 212.68.194.87.http > 217.136.x.y.osmosis-aeea: tcp 0 (DF)
16:46:58.757635 217.136.x.y.osmosis-aeea > 212.68.194.87.http: tcp 0 (DF)
16:46:58.777634 217.136.x.y.osmosis-aeea > 212.68.194.87.http: tcp 172 (DF)
16:46:58.777634 212.68.194.87.http > 217.136.x.y.osmosis-aeea: tcp 0 (DF)
16:46:58.807633 212.68.194.87.http > 217.136.x.y.osmosis-aeea: tcp 285 (DF)
16:46:58.817633 212.68.194.87.http > 217.136.x.y.osmosis-aeea: tcp 12 (DF)
16:46:58.877631 217.136.x.y.osmosis-aeea > 212.68.194.87.http: tcp 0 (DF)
16:46:58.887630 217.136.x.y.osmosis-aeea > 212.68.194.87.http: tcp 0 (DF)
16:46:58.897630 212.68.194.87.http > 217.136.x.y.osmosis-aeea: tcp 12 (DF)
16:46:58.897630 212.68.194.87.http > 217.136.x.y.osmosis-aeea: tcp 45 (DF)
16:46:58.927629 217.136.x.y.osmosis-aeea > 212.68.194.87.http: tcp 0 (DF)
16:46:58.947628 217.136.x.y.osmosis-aeea > 212.68.194.87.http: tcp 0 (DF)
16:46:59.457608 212.68.194.87.http > 217.136.x.y.osmosis-aeea: tcp 27 (DF)
16:46:59.477608 212.68.194.87.http > 217.136.x.y.osmosis-aeea: tcp 3 (DF)
16:46:59.497607 212.68.194.87.http > 217.136.x.y.osmosis-aeea: tcp 15 (DF)
16:46:59.497607 217.136.x.y.osmosis-aeea > 212.68.194.87.http: tcp 0 (DF)
16:46:59.517606 217.136.x.y.osmosis-aeea > 212.68.194.87.http: tcp 0 (DF)
16:46:59.537605 217.136.x.y.osmosis-aeea > 212.68.194.87.http: tcp 0 (DF)
16:46:59.537605 212.68.194.87.http > 217.136.x.y.osmosis-aeea: tcp 0 (DF)

Aux 2eme essais, c'est vraiment le bon server qui a répondu. Au premier, quoi qu'en laisse penser le snifer "client", la réponse viens de qq part ailleurs! De ou, mystere! mais skynet est en train de nous entuber. Cela est tres proche du "source spoofing"

Pour ceux qui ne l'on pas encore fait:

iptables -I INPUT -i ppp0 -s 192.168.0.0/16 -j CACA
iptables -I INPUT -i ppp0 -s 172.16.0.0/12 -j CACA
iptables -I INPUT -i ppp0 -s 10.0.0.0/8 -j CACA

par **Wavyx** » 17 Juin 2002 18:28

moi j'ai juste ça:
/sbin/iptables -P FORWARD DROP
/sbin/iptables -A FORWARD -s 10.0.0.0/24 -j ACCEPT
/sbin/iptables -A FORWARD -d 10.0.0.0/24 -j ACCEPT
/sbin/iptables -t nat -A POSTROUTING -o ppp0 -s 10.0.0.0/24 -j MASQUERADE

c assez?
tes rules ajoutent quoi en fait?

par **Xavier** » 17 Juin 2002 19:08

Le 2002-06-17 18:28, Wavyx a écrit:
tes rules ajoutent quoi en fait?

la sertitude q'un packet avec l'addresse source trafiqué ne rentre pas par l'interface ppp0

par **GoA** » 11 Juil 2002 16:45

Je suis chez Skynet, et pour le moment je n'ai pas encore été confronté au problème.

wait & see...

par **Delutilus** » 11 Juil 2002 17:50

Et moi chez Wanadoo et pas de problèmes à ceux que vous avez rencontrés (juste pour info)

ADSL-BC

Could not connect to the forums database !!!

Qui est en ligne ?