Réseau eth0 DHCP, IP statique et problèmes de négociation automatique

Contexte

J’utilise un serveur Ubuntu le 14.04, qui est actuellement à jour. Je n’ai qu’un seul périphérique réseau connecté. Lorsque j’utilise mon câble Ethernet et que je le connecte du mur à mon ordinateur portable (sous Windows 7), le protocole DHCP est résolu sans problème.

Problème

Lorsque je connecte mon câble Ethernet du mur à mon serveur (sous Ubuntu) et que je mets mon serveur sous tension, le serveur DHCP n’atsortingbue pas d’adresse IP à mon serveur. Cependant, lorsque je connecte le cordon de mon serveur à mon ordinateur portable à l’aide de la connexion Ethernet des ordinateurs portables pour se connecter via ma connexion Wifi, le serveur obtiendra une adresse IP de DHCP via l’ordinateur portable. Enfin, après avoir reçu une adresse IP de la connexion d’un ordinateur portable, j’utilise les commandes suivantes, puis DHCP fonctionne lorsque le cordon est connecté du mur au serveur:

sudo dhclient -r sudo dhclient -v eth0 

La prochaine fois que je redémarre le serveur via sudo shutdown -r now le serveur ne pourra plus obtenir d’adresse IP de DHCP avec le cordon du mur au serveur.

Notez que lorsque j’atsortingbue une adresse statique dans le fichier /etc/network/interfaces , le réseau ne lui atsortingbue pas l’adresse IP et l’interface est inactive.

Question

Existe-t-il un moyen de résoudre le problème rencontré avec mon réseau, qui ne parvient pas à détecter le serveur DHCP lorsque je le met sous tension?

Si vous avez besoin de plus d’informations s’il vous plaît faites le moi savoir.

Information additionnelle

dhclient avant de se connecter à un ordinateur portable

 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x********) DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x********) DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6 (xid=0x********) ... No DHCPOFFERS received No working leases in persistent database - sleeping. 

dhclient avec serveur connecté à un ordinateur portable

 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x*********) DHCPREQUEST of 192.168.137.233 on eth0 to 255.255.255.255 port 67 (xid=0x*********) DHCPOFFER of 192.168.137.233 from 192.168.137.1 DHCPACK of 192.168.137.233 from 192.168.137.1 bound to 192.168.137.233 -- renewal in 275 seconds. ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:22:64:23:7c:da inet addr:192.168.137.233 Bcast:192.168.137.255 Mask:255.255.255.0 inet6 addr: fe80::222:64ff:fe23:7cda/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Mesortingc:1 RX packets:28265 errors:0 dropped:0 overruns:0 frame:0 TX packets:2781 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4655957 (4.6 MB) TX bytes:415144 (415.1 KB) 

dhclient après que le DHCP et le cordon du portable soient reconnectés du mur au serveur

 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x********) DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8 (xid=0x********) DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15 (xid=0x********) DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11 (xid=0x********) DHCPREQUEST of 192.168.1.126 on eth0 to 255.255.255.255 port 67 (xid=0x*******) DHCPOFFER of 192.168.1.126 from 192.168.1.254 DHCPACK of 192.168.1.126 from 192.168.1.154 bound to 192.168.1.126 -- renewal in 41950 second. ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:22:64:23:7c:da inet addr:192.168.1.126 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::222:64ff:fe23:7cda/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Mesortingc:1 RX packets:33438 errors:0 dropped:0 overruns:0 frame:0 TX packets:3391 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:5245215 (5.2 MB) TX bytes:550462 (550.4 KB) 

interface réseau (lshw)

 sudo lshw -class network *-network description: Ethernet interface product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller vendor: Realtek Semiconductor Co., Ltd. physical id: 0 bus info: pci@0000:02:00.0 logical name: eth0 version: 02 serial: 00:22:64:23:7c:da size: 100Mbit/s capacity: 1Gbit/s width: 64 bits clock: 33MHz capabilities: pm msi pciexpress msix vpd bus_master cap_list rom ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full ip=192.168.1.82 latency=0 link=yes multicast=yes port=MII speed=100Mbit/s resources: irq:42 ioport:e800(size=256) memory:febff000-febfffff memory:fdff0000-fdffffff memory:febc0000-febdffff 

Mettre à jour:

Mon fichier /etc/network/interfaces est en tant que tel

 auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp 

J’ai trouvé une solution temporaire qui semble fonctionner, mais je ne voudrais pas que ce soit ma solution si nous pouvons résoudre ce problème. J’ai changé le fichier d’interface comme si

 auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp pre-up ifconfig $IFACE up pre-up mii-tool -R 

Cela (je crois) indiquerait à l’interface de se réinitialiser et pour une raison quelconque, cela permettrait au DHCP de résoudre comme il se doit. Comme je l’ai dit, il doit y avoir un correctif réel en dehors de celui-ci.

Solution:

Grâce à la réponse de Fabbys, j’ai pu proposer une solution plus viable avec laquelle je peux vivre.

Ouvrez / etc / network / interfaces et configurez l’interface Ethernet de l’une des manières suivantes:

DHCP

 auto eth0 iface eth0 inet dhcp pre-up ifconfig $IFACE up pre-up ethtool -s $IFACE speed 100 duplex full autoneg off 

Statique

 auto eth0 iface eth0 inet static post-up ethtool -s $IFACE speed 100 duplex full autoneg off address xxxx #Internal IP netmask 255.255.255.0 gateway xxxy #Gateway IP dns-nameservers 8.8.8.8 #Google DNS 

J’espère que cela aidera quelqu’un d’autre à l’avenir.

Comme indiqué dans la discussion, désactivez la négociation automatique sur le serveur et réglez la vitesse du réseau sur le niveau maximal que la carte d’interface réseau (NIC) peut gérer.

Commencez avec 10 Mbits / s, en semi-duplex et passez à 10 Mb / s FD, 100 Mb / s HD, … jusqu’à ce que le problème se pose. Ensuite, descendez d’un cran et laissez-le à cette vitesse.

Commencez par installer ethtool (s’il est déjà installé, vous recevrez simplement un avertissement indiquant que la dernière version est déjà installée)

 sudo apt-get install ethtool 

À présent:

  1. Tapez la commande suivante (et testez les un par un)

     sudo ethtool --change eth0 speed xxx duplex yyy autoneg off 

    où xxx = 10 , 100 ou 1000 et yyy = half ou full .

    Alors commencez avec 10 half , 10 full , 100 half , …

  2. Faites un ifconfig pour vérifier si vous avez une adresse IP.

  3. Retournez à 1 jusqu’à ce qu’il cesse de fonctionner et utilisez les valeurs précédentes qui fonctionnaient toujours pour:

  4. Pour rendre la modification permanente , exécutez la commande suivante:

     sudo nano /etc/network/interfaces 

    et tapez à la section de pre-up :

     pre-up /usr/sbin/ethtool --change eth0 speed xxx duplex yyy autoneg off 

OH MAN FACEPALM (facepalm pour moi alors que j’avais pensé à cette seconde place au lieu de première comme j’aurais dû, c’est presque toujours la chose la plus simple qui puisse vous faire tourner en rond avec la technologie, hein?)

(déplacé au sumt car c’est probablement le problème, mais a laissé l’autre contenu ci-dessous pour référence).

Si vous utilisez le même câble pour connecter votre serveur à votre ordinateur portable, vous êtes votre serveur au mur, C’EST PROBABLEMENT LE PROBLÈME! !! (Encore une fois, c’est plus moi qui me reproche d’avoir manqué ce premier et d’y penser seulement en second. Je ne voulais pas être dur à dire si c’est comme ça que ça sonne)

Vous utilisez 2 types de fils différents …

Référence: https://www.computercablestore.com/straight-through-crossover-and-rollover-wiring

Le premier est un câble Ethernet droit utilisé pour les commutateurs et les routeurs vers les ordinateurs clients

La deuxième est un câble croisé: ils sont utilisés pour les connexions entre machines et sont physiquement câblés différemment!

Donc, si ces câbles fonctionnent entre votre serveur et votre ordinateur portable sans commutateur ni routeur entre les 2 (la connexion WiFi ne compte pas du tout ici), ce câble doit être un croisement.

Procurez-vous un câble droit direct et connectez-vous du routeur au serveur pour voir ce qui se passe.

D’après mon expérience, les problèmes informatiques se résument au plus simple des problèmes omis. Certains routeurs et commutateurs sont “intelligents” et peuvent essayer de faire des ajustements internes lorsque vous utilisez un câble incorrect (câble croisé) de sorte que vous puissiez toujours l’utiliser pour connecter la machine, mais vous ne pourrez jamais vous en fier à cela. problème.

Euh en fait cela ressemble à un problème de routeur. Par exemple, j’ai FiOS et dans le routeur, je peux consulter les parameters réseau et voir où il relie les segments WiFi et Wired séparément au serveur DHCP. Ainsi, si quelque chose devait arriver à ce paramètre, je pourrais me retrouver avec ce que vous avez. Dans ce cas, vous ne pouvez plus obtenir d’adresse IP sur le réseau filaire, car elle n’est pas connectée au réseau «domestique» exécutant le serveur DHCP, mais vous pouvez utiliser le Wi-Fi car ce dernier est toujours connecté au réseau «domestique» du routeur. Vous pouvez soit essayer de regarder à travers les parameters avancés de votre routeur, soit le plus souvent si vous avez un trombone et qu’il y a un bouton-poussoir de réinitialisation que vous pouvez rechercher en usine. ).

De plus, votre ordinateur portable reçoit une adresse IP via WiFi uniquement. Si vous avez une machine et qu’elle a à la fois un adaptateur filaire et une connexion Wi-Fi et que vous avez une connexion Wi-Fi et twigz un fil même si cela ne fonctionne pas, votre machine surfera quand même correctement sur Internet. port filaire tout à fait.

Votre “solution” fonctionne parce que vous demandez une adresse IP via l’adaptateur Wifi pour ordinateur portable.

En lisant plus ici, je remarque également qu’il s’agit peut-être d’une fonctionnalité de sécurité MAC que vous avez activée sur le routeur … Cela signifie que si l’adresse MAC de votre carte réseau ne figure pas dans la liste des clients autorisés, votre routeur refuserait de lui atsortingbuer une adresse. Vous pouvez “résoudre ce problème en passant d’abord par l’ordinateur portable qui est sur la liste et une fois que vous obtenez une adresse de cette façon, lorsque vous vous reconnectez au mur et envoyez une autre demande, le contrôle MAC peut être ignoré puisqu’il vous l’a déjà déjà indiqué. et à moins que votre serveur ne soit temporairement considéré comme un client de confiance, je voudrais également vérifier la sécurité MAC que vous avez activée dans le routeur.

Je ne dis pas qu’il est impossible que votre serveur DHCP de routeurs ait un problème étrange, mais ce serait SOO SUPER RARE. Je ne peux pas vous dire à quel point il est rare.