Salut tous,
Ma passerelle sous Debian Woody s'est plantée cette nuit près plusieurs
mois d'uptime sans souci. La pile IP vivait encore (réponse au ping,
connexion TCP) donc j'exclus un kernel panic mais aucun service réseau
ne répondait plus (telnet, SSH, DHCP...). J'ai rebranché un écran pour
voir s'il y avait moyen de reprendre la main mais la console était passé
en "veille" (écran noir) depuis des lustre et aucune action sur le
clavier n'a pu la réveiller.
ctrl+alt+suppr pour redémarrer proprement, aussi j'ai fait un reset hard.
La machine redémarre, fsck trouve des erreurs sur l'unique partition de
système de fichiers en ext2 dont deux inodes "unattached", des liaisons
croisées, un inode contenant un tas de "illegal blocks" et d'autres
erreurs qui ne me disaient rien. C'était la première fois que j'avais à
réparer un système de fichier, j'ai accepté tout ce qu'il m'a proposé de
réparer sauf l'inode contenant trop d'invalid blocks qu'il me proposait
de supprimer.
J'aurais tendance à penser qu'une des tâches quotidiennes de cron-daily
est en cause, mais comment savoir ce qui s'est (mal) passé et si ça peut
se reproduire ? Quelqu'un a déjà vu ça ?
Salut tous,
Ma passerelle sous Debian Woody s'est plantée cette nuit près plusieurs
mois d'uptime sans souci. La pile IP vivait encore (réponse au ping,
connexion TCP) donc j'exclus un kernel panic mais aucun service réseau
ne répondait plus (telnet, SSH, DHCP...). J'ai rebranché un écran pour
voir s'il y avait moyen de reprendre la main mais la console était passé
en "veille" (écran noir) depuis des lustre et aucune action sur le
clavier n'a pu la réveiller.
ctrl+alt+suppr pour redémarrer proprement, aussi j'ai fait un reset hard.
La machine redémarre, fsck trouve des erreurs sur l'unique partition de
système de fichiers en ext2 dont deux inodes "unattached", des liaisons
croisées, un inode contenant un tas de "illegal blocks" et d'autres
erreurs qui ne me disaient rien. C'était la première fois que j'avais à
réparer un système de fichier, j'ai accepté tout ce qu'il m'a proposé de
réparer sauf l'inode contenant trop d'invalid blocks qu'il me proposait
de supprimer.
J'aurais tendance à penser qu'une des tâches quotidiennes de cron-daily
est en cause, mais comment savoir ce qui s'est (mal) passé et si ça peut
se reproduire ? Quelqu'un a déjà vu ça ?
Salut tous,
Ma passerelle sous Debian Woody s'est plantée cette nuit près plusieurs
mois d'uptime sans souci. La pile IP vivait encore (réponse au ping,
connexion TCP) donc j'exclus un kernel panic mais aucun service réseau
ne répondait plus (telnet, SSH, DHCP...). J'ai rebranché un écran pour
voir s'il y avait moyen de reprendre la main mais la console était passé
en "veille" (écran noir) depuis des lustre et aucune action sur le
clavier n'a pu la réveiller.
ctrl+alt+suppr pour redémarrer proprement, aussi j'ai fait un reset hard.
La machine redémarre, fsck trouve des erreurs sur l'unique partition de
système de fichiers en ext2 dont deux inodes "unattached", des liaisons
croisées, un inode contenant un tas de "illegal blocks" et d'autres
erreurs qui ne me disaient rien. C'était la première fois que j'avais à
réparer un système de fichier, j'ai accepté tout ce qu'il m'a proposé de
réparer sauf l'inode contenant trop d'invalid blocks qu'il me proposait
de supprimer.
J'aurais tendance à penser qu'une des tâches quotidiennes de cron-daily
est en cause, mais comment savoir ce qui s'est (mal) passé et si ça peut
se reproduire ? Quelqu'un a déjà vu ça ?
Vu les symptômes, c'est un kernel panic qui a planté un des
sous-systèmes du noyau. Vu que la pile IP marchait encore, ce n'est pas
la partie réseau.
La machine redémarre, fsck trouve des erreurs sur l'unique partition de
système de fichiers en ext2 dont deux inodes "unattached", des liaisons
croisées, un inode contenant un tas de "illegal blocks" et d'autres
erreurs qui ne me disaient rien. C'était la première fois que j'avais à
réparer un système de fichier, j'ai accepté tout ce qu'il m'a proposé de
réparer sauf l'inode contenant trop d'invalid blocks qu'il me proposait
de supprimer.
Au vu de celà, je dirais que le kernel panic a touché la partie de
gestion des bloc-device ou un driver lié.
[...]J'aurais tendance à penser qu'une des tâches quotidiennes de cron-daily
est en cause, mais comment savoir ce qui s'est (mal) passé et si ça peut
se reproduire ? Quelqu'un a déjà vu ça ?
Le mieux est de mettre la console sur le port série et d'avoir le port
série connecté à un autre PC. Comme celà, en cas de nouveau crash, tu
auras les logs du noyau. Tu peux éventuellement aussi rediriger une
partie des logs système par le réseau, histoire d'être sur de ne rien
perdre en cas de crash.
Vu les symptômes, c'est un kernel panic qui a planté un des
sous-systèmes du noyau. Vu que la pile IP marchait encore, ce n'est pas
la partie réseau.
La machine redémarre, fsck trouve des erreurs sur l'unique partition de
système de fichiers en ext2 dont deux inodes "unattached", des liaisons
croisées, un inode contenant un tas de "illegal blocks" et d'autres
erreurs qui ne me disaient rien. C'était la première fois que j'avais à
réparer un système de fichier, j'ai accepté tout ce qu'il m'a proposé de
réparer sauf l'inode contenant trop d'invalid blocks qu'il me proposait
de supprimer.
Au vu de celà, je dirais que le kernel panic a touché la partie de
gestion des bloc-device ou un driver lié.
[...]
J'aurais tendance à penser qu'une des tâches quotidiennes de cron-daily
est en cause, mais comment savoir ce qui s'est (mal) passé et si ça peut
se reproduire ? Quelqu'un a déjà vu ça ?
Le mieux est de mettre la console sur le port série et d'avoir le port
série connecté à un autre PC. Comme celà, en cas de nouveau crash, tu
auras les logs du noyau. Tu peux éventuellement aussi rediriger une
partie des logs système par le réseau, histoire d'être sur de ne rien
perdre en cas de crash.
Vu les symptômes, c'est un kernel panic qui a planté un des
sous-systèmes du noyau. Vu que la pile IP marchait encore, ce n'est pas
la partie réseau.
La machine redémarre, fsck trouve des erreurs sur l'unique partition de
système de fichiers en ext2 dont deux inodes "unattached", des liaisons
croisées, un inode contenant un tas de "illegal blocks" et d'autres
erreurs qui ne me disaient rien. C'était la première fois que j'avais à
réparer un système de fichier, j'ai accepté tout ce qu'il m'a proposé de
réparer sauf l'inode contenant trop d'invalid blocks qu'il me proposait
de supprimer.
Au vu de celà, je dirais que le kernel panic a touché la partie de
gestion des bloc-device ou un driver lié.
[...]J'aurais tendance à penser qu'une des tâches quotidiennes de cron-daily
est en cause, mais comment savoir ce qui s'est (mal) passé et si ça peut
se reproduire ? Quelqu'un a déjà vu ça ?
Le mieux est de mettre la console sur le port série et d'avoir le port
série connecté à un autre PC. Comme celà, en cas de nouveau crash, tu
auras les logs du noyau. Tu peux éventuellement aussi rediriger une
partie des logs système par le réseau, histoire d'être sur de ne rien
perdre en cas de crash.
Vu les symptômes, c'est un kernel panic qui a planté un des
sous-systèmes du noyau. Vu que la pile IP marchait encore, ce n'est pas
la partie réseau.
Je ne savais pas qu'un kernel panic n'était que partiel, je croyais que
tout le noyau arrêtait de tourner. Il va falloir que je me documente sur
le sujet.
La machine redémarre, fsck trouve des erreurs sur l'unique partition de
système de fichiers en ext2 dont deux inodes "unattached", des liaisons
croisées, un inode contenant un tas de "illegal blocks" et d'autres
erreurs qui ne me disaient rien. C'était la première fois que j'avais à
réparer un système de fichier, j'ai accepté tout ce qu'il m'a proposé de
réparer sauf l'inode contenant trop d'invalid blocks qu'il me proposait
de supprimer.
Au vu de celà, je dirais que le kernel panic a touché la partie de
gestion des bloc-device ou un driver lié.
Support IDE compilé en dur pour le contrôleur Intel PIIX3 du chipset
Triton VX avec DMA et block mode activés, rien d'expérimental il me semble.
[...]J'aurais tendance à penser qu'une des tâches quotidiennes de cron-daily
est en cause, mais comment savoir ce qui s'est (mal) passé et si ça peut
se reproduire ? Quelqu'un a déjà vu ça ?
Le mieux est de mettre la console sur le port série et d'avoir le port
série connecté à un autre PC. Comme celà, en cas de nouveau crash, tu
auras les logs du noyau. Tu peux éventuellement aussi rediriger une
partie des logs système par le réseau, histoire d'être sur de ne rien
perdre en cas de crash.
Le problème est que cette machine est la seule qui reste allumée en
permanence (c'est chez moi). Mais merci du conseil. Que penses-tu
d'empêcher l'effacement de l'écran (sortie VGA texte) qui se déclenche
suite à l'inactivité de la console ? Ainsi, si le système affiche
quelque chose en cas de nouveau plantage, cela devrait rester visible.
PS: On dirait que la rumeur d'UDP de Free sur Tiscali est fondée, ton
article n'est pas visible sur le serveur de news de Free.
Vu les symptômes, c'est un kernel panic qui a planté un des
sous-systèmes du noyau. Vu que la pile IP marchait encore, ce n'est pas
la partie réseau.
Je ne savais pas qu'un kernel panic n'était que partiel, je croyais que
tout le noyau arrêtait de tourner. Il va falloir que je me documente sur
le sujet.
La machine redémarre, fsck trouve des erreurs sur l'unique partition de
système de fichiers en ext2 dont deux inodes "unattached", des liaisons
croisées, un inode contenant un tas de "illegal blocks" et d'autres
erreurs qui ne me disaient rien. C'était la première fois que j'avais à
réparer un système de fichier, j'ai accepté tout ce qu'il m'a proposé de
réparer sauf l'inode contenant trop d'invalid blocks qu'il me proposait
de supprimer.
Au vu de celà, je dirais que le kernel panic a touché la partie de
gestion des bloc-device ou un driver lié.
Support IDE compilé en dur pour le contrôleur Intel PIIX3 du chipset
Triton VX avec DMA et block mode activés, rien d'expérimental il me semble.
[...]
J'aurais tendance à penser qu'une des tâches quotidiennes de cron-daily
est en cause, mais comment savoir ce qui s'est (mal) passé et si ça peut
se reproduire ? Quelqu'un a déjà vu ça ?
Le mieux est de mettre la console sur le port série et d'avoir le port
série connecté à un autre PC. Comme celà, en cas de nouveau crash, tu
auras les logs du noyau. Tu peux éventuellement aussi rediriger une
partie des logs système par le réseau, histoire d'être sur de ne rien
perdre en cas de crash.
Le problème est que cette machine est la seule qui reste allumée en
permanence (c'est chez moi). Mais merci du conseil. Que penses-tu
d'empêcher l'effacement de l'écran (sortie VGA texte) qui se déclenche
suite à l'inactivité de la console ? Ainsi, si le système affiche
quelque chose en cas de nouveau plantage, cela devrait rester visible.
PS: On dirait que la rumeur d'UDP de Free sur Tiscali est fondée, ton
article n'est pas visible sur le serveur de news de Free.
Vu les symptômes, c'est un kernel panic qui a planté un des
sous-systèmes du noyau. Vu que la pile IP marchait encore, ce n'est pas
la partie réseau.
Je ne savais pas qu'un kernel panic n'était que partiel, je croyais que
tout le noyau arrêtait de tourner. Il va falloir que je me documente sur
le sujet.
La machine redémarre, fsck trouve des erreurs sur l'unique partition de
système de fichiers en ext2 dont deux inodes "unattached", des liaisons
croisées, un inode contenant un tas de "illegal blocks" et d'autres
erreurs qui ne me disaient rien. C'était la première fois que j'avais à
réparer un système de fichier, j'ai accepté tout ce qu'il m'a proposé de
réparer sauf l'inode contenant trop d'invalid blocks qu'il me proposait
de supprimer.
Au vu de celà, je dirais que le kernel panic a touché la partie de
gestion des bloc-device ou un driver lié.
Support IDE compilé en dur pour le contrôleur Intel PIIX3 du chipset
Triton VX avec DMA et block mode activés, rien d'expérimental il me semble.
[...]J'aurais tendance à penser qu'une des tâches quotidiennes de cron-daily
est en cause, mais comment savoir ce qui s'est (mal) passé et si ça peut
se reproduire ? Quelqu'un a déjà vu ça ?
Le mieux est de mettre la console sur le port série et d'avoir le port
série connecté à un autre PC. Comme celà, en cas de nouveau crash, tu
auras les logs du noyau. Tu peux éventuellement aussi rediriger une
partie des logs système par le réseau, histoire d'être sur de ne rien
perdre en cas de crash.
Le problème est que cette machine est la seule qui reste allumée en
permanence (c'est chez moi). Mais merci du conseil. Que penses-tu
d'empêcher l'effacement de l'écran (sortie VGA texte) qui se déclenche
suite à l'inactivité de la console ? Ainsi, si le système affiche
quelque chose en cas de nouveau plantage, cela devrait rester visible.
PS: On dirait que la rumeur d'UDP de Free sur Tiscali est fondée, ton
article n'est pas visible sur le serveur de news de Free.
Je ne savais pas qu'un kernel panic n'était que partiel, je croyais que
tout le noyau arrêtait de tourner. Il va falloir que je me documente sur
le sujet.
C'était vrai sur les 2.2. Depuis le 2.4, le noyau peut résister à
certains panics: en gros, si un thread kernel plante, ça n'empêche pas
les autres de continuer leur boulot, sauf si les structures kernel ont
été "abimées" lors du crash auquel cas on a généralement des crashs
en cascade.
Au vu de celà, je dirais que le kernel panic a touché la partie de
gestion des bloc-device ou un driver lié.
Support IDE compilé en dur pour le contrôleur Intel PIIX3 du chipset
Triton VX avec DMA et block mode activés, rien d'expérimental il me semble.
Rien que du standard, en effet. Tu utilise uniquement de l'ext2 ?
Je ne sais pas si tu peux empêcher facilement la console de s'inactiver.
C'est sans aucun doute possible, au pire en modifiant le noyau.
PS: On dirait que la rumeur d'UDP de Free sur Tiscali est fondée, ton
article n'est pas visible sur le serveur de news de Free.
?
Je ne savais pas qu'un kernel panic n'était que partiel, je croyais que
tout le noyau arrêtait de tourner. Il va falloir que je me documente sur
le sujet.
C'était vrai sur les 2.2. Depuis le 2.4, le noyau peut résister à
certains panics: en gros, si un thread kernel plante, ça n'empêche pas
les autres de continuer leur boulot, sauf si les structures kernel ont
été "abimées" lors du crash auquel cas on a généralement des crashs
en cascade.
Au vu de celà, je dirais que le kernel panic a touché la partie de
gestion des bloc-device ou un driver lié.
Support IDE compilé en dur pour le contrôleur Intel PIIX3 du chipset
Triton VX avec DMA et block mode activés, rien d'expérimental il me semble.
Rien que du standard, en effet. Tu utilise uniquement de l'ext2 ?
Je ne sais pas si tu peux empêcher facilement la console de s'inactiver.
C'est sans aucun doute possible, au pire en modifiant le noyau.
PS: On dirait que la rumeur d'UDP de Free sur Tiscali est fondée, ton
article n'est pas visible sur le serveur de news de Free.
?
Je ne savais pas qu'un kernel panic n'était que partiel, je croyais que
tout le noyau arrêtait de tourner. Il va falloir que je me documente sur
le sujet.
C'était vrai sur les 2.2. Depuis le 2.4, le noyau peut résister à
certains panics: en gros, si un thread kernel plante, ça n'empêche pas
les autres de continuer leur boulot, sauf si les structures kernel ont
été "abimées" lors du crash auquel cas on a généralement des crashs
en cascade.
Au vu de celà, je dirais que le kernel panic a touché la partie de
gestion des bloc-device ou un driver lié.
Support IDE compilé en dur pour le contrôleur Intel PIIX3 du chipset
Triton VX avec DMA et block mode activés, rien d'expérimental il me semble.
Rien que du standard, en effet. Tu utilise uniquement de l'ext2 ?
Je ne sais pas si tu peux empêcher facilement la console de s'inactiver.
C'est sans aucun doute possible, au pire en modifiant le noyau.
PS: On dirait que la rumeur d'UDP de Free sur Tiscali est fondée, ton
article n'est pas visible sur le serveur de news de Free.
?
Je ne sais pas si tu peux empêcher facilement la console de
s'inactiver.
C'est sans aucun doute possible, au pire en modifiant le noyau.
Je n'ai pas encore cherché mais je serait étonné qu'il n'y ait pas une
option à passer au démarrage du noyau ou dans un fichier de
configuration pour régler ça.
Bonjour,
Je ne sais pas si tu peux empêcher facilement la console de
s'inactiver.
C'est sans aucun doute possible, au pire en modifiant le noyau.
Je n'ai pas encore cherché mais je serait étonné qu'il n'y ait pas une
option à passer au démarrage du noyau ou dans un fichier de
configuration pour régler ça.
Bonjour,
Je ne sais pas si tu peux empêcher facilement la console de
s'inactiver.
C'est sans aucun doute possible, au pire en modifiant le noyau.
Je n'ai pas encore cherché mais je serait étonné qu'il n'y ait pas une
option à passer au démarrage du noyau ou dans un fichier de
configuration pour régler ça.
Bonjour,
Je ne savais pas qu'un kernel panic n'était que partiel, je croyais que
tout le noyau arrêtait de tourner. Il va falloir que je me documente sur
le sujet.
C'était vrai sur les 2.2. Depuis le 2.4, le noyau peut résister à
certains panics: en gros, si un thread kernel plante, ça n'empêche pas
les autres de continuer leur boulot, sauf si les structures kernel ont
été "abimées" lors du crash auquel cas on a généralement des crashs
en cascade.
Oups, j'ai oublié de préciser la version du noyau (2.4.18 pour Pentium,
sources Debian). Honte à moi qui suis le premier à râler contre les
descriptions de problèmes manquant de précision.
PS: On dirait que la rumeur d'UDP de Free sur Tiscali est fondée, ton
article n'est pas visible sur le serveur de news de Free.
?
UDP = Usenet Death Penalty. Un allumé bien connu de fuad (tu peux aller
voir dans ce forum, on en parle) émet des annulations sauvages contre
certains contributeurs depuis le serveur de news de Tiscali et ce
dernier ne réagit pas. Par conséquent Free a décidé de refuser tous
les articles (y compris les articles de contrôle d'annulation) émis
depuis ce serveur dans le but de faire réagir Tiscali. C'est ce qu'on
appelle une UDP passive.
Je ne savais pas qu'un kernel panic n'était que partiel, je croyais que
tout le noyau arrêtait de tourner. Il va falloir que je me documente sur
le sujet.
C'était vrai sur les 2.2. Depuis le 2.4, le noyau peut résister à
certains panics: en gros, si un thread kernel plante, ça n'empêche pas
les autres de continuer leur boulot, sauf si les structures kernel ont
été "abimées" lors du crash auquel cas on a généralement des crashs
en cascade.
Oups, j'ai oublié de préciser la version du noyau (2.4.18 pour Pentium,
sources Debian). Honte à moi qui suis le premier à râler contre les
descriptions de problèmes manquant de précision.
PS: On dirait que la rumeur d'UDP de Free sur Tiscali est fondée, ton
article n'est pas visible sur le serveur de news de Free.
?
UDP = Usenet Death Penalty. Un allumé bien connu de fuad (tu peux aller
voir dans ce forum, on en parle) émet des annulations sauvages contre
certains contributeurs depuis le serveur de news de Tiscali et ce
dernier ne réagit pas. Par conséquent Free a décidé de refuser tous
les articles (y compris les articles de contrôle d'annulation) émis
depuis ce serveur dans le but de faire réagir Tiscali. C'est ce qu'on
appelle une UDP passive.
Je ne savais pas qu'un kernel panic n'était que partiel, je croyais que
tout le noyau arrêtait de tourner. Il va falloir que je me documente sur
le sujet.
C'était vrai sur les 2.2. Depuis le 2.4, le noyau peut résister à
certains panics: en gros, si un thread kernel plante, ça n'empêche pas
les autres de continuer leur boulot, sauf si les structures kernel ont
été "abimées" lors du crash auquel cas on a généralement des crashs
en cascade.
Oups, j'ai oublié de préciser la version du noyau (2.4.18 pour Pentium,
sources Debian). Honte à moi qui suis le premier à râler contre les
descriptions de problèmes manquant de précision.
PS: On dirait que la rumeur d'UDP de Free sur Tiscali est fondée, ton
article n'est pas visible sur le serveur de news de Free.
?
UDP = Usenet Death Penalty. Un allumé bien connu de fuad (tu peux aller
voir dans ce forum, on en parle) émet des annulations sauvages contre
certains contributeurs depuis le serveur de news de Tiscali et ce
dernier ne réagit pas. Par conséquent Free a décidé de refuser tous
les articles (y compris les articles de contrôle d'annulation) émis
depuis ce serveur dans le but de faire réagir Tiscali. C'est ce qu'on
appelle une UDP passive.
En y repenssant, il m'est arrivé de crasher ma passerelle, avec des
symptômes du même style, à cause d'une micro-coupure de courant.
Mon PC principal n'a pas bougé, mais ma passerelle s'est figée...
Un allumé bien connu de fuad émet des annulations sauvages contre
certains contributeurs depuis le serveur de news de Tiscali et ce
dernier ne réagit pas. Par conséquent Free a décidé de refuser tous
les articles (y compris les articles de contrôle d'annulation) émis
depuis ce serveur dans le but de faire réagir Tiscali.
D'accord. Mais je ne suis pas chez tiscali...
Et mon provider passe par le réseau de neuf-telecom, à priori...
En y repenssant, il m'est arrivé de crasher ma passerelle, avec des
symptômes du même style, à cause d'une micro-coupure de courant.
Mon PC principal n'a pas bougé, mais ma passerelle s'est figée...
Un allumé bien connu de fuad émet des annulations sauvages contre
certains contributeurs depuis le serveur de news de Tiscali et ce
dernier ne réagit pas. Par conséquent Free a décidé de refuser tous
les articles (y compris les articles de contrôle d'annulation) émis
depuis ce serveur dans le but de faire réagir Tiscali.
D'accord. Mais je ne suis pas chez tiscali...
Et mon provider passe par le réseau de neuf-telecom, à priori...
En y repenssant, il m'est arrivé de crasher ma passerelle, avec des
symptômes du même style, à cause d'une micro-coupure de courant.
Mon PC principal n'a pas bougé, mais ma passerelle s'est figée...
Un allumé bien connu de fuad émet des annulations sauvages contre
certains contributeurs depuis le serveur de news de Tiscali et ce
dernier ne réagit pas. Par conséquent Free a décidé de refuser tous
les articles (y compris les articles de contrôle d'annulation) émis
depuis ce serveur dans le but de faire réagir Tiscali.
D'accord. Mais je ne suis pas chez tiscali...
Et mon provider passe par le réseau de neuf-telecom, à priori...
Je ne savais pas qu'un kernel panic n'était que partiel, je croyais que
tout le noyau arrêtait de tourner. Il va falloir que je me documente sur
le sujet.
Il existe des firewall machine eteinte, il me semble.
Je ne savais pas qu'un kernel panic n'était que partiel, je croyais que
tout le noyau arrêtait de tourner. Il va falloir que je me documente sur
le sujet.
Il existe des firewall machine eteinte, il me semble.
Je ne savais pas qu'un kernel panic n'était que partiel, je croyais que
tout le noyau arrêtait de tourner. Il va falloir que je me documente sur
le sujet.
Il existe des firewall machine eteinte, il me semble.
Un allumé bien connu de fuad émet des annulations sauvages contre
certains contributeurs depuis le serveur de news de Tiscali et ce
dernier ne réagit pas. Par conséquent Free a décidé de refuser tous
les articles (y compris les articles de contrôle d'annulation) émis
depuis ce serveur dans le but de faire réagir Tiscali.
D'accord. Mais je ne suis pas chez tiscali...
Et mon provider passe par le réseau de neuf-telecom, à priori...
Pourtant je lis ceci dans tes en-têtes :
Path: biggoron.nerim.net!nerim.net!news.tiscali.fr!not-for-mail
X-Trace: news.tiscali.fr 1110738224 9702 62.210.158.41 (13 Mar 2005
18:23:44 GMT)
X-Complaints-To:
Ce qui montre que tes articles sont injectés dans le réseau Usenet via le
serveur de news de Tiscali. Allez, petite enquête : :)
$ host news.magic.fr
news.magic.fr is an alias for nntp.magic.fr.
nntp.magic.fr has address 62.210.158.46
nntp.magic.fr has address 62.210.158.41
nntp.magic.fr has address 62.210.158.45
Un allumé bien connu de fuad émet des annulations sauvages contre
certains contributeurs depuis le serveur de news de Tiscali et ce
dernier ne réagit pas. Par conséquent Free a décidé de refuser tous
les articles (y compris les articles de contrôle d'annulation) émis
depuis ce serveur dans le but de faire réagir Tiscali.
D'accord. Mais je ne suis pas chez tiscali...
Et mon provider passe par le réseau de neuf-telecom, à priori...
Pourtant je lis ceci dans tes en-têtes :
Path: biggoron.nerim.net!nerim.net!news.tiscali.fr!not-for-mail
X-Trace: news.tiscali.fr 1110738224 9702 62.210.158.41 (13 Mar 2005
18:23:44 GMT)
X-Complaints-To: abuse@libertysurf.fr
Ce qui montre que tes articles sont injectés dans le réseau Usenet via le
serveur de news de Tiscali. Allez, petite enquête : :)
$ host news.magic.fr
news.magic.fr is an alias for nntp.magic.fr.
nntp.magic.fr has address 62.210.158.46
nntp.magic.fr has address 62.210.158.41
nntp.magic.fr has address 62.210.158.45
Un allumé bien connu de fuad émet des annulations sauvages contre
certains contributeurs depuis le serveur de news de Tiscali et ce
dernier ne réagit pas. Par conséquent Free a décidé de refuser tous
les articles (y compris les articles de contrôle d'annulation) émis
depuis ce serveur dans le but de faire réagir Tiscali.
D'accord. Mais je ne suis pas chez tiscali...
Et mon provider passe par le réseau de neuf-telecom, à priori...
Pourtant je lis ceci dans tes en-têtes :
Path: biggoron.nerim.net!nerim.net!news.tiscali.fr!not-for-mail
X-Trace: news.tiscali.fr 1110738224 9702 62.210.158.41 (13 Mar 2005
18:23:44 GMT)
X-Complaints-To:
Ce qui montre que tes articles sont injectés dans le réseau Usenet via le
serveur de news de Tiscali. Allez, petite enquête : :)
$ host news.magic.fr
news.magic.fr is an alias for nntp.magic.fr.
nntp.magic.fr has address 62.210.158.46
nntp.magic.fr has address 62.210.158.41
nntp.magic.fr has address 62.210.158.45
Dans le message <news:d1224u$6v6$,
** tapota sur f.c.o.l.configuration :Un allumé bien connu de fuad émet des annulations sauvages contre
certains contributeurs depuis le serveur de news de Tiscali et ce
dernier ne réagit pas. Par conséquent Free a décidé de refuser tous
les articles (y compris les articles de contrôle d'annulation) émis
depuis ce serveur dans le but de faire réagir Tiscali.
D'accord. Mais je ne suis pas chez tiscali...
Et mon provider passe par le réseau de neuf-telecom, à priori...
Pourtant je lis ceci dans tes en-têtes :
Path: biggoron.nerim.net!nerim.net!news.tiscali.fr!not-for-mail
X-Trace: news.tiscali.fr 1110738224 9702 62.210.158.41 (13 Mar 2005
18:23:44 GMT)
X-Complaints-To:
Ce qui montre que tes articles sont injectés dans le réseau Usenet via le
serveur de news de Tiscali. Allez, petite enquête : :)
$ host news.magic.fr
news.magic.fr is an alias for nntp.magic.fr.
nntp.magic.fr has address 62.210.158.46
nntp.magic.fr has address 62.210.158.41
nntp.magic.fr has address 62.210.158.45
$ dig +short ppp-181.net-555.magic.fr
62.210.255.181
$ whois -T ROUTE 62.210.158.46
route: 62.210.0.0/16
descr: Tiscali France (formerly C&W/ISDNET)
origin: AS12876
mnt-by: MNT-TISCALIFR
changed: 20040824
source: RIPE
Magic = réseau Tiscali.
Dans le message <news:d1224u$6v6$1@biggoron.nerim.net>,
*Pascal@plouf* tapota sur f.c.o.l.configuration :
Un allumé bien connu de fuad émet des annulations sauvages contre
certains contributeurs depuis le serveur de news de Tiscali et ce
dernier ne réagit pas. Par conséquent Free a décidé de refuser tous
les articles (y compris les articles de contrôle d'annulation) émis
depuis ce serveur dans le but de faire réagir Tiscali.
D'accord. Mais je ne suis pas chez tiscali...
Et mon provider passe par le réseau de neuf-telecom, à priori...
Pourtant je lis ceci dans tes en-têtes :
Path: biggoron.nerim.net!nerim.net!news.tiscali.fr!not-for-mail
X-Trace: news.tiscali.fr 1110738224 9702 62.210.158.41 (13 Mar 2005
18:23:44 GMT)
X-Complaints-To: abuse@libertysurf.fr
Ce qui montre que tes articles sont injectés dans le réseau Usenet via le
serveur de news de Tiscali. Allez, petite enquête : :)
$ host news.magic.fr
news.magic.fr is an alias for nntp.magic.fr.
nntp.magic.fr has address 62.210.158.46
nntp.magic.fr has address 62.210.158.41
nntp.magic.fr has address 62.210.158.45
$ dig +short ppp-181.net-555.magic.fr
62.210.255.181
$ whois -T ROUTE 62.210.158.46
route: 62.210.0.0/16
descr: Tiscali France (formerly C&W/ISDNET)
origin: AS12876
mnt-by: MNT-TISCALIFR
changed: jerome.fleury@fr.tiscali.com 20040824
source: RIPE
Magic = réseau Tiscali.
Dans le message <news:d1224u$6v6$,
** tapota sur f.c.o.l.configuration :Un allumé bien connu de fuad émet des annulations sauvages contre
certains contributeurs depuis le serveur de news de Tiscali et ce
dernier ne réagit pas. Par conséquent Free a décidé de refuser tous
les articles (y compris les articles de contrôle d'annulation) émis
depuis ce serveur dans le but de faire réagir Tiscali.
D'accord. Mais je ne suis pas chez tiscali...
Et mon provider passe par le réseau de neuf-telecom, à priori...
Pourtant je lis ceci dans tes en-têtes :
Path: biggoron.nerim.net!nerim.net!news.tiscali.fr!not-for-mail
X-Trace: news.tiscali.fr 1110738224 9702 62.210.158.41 (13 Mar 2005
18:23:44 GMT)
X-Complaints-To:
Ce qui montre que tes articles sont injectés dans le réseau Usenet via le
serveur de news de Tiscali. Allez, petite enquête : :)
$ host news.magic.fr
news.magic.fr is an alias for nntp.magic.fr.
nntp.magic.fr has address 62.210.158.46
nntp.magic.fr has address 62.210.158.41
nntp.magic.fr has address 62.210.158.45
$ dig +short ppp-181.net-555.magic.fr
62.210.255.181
$ whois -T ROUTE 62.210.158.46
route: 62.210.0.0/16
descr: Tiscali France (formerly C&W/ISDNET)
origin: AS12876
mnt-by: MNT-TISCALIFR
changed: 20040824
source: RIPE
Magic = réseau Tiscali.
