problème de réseau franchement relou! au s'cours! (résolu)

Support Debian
#21

Et Pascal Hambourg… Merci d’avoir levé mon doute…! En faisant des recherches, je suis bien tombé sur une explication (wikipédia), mais je t’avouerai que je n’avais pas très bien compris.

Une émulation d’un lien ethernet sur une interface Firewire/IEEE 1394 (le machin concurrent de l’USB et plsu performant pour connecter des disques externes)? C’est à dire quej par ce biais là, on utilise le port physique du Firewire pour transporter des paquets IP? Je n’ai jamais croisé ce cas de figure. C’est une possibilité réçente?

Piratebab : Ben justement, l’adresse MAC qui figurait quand je faisait ifconfig me paraissait bougrement plus ressembler à une adresse MAC de carte réseau qu’avec eth0… C’est ce qui m’a mis la puce à l’oreille ce matin. Mais bon, faut que je vous mette le résultat concret de Ifconfig, pour bien voir. J’ajouterais que ça serait cohérent avec la remarque de Pascal au sujet de mon install. Faut dire aussi que quand j’ai essayer “Realtek” au lieu de Firewire, mon switch (ou ma connexion, ou mon port physique RJ45, ou dieu seul sait quoi) était planté. Ca n’aurait pas marché, de toute façon. Maintenant que ça a l’air de refonctionner (et me gonfle de pas savoir ce qui s’est passé), je pourrais plus facilement corriger l’erreur… j’espère, en tout cas.

dmon :

ifconfig eth0 inet 192.168.1.60

route add default gw 192.168.1.1

ping -c 2 192.168.1.60

ping -c 2 192.168.1.1

Je te dis ça ce soir. Interessant d’utiliser “inet” en plus du reste, en lancant la commande ifconfig. D’hab’ je fais juste ifconfig eth0. Je ne connaissais pas. Je suis bien curieux de voir ce que ça va donner. Idem pour l’option -c de ping. J’apprends des petits trucs bien utile, ici… :slightly_smiling:

Cordialement,
Chris

#22

Oui, en gros.

Non, ça existait déjà au moins depuis les noyaux 2.4.

Mais encore ? L’adresse “MAC” d’eth0 est beaucoup plus longue qu’une adresse MAC ethernet ? C’est typique d’une interface firewire.

Plutôt “ifconfig -a” pour afficher toutes les interfaces, même inactives.

#23

Okidoki.

C’est un peu space : je n’avais jamais fait gaffe lors de mes précéentes install… ou alors stupidement, je me suis posé la mauvaise question là où d’habitude je ne me la pose pas. Bref je devais être dans la lune… En tout cas, merci pour l’eclaircissement.

Je vais donc devoir :

1-laisser paraitre le ifconfig -a (interressante option, celle-là aussi), le ping -c et, probablement,
2-refaire l’installation comme il faut (sans choisir l’option “Firewire”).

Ca m’interesse, ton explication relative au Firewire/IEEE 1394. J’ai trouvé une mention dans wiki :

“Bien qu’il serve le plus souvent à connecter des disques durs ou des caméscopes pour réaliser des montages vidéo, le port FireWire peut aussi, pour des besoins ponctuels, servir à relier deux machines en réseau ; il apparaît donc dans la partie « Connexions réseau » de Windows XP et comme interface réseau sous les systèmes utilisant le noyau Linux ou UNIX.”

Apparemment, la possibilité d’utiliser le Firewire dans le cadre du réseau semble assez courante, présenté ainsi. Cependant, je ne l’ai jamais vu en “live”, pour ainsi dire. En dehors de l’existence ou non de la prise Firewire, il y a des contraintes particulières? Ce que je ne vois pas du tout, par contre, c’est comment se faire la connexion côté “élément actif” (dans ce cas. Le câble utlisé sera d’un côté “Firewire” et de l’autre “RJ45”? Et enfin, lorsqu’il s’agit non pas de faire du réseau, mais de raccorder un ou plusieurs DD externes, mettont en RAID, il faut du matériel spécial pour faire ça?

Si je lis l’article sur la page de byc.ch/scsi/scsiieee.html, je vois “On attend encore le support matériel du RAID en configuration Firewire…
Il ne viendra peut-être jamais car maintenant, le Serial SCSI (SAS) prend la première place.”

Thx,
Christian

#24

Non, ce sera firewire des deux côtés. Rien à voir avec les adaptateurs USB-ethernet qui contiennent de l’électronique pour relier un ordinateur doté d’un port USB hôte à un réseau ethernet physique.

#25

Hello,

Voilà le résultat des commandes demandées :

eth0 Lien encap:UNSPEC HWaddr 00-1E-8C-00-01-07-C5-E4-00-00-00-00-00-00-00-00
inet adr:192.168.1.60 Bcast:192.168.1.255 Masque:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1008 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:569 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:0 (0.0 b) TX bytes:71507 (69.8 KiB)

eth1 Lien encap:Ethernet HWaddr 00:1E:8C:C5:4D:44
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:14140 errors:0 dropped:12275573692 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:933172 (911.3 KiB) TX bytes:0 (0.0 b)
Interruption:185 Adresse de base:0x4000

lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:166 errors:0 dropped:0 overruns:0 frame:0
TX packets:166 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:13204 (12.8 KiB) TX bytes:13204 (12.8 KiB)

PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
From 192.168.1.60 icmp_seq=1 Destination Host Unreachable
From 192.168.1.60 icmp_seq=2 Destination Host Unreachable

— 192.168.1.1 ping statistics —
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 999ms
, pipe 2
PING 192.168.1.60 (192.168.1.60) 56(84) bytes of data.
64 bytes from 192.168.1.60: icmp_seq=1 ttl=64 time=0.014 ms
64 bytes from 192.168.1.60: icmp_seq=2 ttl=64 time=0.007 ms

— 192.168.1.60 ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.007/0.010/0.014/0.004 ms

Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

Comme vous pouvez le voir, je peux me pinguer moi-même. Je ne pingue pas la passerelle. Les routes sont ok, ayant été construites par défaut à l’installation.

Comme tu le vois, pascal, l’adresse HW de eth1 apparait comme très différente. Donc, je suppose que l’explication est bien là : mauvaise installation de ma part. j’ai plus qu’à recommencer… (bon c’est pas long et si ça marche impec’, cette fois… je vais pas me plaindre). Je n’ai pas repéré le problème, la première fois, à cause de mon soucis avec le switch (toujours inexplicable, du reste… à mon avis un simple mauvais contact). Je m’étais concentré là dessus et pas sur la configuration. Cela dit, encore merci pour l’explication relative au FireWire… Je ne l’aurais pas deviné, mouarf!

So, tu en penses quoi? Tu confirmes le problème “firewire”? Je vois que ça, perso (et vu ton explication, très claire… voilà, quoi… ca parait pas pouvoir être autre chose).

Thx,
Christian

#26

Oui, eth0 est bien l’interface firewire et eth1 est l’interface ethernet. Par contre le nombre énorme de paquets reçus “dropped” m’inquiète un peu.

Tu n’as pas normalement besoin de réinstaller le système, il devrait suffire de remplacer eth0 par eth1 dans /etc/network/interfaces.

#27

Yo,

Ok, bon j’ai changé le numéro d’eth. Pas de changement. J’ai donc réinstallé (bah… ça prends 15-20 minutes… Pas long) avec “eth1 Realtek” etc… au lieu de “eth0 firewire 1394 Ethernet device” en interface principale (avec l’avantage d’être un peu plus sûr de ce que j’ai fait).

Le hic, c’est que j’ai tjs le même résultat… Baaaaah… pffff… Cela dit - bon indice, sans doute - j’ai tjs un sacré paquet de… paquets de droppés quand je fais ifconfig. Je n’ai pas remis de copie de ifconfig, ici (il était tard hier), mais en gros, j’ai la même chose que sur ce que j’ai la même chose que la copie que j’ai posée sur la page précédemment. A quoi c’est dû, ça? Un paquet droppé, c’est un paquet refusé (c’est mal!). Donc je vois deux possibilités : soit le FW est mal configuré, sur ma LiveBox (je vais vérifier ma configuration. Je vois pas pourquoi ça bloque mais bon…), soit y a un netfilter (et y a pas lol. Par défaut, il est configuré sans règles définies), soit y aun pb physique… sur ce point j’ai quand même un doute : j’avais eu des pb à ce niveau, certes, mais ayant pratiqué des tests en branchant les câbles de façon aléatoires et même en changeant de switch, il s’avérait que ça ne venait pas de là. Quand à la carte réseau, elle fonctionne quand je suis sous Windows.

Ce qui me laisse une possibilité, pour le moment : la config de la LiveBox.

Si tu as un avis différent… ou une autre idée de test, n’hésite pas. Je suis ultrapreneur.

Thx,
Chris

#28

Je ne sais pas à quoi correspondent les paquets marqués “dropped”, mais cela se produit au niveau de la carte ou du pilote, donc je peux te dire que les firewalls du PC ou de la box n’y sont pour rien. Si le même matériel fonctionne sous Windows, cela pourrait venir du pilote.
Il y a des messages du noyau relatifs à eth1 (dmesg|grep eth1) ? Tu peux refaire un “ifconfig eth1” ?

#29

Et comment tu fais ça? Moi je ne voie pas.

Par contre je peux suggérer à des fin de test de modifier mes anciennes commandes

[code]# ifconfig eth1 inet 192.168.1.60

route add default gw 192.168.1.1

ping -c 2 192.168.1.60

ping -c 2 192.168.1.1[/code]

J’ai modifié eth0 par eth1.

#30

Et comment tu fais ça? Moi je ne voie pas.[/quote]
Avec un éditeur de texte. Quel est le problème ?

#31

yo, je t’envoie tout ça en début de soirée. Pas de pb.

Encore merci,
christian

#32

as tu lu http://forum.debian-fr.org/viewtopic.php?f=3&t=14995 ?

#33

hello (ou “helo” comme qui dirait, en langage "serveur de mail mouarf),

So, avec ifconfig et dmesg, j’ai ceci :

dmesg|grep eth1
eth1394: eth0: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
r8169: eth1: link up
NETDEV WATCHDOG: eth1: transmit timed out

ifconfig eth1:
eth1 Lien encap:Ethernet HWaddr 00:1E:8C:C5:4D:44
inet adr:192.168.1.60 Bcast:192.168.1.255 Masque:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:81604378605 overruns:0 frame:0
TX packets:0 errors:0 dropped:46 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interruption:185 Adresse de base:0x8000

Qu’est ce que tu en penses?

Piratelab : nein je n’ai pas lu. Je mate ça dès que possible (demain, donc).

Thx,
Christian

#34

J’en pense qu’il y a un problème avec le pilote. Quelle est la version du noyau ? Si c’est une 2.6.18 d’etch tu pourrais essayer une version plus récente d’etch-backports car entretemps pas mal de corrections ont été apportées au pilote r8169 pour la gestion des contrôleurs RTL8168/8111 notamment. Ou bien tu pourrais essayer d’utiliser le pilote pour Windows avec ndiswrapper, je pense que c’est ce que suggérait piratebab.

#35

Ah!

Ok… J’ai bien envie de mettre un noyau plus récent (ça ne peut pas faire de mal). Effectivement, c’est une 2.6.18. Je vais y réfléchir. Je vous dirai ce que je vous répondrai d’ici demain soir. Je vais lire le lien qu’a laissé Piratelab.

Thx,
Chris

#36

hi,

Voilà,

J’ai donc fait quelques tests supplémentaires, avant d’envisager la solution de ndiswrapper ou de l’évolution du kernel.

Si je fais un lspci, j’ai :
00:00.0 Host bridge: Intel Corporation Unknown device 29c0 (rev 02)
00:01.0 PCI bridge: Intel Corporation Unknown device 29c1 (rev 02)
00:1a.0 USB Controller: Intel Corporation Unknown device 2937 (rev 02)
00:1a.1 USB Controller: Intel Corporation Unknown device 2938 (rev 02)
00:1a.7 USB Controller: Intel Corporation Unknown device 293c (rev 02)
00:1b.0 Audio device: Intel Corporation Unknown device 293e (rev 02)
00:1c.0 PCI bridge: Intel Corporation Unknown device 2940 (rev 02)
00:1c.2 PCI bridge: Intel Corporation Unknown device 2944 (rev 02)
00:1d.0 USB Controller: Intel Corporation Unknown device 2934 (rev 02)
00:1d.1 USB Controller: Intel Corporation Unknown device 2935 (rev 02)
00:1d.2 USB Controller: Intel Corporation Unknown device 2936 (rev 02)
00:1d.3 USB Controller: Intel Corporation Unknown device 2939 (rev 02)
00:1d.7 USB Controller: Intel Corporation Unknown device 293a (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
00:1f.0 ISA bridge: Intel Corporation Unknown device 2916 (rev 02)
00:1f.2 RAID bus controller: Intel Corporation 82801HR/HO/HH (ICH8R/DO/DH) SATA RAID Controller (rev 02)
00:1f.3 SMBus: Intel Corporation Unknown device 2930 (rev 02)
01:05.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 70)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
04:00.0 VGA compatible controller: nVidia Corporation Unknown device 0402 (rev a1)

Si je fais un lsmod, pour connaitre les modules montés, j’ai :

Module Size Used by
nls_iso8859_1 9856 1
nls_cp437 11520 1
vfat 18048 1
fat 57264 1 vfat
nfs 236216 0
nfsd 256200 17
exportfs 10368 1 nfsd
lockd 67600 3 nfs,nfsd
nfs_acl 8320 2 nfs,nfsd
sunrpc 166984 13 nfs,nfsd,lockd,nfs_acl
ppdev 14088 0
parport_pc 41640 0
lp 17736 0
parport 44684 3 ppdev,parport_pc,lp
button 12192 0
ac 10376 0
battery 15496 0
dm_snapshot 20664 0
dm_mirror 25216 0
dm_mod 62800 2 dm_snapshot,dm_mirror
sbp2 28680 0
loop 20112 0
tsdev 13056 0
sg 40744 0
psmouse 44432 0
i2c_i801 13076 0
sr_mod 22436 0
serio_raw 12036 0
i2c_core 27776 1 i2c_i801
pcspkr 7808 0
cdrom 40488 1 sr_mod
eth1394 24840 0
evdev 15360 1
ext3 138512 5
jbd 65392 1 ext3
mbcache 14216 1 ext3
sd_mod 25856 9
usb_storage 87872 1
ide_core 147584 1 usb_storage
ohci1394 38216 0
ahci 25092 6
ieee1394 361976 3 sbp2,eth1394,ohci1394
r8169 36872 0
libata 106784 1 ahci
scsi_mod 153008 7 sbp2,sg,sr_mod,sd_mod,usb_storage,ahci,libata
ehci_hcd 36104 0
uhci_hcd 28696 0
thermal 20240 0
processor 38248 1 thermal
fan 9864 0
filename: /lib/modules/2.6.18-6-amd64/kernel/drivers/net/r8169.ko
author: Realtek and the Linux r8169 crew netdev@vger.kernel.org
description: RealTek RTL-8169 Gigabit Ethernet driver
license: GPL
version: 2.2LK-NAPI
vermagic: 2.6.18-6-amd64 SMP mod_unload gcc-4.1

Et si je mate dans le détail les infos relatives à la carte, via un modinfo r8169 :

depends:
alias: pci:v000010ECd00008129svsdbcsci*
alias: pci:v000010ECd00008136svsdbcsci*
alias: pci:v000010ECd00008167svsdbcsci*
alias: pci:v000010ECd00008168svsdbcsci*
alias: pci:v000010ECd00008169svsdbcsci*
alias: pci:v00001186d00004300svsdbcsci*
alias: pci:v00001259d0000C107svsdbcsci*
alias: pci:v000016ECd00000116svsdbcsci*
alias: pci:v00001737d00001032svsd00000024bcsci
srcversion: 64EBAEB8E2D2228C72B9EB9
parm: debug:Debug verbosity level (0=none, …, 16=all) (int)
parm: use_dac:Enable PCI DAC. Unsafe on 32 bit PCI slot. (int)
parm: rx_copybreak:Copy breakpoint for copy-only-tiny-frames (int)
parm: media:force phy operation. Deprecated by ethtool (8). (array of int)

si je fais un modprobe -r suivi un -a, le module descent et monte (du moins la seconde fois que je l’ai fait… la première fois, ca n’a pas marché).

lsmod|grep r8169
r8169 36872 0

Ca ne change rien. J’ai aussi essayé avec une Mandriva, mais le noyau était un 2.6.17. Toujours est-il que c’est la même chose.

Si je teste avec un liveCD, avec un System Rescue CD et en mettant une autre adresse IP:

system rescue cd.
address : 192.168.1.150. netmask 255.255.255.0

test :
ping 192.168.1.1
connect : Network is unreachable

Je vérifie le noyau:
uname -r
2.6.20.11-fd06

Donc un kernel plus réçent que le 2.6.18…
C’est dingue…

J’ai aussi changé les câbles. Même résultat. Je n’ai pas changé le switch (je peux le refaire, si besoin est, mais quand je l’ai fait la première fois, ca n’a pas changé grand-chose. Snif).

Je sèche… Si le problème vient d’un mauvais fonctionnement du module, on pourrait penser qu’avec le system Rescue CD, cela ourrait marcher, n’est ce pas? (à moins que le problème ne se répète au même niveau, ce qui parait improbable). Idem pour l’âge du kernel, puisque celui du System Rescue CD est plus récent. So What? Ca peut être un problème de firmware? Il y a un test qui pourrait me permettre de voir ça?

Je précise aussi que je n’ai pas fait le changement dans le fichier /etc/udev/rules.d/z25_persistent-net.rules, mais bon… le problème ne se situe pas là.

Je me pose une autre question. Quand je fais mon lpci, je vois :
Semiconductor Co., Ltd. RTL8111/8168B PCI
Tandis que via un lsmod, j’ai :
r8169 36872 0
(et non pas r8168b, par exemple).

Tu en penses quoi?

Thx,
Chris

#37

Hi, j’ai regardé ton lien : le problème du gars était lié à la configuration “carte wifi”. J’ai une carte ethernet.
Par contre, qu’il me faille “n’diswrapper”, on va voir. C’est possible… C’est quand même spatial, tout ça… Apparemment la R8168/9 est courante sous Nunux. Pourtant je galère.

En tout cas, merci pour la suggestion.

Thx,
Chris

#38

Bonjour,

Es-tu sur de ta config Livebox aussi ? je sais que les Freebox par exemple ne sont pde en mode routeur d’origine. Si tu te mets ta machine en config DHCP ca donne quoi ?

@+

#39

En fait, je suis déjà en dhcp, oui. Mais tu peux être en dhcp et prendre une adresse qui ne soit pas dans l’étendue dhcp de façon à avoir une ip fixe. C’est courant.

Cela dit, je vais quand même regarder. Sache toutefois que j’ai fait un dhclient quand j’ai fait le test avec le live-cd. Et en retour du dhcpdiscover, j’ai eu un z’olie dhcpoffer qui m’a renvoyé dans le barbelé. En gros, un truc type “no dhcpoffer”. C’est logique, dans la mesure où je ne peux même pas pinguer la box (ce que je peux faire avec les autres machines - je le ferai plus tard mais pour le moment, j’ai gardé une configuration qui permet le ping).

Quand à la livebox… En principe, tel quel, y a rien qui empêche la machine de pinguer. Je n’ai pas interdit la machine au niveau du FW. Quand au mode routeur, je suppose que j’aurais des difficultés à faire communiquer mes deux autres bécanes ensemble s’il y avait un pb de ce côté-là.
Mais là aussi, bien sûr, je peux (re)voir. Ca coûte rien, tu as raison.

chris

#40

Cela dit, avec le même nom de machine et la même IP (ou une autre), même machine, sous Win, ca marche impec’. A partir de là, s’il y avait une configuration intempestive, je suppose que ce serait pareil sous win, n’est ce pas? :slightly_smiling:

chris