Interface RED arrête après 2 jours?

par **jgilles** » 18 Sep 2003 21:09

Ca fait deux fois que ca m'arrive... je me branche ce midi et PAF plus d'internet... je me branche local sur mon ipcop et essaie de trouver pourquoi. Rien dans les journeaux ou dans info peut me renseigner sur cet arret subit. j'ai redémarré + redémarré mon modem cable et c'est revenu a la normal. red=modem cable green=172.20.14.xxx pc 133Mhz 32 meg ram dd 1.6Gig il ne me reste que 3 meg ram libre est-ce suffisant?

par **Gesp** » 18 Sep 2003 21:56

Sans snort cela tourne bien avec 32Mo et les réglages standards du cache. Est-ce que ton IP change ou est-elle fixe sur le RED?

par **jgilles** » 18 Sep 2003 23:10

Elle Change si on redémarre sinon l'ip reste aussi longtemps que le modem est branché (par expérience)

par **Gesp** » 19 Sep 2003 00:29

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD>En réponse à:<HR></TD></TR><TR><TD><BLOCKQUOTE>Elle Change si on redémarre </BLOCKQUOTE></TD></TR><TR><TD><HR></TD></TR></TABLE> c'est IPCop que l'on redémarre? Si c'est le cas, il se pourrait que ce soit lié à un bug corrigé dans la prochaine version. rc.updated n'est pas relancé quand l'adresse du bail DHCP est renouvellée. Mais à priori, il n'y a que le client dynsdns qui était touché. Donc il y a de fortes chances que ce ne soit pas cela. Je ne pense pas que ce soit lié à la mémoire. J'ai aussi 32 Mo mais Snort inactif et je ne tombe pas.

par **jgilles** » 19 Sep 2003 04:05

j'ai tout actif + DansGuardian installé mais non actif + un vpn qui roule 24/24

par **Gesp** » 19 Sep 2003 07:46

Dans ce cas là c'est peut-être juste. Mais je pense que tu dois être bloqué comme moi par des barrettes EDO pour être à 32Mo Essaye une fois sans snort pour voir s'il y a une différence.

par **jgilles** » 19 Sep 2003 14:20

ok je test mais sans snort je ne m'expose pas plus aux intrusions ou si c'est seulement un "log" ?

par **Gesp** » 19 Sep 2003 14:50

Il y a eu des vulnérabilités dans snort récement (juste avant le passage à la V1.3.0) donc on n'est moins vulnérable quand il ne tourne pas <IMG SRC="images/smiles/icon_smile.gif"> Moins il y a de services qui tournent, moins il y a de vulnérabilités. Cependant on voit moins les attaques mais le problème étant que dans 90 ou 99% des cas, ce sont des scripts sans conséquences aux adresses pouvant être contrefaites, qu'est-ce que l'on peut y faire? Je crois que le mieux est de ne pas gacher du temps à cela.

par **jgilles** » 19 Sep 2003 14:58

ok! Merci alors je changerai probablement de pc pour faire tourner les services que j'aime bien.

par **Riric** » 22 Sep 2003 12:15

j'ai un truc un peu équivalent, à savoir que ce matin par exemple, l'IPCop que j'ai mis au boulot - donc assez critique - n'avais plus le lien Internet cf. les log ci-dessous. La conf : IPCOP 1.3.0 fix 4 (mais kernel 2.4.20 car le .21 plante mon PC!), Pentium Pro 200, 128Mo RAM (14Mo libres), Snort+Proxy activés, modem Ethernet SpeedTouch home. Sep 20 21:00:02 fwl ntpdate[23087]: step time server xxxxx offset 0.500862 sec Sep 20 21:00:02 fwl ipcop: NTP synchronisation event ...puis des traces sur la chaine INPUT interface ppp0 jusqu'à 23:59:56 Sep 21 00:01:01 fwl syslogd 1.4.1: restart. Sep 21 00:01:02 fwl ipsec_setup: Stopping FreeS/WAN IPsec... ...ensuite je fais un ipsec restart pour resynchroniser mon VPN ...et de nouveau des traces sur INPUT Sep 21 01:39:57 fwl pppd[31579]: No response to 3 echo-requests Sep 21 01:39:57 fwl pppd[31579]: Serial link appears to be disconnected. Sep 21 01:39:57 fwl snort: pcap_loop: recvfrom: Network is down Sep 21 01:39:57 fwl snort: Snort exiting Sep 21 01:39:58 fwl pppd[31579]: Connection terminated. Sep 21 01:39:58 fwl pppd[31579]: Connect time 3884.2 minutes. Sep 21 01:39:58 fwl pppd[31579]: Sent 3513892466 bytes, received 1976148803 bytes. Sep 21 01:39:58 fwl pppd[31579]: Using interface ppp0 Sep 21 01:39:58 fwl pppd[31579]: Connect: ppp0 <--> /dev/ttyp1 Sep 21 01:39:58 fwl pppoe[31581]: read (asyncReadFromPPP): Session 10872: Input/output error Sep 21 01:39:58 fwl pppoe[31581]: Sent PADT Sep 21 01:39:58 fwl pppoe[25047]: PPP session is 22541 Sep 21 01:39:58 fwl ipcop: PPP has gone down on ppp0 Sep 21 01:40:00 fwl pppd[31579]: Remote message: CHAP authentication success, unit 167 Sep 21 01:40:00 fwl pppd[31579]: local IP address 193.251.69.213 Sep 21 01:40:00 fwl pppd[31579]: remote IP address 193.251.69.1 Sep 21 01:40:00 fwl ipcop: PPP has gone up on ppp0 Sep 21 01:40:22 fwl kernel: INPUT IN=ppp0 OUT= MAC= SRC=*.*.*.* DST=x.y.z.w LEN=404 TOS=0x00 PREC=0x00 TTL=107 ID=21067 PROTO=UDP SPT=1048 DPT=1434 LEN=384 Sep 21 01:40:23 fwl ipcop: Dynamic DNS ip-update for something : failure plus de synchro de l'heure (can't find host) par contre, quelques traces sur INPUT ppp0 (mais trés peu).... Du coup ce matin, j'ai arrêté le RED (rc.red stop), ipsec (ipsec stop) puis redémarré à la main.... Sachant qu'aprés, il faut que je me connecte à l'IPCOP de l'autre coté pour faire un restart du VPN, sinon pas de connexion. Une idée ? @+

par **Gesp** » 22 Sep 2003 13:15

De tes logs, je remarques plusieurs choses. Du fait du caractère asynchrone de l'arrivée des messages dans le log, ils ne sont pas toujours dans l'ordre dans lequels ils se passent réellement. On y peut pas grand chose, mais la déconnexion est mélée à la reconnexion dans le log. Deuxièment, il semble que tu n'as pas le fix d'appliqué imposant une pause de 30 s entre la fin d'une session de pppd et la suivante. Il y aurait du y avoir une pause de 30s que l'on ne voit pas dans le log. Il y aurait du y avoir un 'holdoff', $holdoff dans rc.red, procédure dopppoedial() dans les paramêtres de pppd. Je ne sais pas dans quel numéro de fix, c'est appliqué vu qu'il y a longtemps que je n'ai plus de V1.3.0, mais il semble que cela a apporté une solution à certains. J'ai vérifié, la correction est aussi dans le CVS de la V1.3.0 <a href="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ipcop/ipcop/src/rc.d/Attic/rc.red.diff?r1=1.1.2.16.2.2&r2=1.1.2.16&only_with_tag=IPCOP_v1_3_0" target="_blank">http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ipcop/ipcop/src/rc.d/Attic/rc.red.diff?r1=1.1.2.16.2.2&r2=1.1.2.16&only_with_tag=IPCOP_v1_3_0</a> Malheureusement je ne pense pas que la source de tes problèmes viennent de là étant donné que IPCop s'est reconnecté. Il se pourrait que les DNS n'aient pas été en très bonne santé à ce moment, ce qui expliquerait à la fois que l'accès à no-ip et à la remise à l'heure ait échoué, faute de résoudre l'IP des noms. Concernant l'occupation de la mémoire, Linux garde toujours un petit pourcentage de libre en envoyant le surplus dans le cache donc ce n'est pas significatif tant le swap n'est pas plein. Enfin c'est ce qu'il me semble avoir compris, je ne suis pas un spécialiste du sujet.

par **Riric** » 22 Sep 2003 14:08

je viens de vérifier et j'ai ça dans rc.red : my $holdoff = 30; ...snip... push (@pppcommand, ('novj', 'novjccomp', 'holdoff', $holdoff)); ...snip... et d'autres lignes, donc à priori c'est en place. Le pire, c'est que je suis avec l'offre Extense Pro+ de Wanadoo, donc sans déco toutes les 24h....je me demande si dans mon cas, ce ne serait pas mieux (car ça arrive quand même assez souvent). <IMG SRC="images/smiles/icon_mad.gif"> @+

par **jgilles** » 22 Sep 2003 22:59

Cette fin de semaine, le modem cable a changé d'adresse seul et il s'est redémarré seul et sans problèmes. depuis la semaine derniere, j'ai enlevé le snort et monipcop semble OK. il faudra donc que je change le PC... Il n'y a que mon vpn qui n'a pas démarré mais c'est un autre prob qu'il me fait régler.

Interface RED arrête après 2 jours?

Qui est en ligne ?