[Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

raleur · 28-07-2015 14:21:04

Acinis a écrit :

Je me demandais si l'UEFI gèrerait certains paramètres de connexion.

A quels paramètres de connexion penses-tu ?

Acinis a écrit :

Pour ce qui est de la compilation du driver realtek, pourquoi le résultat serait meilleur qu'avec l'installation de firmware-realtek dans les dépots nonfree ?

Ce n'est pas du tout la même chose. Comme son nom l'indique, le paquet firmware-realtek contient des firmwares, pas un pilote. Un firmware (ou "micrologiciel") est chargé par par le système hôte sur le périphérique et s'exécute directement sur celui-ci alors qu'un pilote (ou "driver") est exécuté par le processeur du système hôte, comme n'importe quel logiciel classique.

Acinis a écrit :

Pour ce qui est du noyau plus récent, il vaux mieux tenter de le compiler sous stable et essayer de l'installer tel quel sans rien changer, ou bien de passer directement à la branche testing ?

J'aurais dit en priorité d'essayer le noyau rétroporté de jessie-backports, mais il n'y en a pas encore. Entre les deux autres solutions, prends celle que tu maîtrises le mieux. Pourquoi pas une nouvelle installation en testing (voire un démarrage en live) à côté de ton système actuel juste pour tester le réseau ?

Dernière modification par raleur (28-07-2015 14:53:37)

Acinis · 10-08-2015 01:51:57

Pour les paramètres éventuellement gérés par l'UEFI, je n'avais pas d'idée précise, juste une question que je me posais.

Merci pour ces précisions, j'y vois désormais plus clair. En compilant, on forcerait debian à utiliser à tous les coups le pilote ?
- Si je compile le driver, et que pour une raison X ou Y il ne marche pas, comment revenir à la configuration actuelle ? (je me rappelle avoir installé le pilote catalyst, mais ça c'est une autre histoire...)
- ce qui me perturbe toujours beaucoup, c'est l’intermittence du problème, et le fait qu'il n'est survenu que très récemment : qu'est ce qui pourrait bien faire que un coup tout marche parfaitement et un autre coup plus rien ? Parce que ce fichu contrôleur réseau, il marchait diablement bien sous wheezy.

J'ai besoin pour septembre d'une machine stable dans son fonctionnement, donc passer en testing me parait compliqué. Un noyau de backport pourrait être la solution, mais pour cela il vas falloir attendre. D'ici là, et maintenant que j'ai le matériel approprié à portée de main, je vais faire un test en livecd, car installer à côté une autre debian me parait compliqué dans mon cas.

J'ai juste une autre question :

dmesg |grep eth0

[    0.680469] r8169 0000:03:00.0 eth0: RTL8168g/8111g at 0xffffc90000c78000, 10:c3:7b:92:3f:46, XID 0c000800 IRQ 41

[    0.680471] r8169 0000:03:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]

[   11.419072] r8169 0000:03:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168g-2.fw (-12)

[   11.429334] r8169 0000:03:00.0 eth0: link down

[   11.429359] r8169 0000:03:00.0 eth0: link down

[   11.429387] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

[  109.864608] r8169 0000:03:00.0 eth0: link down

[  110.271264] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

[  110.280878] r8169 0000:03:00.0 eth0: link down

[  110.280917] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

[  113.191396] r8169 0000:03:00.0 eth0: link up

[  113.191400] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Qu'est ce que ce "link" qui deviens prêt ? Peut-on accéder à davantage d'information à son sujet, voir intervenir manuellement dessus ? Tel que je vois, que ça bug, le "eth0:link up" ne se fait pas. Est-il possible que la procédure automatique lors du démarrage "oublie" de le faire passer en "link up" ?

Cela fait beaucoup de questions, d’interrogations, je ne sais pas si je suis très clair, mais j'aimerais bien comprendre le pourquoi du comment de mon soucis.

raleur · 10-08-2015 11:52:56

"Link", c'est la liaison ethernet physique. "Link up", cela signifie que l'interface a détecté la présence d'un port ethernet à l'autre bout du câble, que les deux ont négocié le type de liaison (vitesse, duplex) et donc que la liaison est opérationnelle et peut servir à s'échanger des trames de données. C'est géré automatiquement par le pilote et le contrôleur dès que l'interface est activée administrativement (UP), donc il n'est pas possible d'"oublier". Si l'interface n'était pas activée administrativement, il n'y aurait pas de messages "link".

Acinis a écrit :

En compilant, on forcerait debian à utiliser à tous les coups le pilote ?

Cela dépend de quelle façon le pilote externe est installé une fois compilé. Fondamentalement, ce n'est qu'un module du noyau, un fichier <module>.ko. On peut le charger manuellement avec la commande insmod <chemin/fichier>. Pour qu'il soit traité comme les modules intégrés au noyau, il faut le copier dans l'arborescence des modules sous /lib/modules/<version_noyau>/kernel/drivers/... et exécuter la commande depmod. Pour éviter que le module officiel r8169 soit aussi chargé automatiquement, il faut le mettre en "blacklist" dans un fichier /etc/modprobe.d/*.conf. Toutes ces opérations peuvent éventuellement être effectuées par le script d'installation du pilote externe (make install) ou manuellement, et sont réversibles si besoin. Pour revenir au module interne, il suffit de le déblackister et de blacklister le module externe à la place.

anonyme · 11-08-2015 01:34:35

captnfab a écrit :

* captnfab ressert une assiette de pâté de bisounours à raleur.

je peus avoir un peu de paté de bisounours moi aussi ?

ps: je suis déja trés loin ........

Acinis · 11-08-2015 16:49:34

D'accord. C'est quand même curieux, je me demande ce qui peut bien faire qu'un coup ça marche et un autre coup non. Aujourd'hui, MAJ du noyau et connexion dès le boot. J'en profite pour télécharger des .isos de stable et de testing pour voir ce que cela donne en live. Je vous dirais si il s'avère que cette MAJ à résolu le soucis, bien sûr. Il me viens une autre question : peut-on vérifier que la distribution est intègre (qu'il ne manque pas un logiciel, par exemple ?).

Merci pour les explications. Mais, vu que ce driver serait pas libre, ils ne fourniraient pas plutôt un .run ou un .deb ? A installer directement avec dpkg -i nom_du_truc.run/deb ? Si toutefois rien ne fonctionnait, je viens de penser à un truc : installer une carte réseau PCI non intégrée à la carte mère, j'en vois à une dizaine d'euros. Logiquement, il dois bien y en avoir des supportées sous linux, et peut être tant qu'à faire avec un module wi-fi (ça pourrait s'avérer utile pour ma tours un jour). J'ai bon ?

raleur · 12-08-2015 08:36:51

La plupart des cartes ethernet PCI pas trop récentes devraient être supportées par Linux.
Par contre, et ce n'est pas spécifiques aux cartes PCI, toutes les cartes wifi ne sont pas supportées nativement. Souvent il faut au mieux installer un firmware non libre, ou carrément un pilote externe plus ou moins libre et stable.

Acinis · 13-08-2015 19:35:43

Donc, si je résume, pour l'installation du driver propriétaire qui résolverait mon soucis :
- retirer le firmware
- télécharger le .ko sur le site realtek
- le copier dans /lib/modules/<version_noyau>/kernel/drivers/ et suivre la procédure que tu m'as indiquée.
- Prier pour que ça marche ?

Il me reste encore 1 jour pour réussir à télécharger l'image live de jessie... et oui, ces derniers temps quand je suis connecté, j'oscille entre 1 et 50 kio/s de débit.

raleur · 18-08-2015 11:19:29

Acinis a écrit :

- retirer le firmware

Quel firmware ?

Acinis a écrit :

- télécharger le .ko sur le site realtek

Je doute fort que Realtek fournisse un module précompilé pour chaque version, variante et architecture du noyau. Il faut plus probablement récupérer les sources dans une archive tar.gz|bz2|xz, les extraire et compiler le module pour ta version particulière du noyau.

Acinis a écrit :

- Prier pour que ça marche ?

Inefficace et superflu.

smolski · 18-08-2015 12:31:38

Acinis a écrit :

- Prier pour que ça marche ?

Debby · 18-08-2015 13:09:04

Bonjour! C’est un peu trop long à expliquer, le mieux c’est qui tu regardes cette vidéo cisco et donnes moi des nouvelles. Bonne chance !
http://www.alphorm.com/tutoriel/formati … nt-100-101

Acinis · 20-08-2015 14:17:29

Bonjour à tous,

Alors, j'ai essayé d'installer le driver propriétaire. Sur le site de realtek, j'en ai trouvé un qui semblait faire l'affaire. Je l'ai donc téléchargé. Parallèlement, j'ai trouvé sur le forum ubuntu (http://ubuntuforums.org/showthread.php?t=2224262) quelqu'un qui à un contrôleur Ethernet similaire, et la solution proposée est d'installée un .deb.... que j'ai trouvé sur le site de debian. En fait, il s'agit du même fichier que celui trouvé sur le site de realtek, mais mis en forme de .deb.

Donc, j'ai fait :

apt-get install dkms build-essential

(les headers ont été installés via les dépendances, de même que make, make-config, etc.

dpkg -i r8168-dkms_8.040.00-1_all.deb

 

L'installation s'est bien déroulée, reboot, et connection ethernet qui fonctionne. Et là :

lsmod | grep r8168

r8168                 490633  0 

dmesg | grep eth0

[    9.643806] eth0: 0xffffc90000c78000, 10:c3:7b:92:3f:46, IRQ 41

[    9.709290] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

[   21.720253] r8168: eth0: link up

[   21.720288] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Auparavant, c'était le r8169 qui était chargé. On dirait que le module venant de realtek est correctement installé. Je vais de ce pas tester pour savoir si mon problème est résolu (et j'espère que oui, parce qu'il ne me reste qu'une semaine pour le faire, après quoi je serait obligé de partir avec du windows 7 pour un an si ça marche pas :( )

Merci pour le lien Debby, je pense que je comprendrais mieux le fonctionnement du réseau après cela.

Melodie · 24-08-2015 06:08:59

Salut,

J'ai la machine dotée d'une carte Ethernet "RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller " laquelle me connecte avec le driver "realtek/r8169.ko". (Noyau 3.19.0-27) C'est sous "Ubento" Vivid, (et Trusty, et Precise avant), et la connexion fonctionne. Par contre elle fonctionne bien mieux depuis que j'ai remplacé resolvconf par openresolv. (Moi par contre, je ne sais pas si je comprendrai un jour quelque chose aux réseaux ?

)

Fais-nous savoir si la compilation a réussi et si ça résout ton problème. S'il te plaît, donne-nous le retour de:

lsmod | grep r818

Acinis · 24-08-2015 22:13:41

Salut,

Je reviens donner des nouvelles, après quelque temps de test. Internet fonctionne désormais parfaitement avec cette manipulation, merci à tous pour votre aide précieuse

Rien à redire, sortie de veille, démarrage, débit : ça marche au poil. Juste une inquiétude, si une MAJ du noyau sort dans stable, comme cela arrive souvent (sécurité ?), il faudra recommencer la manip, ou elle sera conservée, vu que je suis passé par un .deb ?

@Melodie : cette commande ne retourne rien du tout.

Mon plus gros soucis du moment est terminé, il m'en reste deux à régler :
- une imprimante récalcitrante
- des freezes de debian lors d'une lecture vidéo (pilote qui déconne pour cause de carte trop récente?)
Mais tout cela, c'est une autre histoire.... qui n'a pas sa place ici.

Acinis

Dernière modification par Acinis (24-08-2015 22:16:15)

Melodie · 24-08-2015 22:19:27

Acinis a écrit :

@Melodie : cette commande ne retourne rien du tout.

Euh et comme ça ?

lsmod | grep r818*

raleur · 25-08-2015 10:26:16

Cela ne retournera rien non plus, le nom du module étant r8168. De toute façon la question est sans objet, Acinis ayant déjà fourni les indications que le module était bien actif.

Acinis a écrit :

si une MAJ du noyau sort dans stable, comme cela arrive souvent (sécurité ?), il faudra recommencer la manip, ou elle sera conservée, vu que je suis passé par un .deb ?

Je n'ai jamais utilisé dkms, mais je pense que comme tu as utilisé un paquet source dkms la recompilation du module devrait être automatique.

Melodie · 25-08-2015 10:50:45

raleur a écrit :

Cela ne retournera rien non plus, le nom du module étant r8168. De toute façon la question est sans objet, Acinis ayant déjà fourni les indications que le module était bien actif.

Bonjour,

Pourtant chez moi cela retourne ceci:

lsmod | grep r818*

r8169                  81920  0 

mii                    16384  1 r8169

et la carte réseau de mon PC:

lspci | grep Ethernet

04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

semble être la même que la sienne. (Et ici je n'ai pas de problème de fonctionnement : Ubuntu Vivid avec le kernel courant, soit pour l'instant le 3.19.0-27).

Quelqu'un d'autre a subi des inconsistances identiques avec un matériel identique, sous Ubuntu. Il a posté ici, sur cet autre forum. J'ai d'abord suggéré de remplacer le paquet resolvconf par openresolv (suite à des expériences que j'avais eues avec ça) et ça semble avoir réglé le problème pour lui. Puis j'ai fait le rapprochement avec le fil de discussion ici.

Donc chez moi ça fonctionne tous les jours, avec un driver r8169 pour une carte RTL8111/8168/8411 : mais je ne sais pas pourquoi/comment ça fonctionne.

paskal · 25-08-2015 11:00:56

Melodie a écrit :

raleur a écrit :
Cela ne retournera rien non plus, le nom du module étant r8168. De toute façon la question est sans objet, Acinis ayant déjà fourni les indications que le module était bien actif.

Bonjour,

Pourtant chez moi cela retourne ceci:
lsmod | grep r818*
r8169 81920 0
mii 16384 1 r8169

+1

lsmod | grep r818*

r8169                  47008  0 

mii                    12675  1 r8169

raleur · 25-08-2015 11:36:54

Au temps pour moi, * signifie n'importe quel nombre de fois le motif y compris 0. Mais cette façon d'écrire une expression rationnelle se terminant par * est un peu trompeur, cela équivaut à écrire simplement "r81".

Melodie a écrit :

Donc chez moi ça fonctionne tous les jours, avec un driver r8169 pour une carte RTL8111/8168/8411 : mais je ne sais pas pourquoi/comment ça fonctionne.

Il existe dans la nature une floppée de variantes de ces contrôleurs Realtek qui ont le même nom mais ne sont pas tous bien pris en charge par le pilote libre r8169 intégré au noyau. Tu as la chance d'avoir une variante bien supportée par le pilote libre, contrairement à Acinis. Parfois il faut un noyau plus récent, parfois seul le pilote Realtek r8168 fonctionne. En tout cas je ne vois pas comment le remplacement de resolvconf par openresolv peut y changer quoi que ce soit si le pilote du noyau ne fonctionne pas correctement.

paskal · 25-08-2015 12:04:04

raleur a écrit :

Au temps pour moi, * signifie n'importe quel nombre de fois le motif y compris 0. Mais cette façon d'écrire une expression rationnelle se terminant par * est un peu trompeur, cela équivaut à écrire simplement "r81".

Curieux, effectivement.
On en apprend tous les jours.

Melodie · 25-08-2015 12:14:46

paskal a écrit :

raleur a écrit :
Au temps pour moi, * signifie n'importe quel nombre de fois le motif y compris 0. Mais cette façon d'écrire une expression rationnelle se terminant par * est un peu trompeur, cela équivaut à écrire simplement "r81".
Curieux, effectivement.
On en apprend tous les jours.

Cela fonctionne aussi comme ça,

[melodie@bento64:~]$ lsmod | grep r81

r8169                  81920  0 

mii                    16384  1 r8169

[melodie@bento64:~]$ lsmod | grep r81*

r8169                  81920  0 

mii                    16384  1 r8169

[melodie@bento64:~]$

Le '*' utilisé ainsi est un joker (il remplace "n'importe quel caractère" qui sera trouvé).

Pour le resolvconf vs openresolv, je n'ai pas dit que ça soit lié au pilote. Je pense au contraire que ça n'a rien à voir, sauf que le problème était ressemblant, du point de vue des effets.

raleur · 25-08-2015 13:48:52

Melodie a écrit :

Le '*' utilisé ainsi est un joker (il remplace "n'importe quel caractère" qui sera trouvé).

Non, le "joker" (caractère générique) dans les expressions rationnelles comme celles utilisées avec grep est le point ".".

Comme je viens de l'écrire plus haut, l'étoile "*" est un modificateur qui affecte le motif élémentaire qui précède et qui signifie "0 ou plus occurrences de ce motif".
Par exemple le motif r818* peut représenter les séquences r81 (0 fois 8), r818 (1 fois 8), r8188 (2 fois 8), r81888 (3 fois 8)...

Dernière modification par raleur (25-08-2015 13:51:52)

Acinis · 27-08-2015 17:14:16

@ Melodie : J'ai la version (rev 11) et toi la (rev 06). Sur un autre pc, j'ai la (rev 08), et j'ai le même bogue mais à une fréquence beaucoup plus faible (je dirais <1/10). ça ressemble en effet à un soucis au niveau du driver libre. Cela vaudrait le coup de tester un noyau plus récent, mais lors des tests, j'ai été dans l'incapacité de le faire. Je vois que le 4.1 LTS est arrivé dans les backports de jessie. J'ai également des problèmes de crash graphique à la lecture de vidéos, qui arrivent de temps en temps. Si ça venait à se répéter, je pense que j'installerais le noyau 4.1, et alors je pourrais voir au passage si l’Ethernet fonctionne mieux. Cela étant, j'ai pas très envie de faire du bricolage, car bientôt j'aurai uniquement internet que si je me logue sur un truc via le navigateur web; ainsi si je casse le démarrage graphique je n'ai plus de connexion, donc plus de réinstallation/réparation. Donc il me faut du stable et du solide pendant au moins un an, Debian je compte sur toi !

@raleur : probablement que linux 4.1 LTS pourrait posséder des drivers plus adaptés pour mon contrôleur, mais : ne vaux-il mieux pas attendre la sortie de stretch ? J'ai commencé à regarder les possibilités de backport, et j'ai l'impression qu'il y a beaucoup de choses à installer.... au moins le noyau, les headers, firmware free et firmware non free, les pilotes radeon. Cela ne serait pas dangeureux pour la stabilité générale de l'ensemble (simple question, vu que dans la doc ils disent d'installer "ce dont on à vraiment besoin")?

Je pense que je peut passer en résolu pour ce soucis là

Dernière modification par Acinis (27-08-2015 17:28:35)

raleur · 27-08-2015 17:54:11

Acinis a écrit :

ne vaux-il mieux pas attendre la sortie de stretch ?

Dans ce cas il va falloir s'armer de patience, car à mon avis la prochaine version stable ne sortira pas avant un an.

Acinis a écrit :

J'ai commencé à regarder les possibilités de backport, et j'ai l'impression qu'il y a beaucoup de choses à installer

J'ai regardé les dépendances du paquet linux-image-4.1* dans jessie-backports, et je n'en ai pas l'impression. Dans les versions précédentes de backports, il fallait généralement mettre à jour d'autres paquets comme initramfs-tools, mais cette fois cela ne semble pas nécessaire. Le paquet firmware-linux-free n'a pas de version dans jessie-backports, la version de firmware-linux-nonfree de jessie-backports n'est utile que pour bénéficier d'un éventuel nouveau firmware inclus dans ce paquet lié à un péripérique présent dans ta machine. Par contre la mise à jour du paquet firmware-realtek peut être utile pour ton contrôleur ethernet Realtek.

Les en-têtes du paquet linux-headers* ne sont utiles que pour recompiler un pilote externe pour le nouveau noyau, comme par exemple le pilote non libre fglrx pour les GPU Radeon. Mais tu n'es pas obligé de le faire dans un premier temps, tu peux juste installer et lancer le noyau sans interface graphique pour tester le fonctionnement du réseau en ligne de commande.

Acinis · 27-08-2015 20:52:01

Dans ce cas il va falloir s'armer de patience, car à mon avis la prochaine version stable ne sortira pas avant un an.

Hum, dans ce cas je vais essayer le nouveau noyau dès ce soir, tant que j'ai un accès réseau correct pour réparer si besoin était. Je vais installer le noyau, et firmware linux nonfree pour MAJ le microcode de ma carte graphique, ainsi que firmware realtek. Bilan tout à l'heure.

Compte rendu :

Bon, j'ai installé le noyau 4.1, avec firmware-nonfree et firmware-realtek. J'ai également purgé le driver propriétaire, afin de recharger le module ethernet libre ainsi qu'expliqué dans le LISEZMOI du paquet du driver. Le nouveau noyau démarre très vite, c'est une vraie fusée. En revanche, pas de correction du problème ethernet (j'ai vérifié le correct chargement du module libre). J'ai du télécharger les headers du 4.1 pour réinstaller le pilote propriétaire, ce qui à de nouveau résolu le problème.

Par contre, j'ai eu un crash graphique en écoutant de la musique. Cependant, il semble que xorg aie redémarré (écran tout noir, avec tout de figé, puis avec quelques secondes retour sur l'écran de login). Ceci est moins grave que ceux que j'avais avant, ou j'avais un kernel panic, et obligé de redémarrer en force (les touches magiques ne marchaient pas). maintenant, je vais éprouver un petit peut le système (lecture de vidéos HQ, jeux) pour voir ce qu'il se passe.

Dernière modification par Acinis (28-08-2015 00:11:22)

Acinis · 28-08-2015 19:07:58

De nouveau un crash graphique, en étant sur internet, j'ai du redémarrer avec les touches magiques. Afficher une image, ou lire une vidéo cause le problème.

J'ai ouvert un nouveau sujet pour ce soucis graphique, dans la section matériel.

Je ne trouve pas comment mettre celui-ci en résolu, comment fait-on s'il vous plaît ?

Dernière modification par Acinis (28-08-2015 19:37:36)

Debian-facile

#26 28-07-2015 14:21:04

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#27 10-08-2015 01:51:57

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#28 10-08-2015 11:52:56

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#29 11-08-2015 01:34:35

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#30 11-08-2015 16:49:34

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#31 12-08-2015 08:36:51

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#32 13-08-2015 19:35:43

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#33 18-08-2015 11:19:29

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#34 18-08-2015 12:31:38

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#35 18-08-2015 13:09:04

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#36 20-08-2015 14:17:29

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#37 24-08-2015 06:08:59

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#38 24-08-2015 22:13:41

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#39 24-08-2015 22:19:27

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#40 25-08-2015 10:26:16

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#41 25-08-2015 10:50:45

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#42 25-08-2015 11:00:56

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#43 25-08-2015 11:36:54

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#44 25-08-2015 12:04:04

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#45 25-08-2015 12:14:46

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#46 25-08-2015 13:48:52

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#47 27-08-2015 17:14:16

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#48 27-08-2015 17:54:11

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#49 27-08-2015 20:52:01

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

#50 28-08-2015 19:07:58

Re : [Résolu] Problème ethernet, carte réseau = RTL8111/8168/8411

Pied de page des forums