Négociation et full-duplex fixe

Question plus particulièrement à TG :

Il y a très longtemps, dans une vie antérieure et un monde extérieur, tu nous avais fait un résumé très instructif sur l’historique de l’ethernet. Tu terminais sur l’arrivée du full duplex et la négociation automatique. Justement, j’ai une question à ce sujet : si j’ai un certain nombre de machines (Mac, PC, routeur et imprimantes) sur un switch, certaines configurées en 100BT full-duplex fixe et d’autres en négociation automatique, est-ce que je vais avoir un problème de perte de temps en négociations ou pas ? Bref, un côté étant en full-duplex fixe, est-ce que l’autre va perdre du temps à lui poser la question à chaque fois ?

À propos, on pourrait peut-être utilement mettre ton bref « article » dans cette rubrique labo, non ? Ce serait dommage de ne pas le mettre à disposition ici, il était clair et facile à comprendre. Je l’ai gardé et il serait instantané d’en faire un message. Je peux te l’envoyer en mp, si tu ne l’as plus.

hr, concernant la première partie de ton post, la réponse est simple : non. L'autonégociation a lieu au démarrage lors du branchement des appareils entre eux (le démarrage tenant lieu de débranchage/rebranchement virtuels, la négo a lieu aussi à cette occasion). Et elle a lieu entre les appareils reliés directement, c'est à dire dans ton cas entre les machines et le switch. La perte de temps est donc infiniment petite et se déroule à un moment où on ne se sert pas des engins en pratique.

Pour la suite, j'allais te dire de le poster toi-même mais envoie-le moi en mp. J'aimerais bien relire avant

L'avais sauvé aussi l'article quand ça a commencé à sentir le roussi des bûchers de l'inquisition.

Ah ben, c'est carrément un fan club !

TG a écrit:

La perte de temps est donc infiniment petite et se déroule à un moment où on ne se sert pas des engins en pratique.

Ah bon, alors ça va, parce que sur les imprimantes et le routeur, je ne sais pas régler ça.

TG a écrit:

Pour la suite, j'allais te dire de le poster toi-même mais envoie-le moi en mp. J'aimerais bien relire avant

J’ai essayé mais ça reste dans la boîte d’envoi, pas dans les envoyés. Faut que tu l’aies lu pour que ça change de boîte ?

hr a écrit:

ça reste dans la boîte d’envoi, pas dans les envoyés. Faut que tu l’aies lu pour que ça change de boîte ?

Oui. Je viens de le faire.

Dans la même série, une autre question tordue, mais j’explique d’abord ce que j’ai compris (ou cru) pour savoir si je ne suis pas enduit d’erreur déjà au départ.

Pour configurer l’adresse IP d’un poste, on a le choix entre laisser l’adresse vide en la laissant être définie par le routeur, c’est à dire par le serveur DHCP du routeur (sur le mac, dans les préférences réseau, option Configurer IPv4 : Via DHCP).

Par défaut, quand le poste se déclare que le réseau, le DHCP lui attribue une adresse IP arbitraire qui pourra éventuellement ne pas être identique d’une connexion à l’autre.
Cet automatisme est très commode pour un portable qui pourra se trouver une adresse valable sur n’importe quel réseau inconnu muni d’un routeur.

Si on préfère que chaque poste ait toujours une adresse précise définie une fois pour toutes, on indique au routeur l’adresse physique de la carte ethernet du poste (toujours sur le mac, ID ethernet dans l’onglet Ethernet) et l’adresse ethernet qu’on désire lui associer. Quand le poste se déclare sur le réseau, le DHCP l’identifie par son ID et lui attribue l’adresse IP qui lui correspond.

Parfait, parfait, si le routeur est en route (haha) au moment où le poste se déclare, tout va bien. Mais il peut arriver que le poste démarre avant que le DHCP ne soit en mesure de lui causer et là, le poste s’attribue une adresse à la gomme et un masque de sous-réseau incompatible qui fait qu’il va se causer à lui tout seul croyant être seul au monde alors que ça grouille autour de lui.

On a alors une autre option possible qui consiste à attribuer « à la main » une adresse fixe à la machine, ainsi qu’un masque et une adresse de routeur (option Manuellement de Configurer IPv4). Dans ce cas, l’adresse est la bonne même si le routeur est hs au moment où le poste se connecte et tout est censé se passer correctement lors du retour à la normale.

Il y a aussi une option intermédiaire avec l’adresse fixe tout en utilisant le DHCP pour le reste (Utilisation de DHCP avec une adresse fixe). Je ne sais pas trop quel intérêt, sauf si le serveur DHCP peut avoir changé d’une connexion à l’autre, peut-être. Je ne sais pas.

Donc, j’avais une question.

Pourquoi diable ce bougre d’animal de routeur, de temps en temps, est-il incapable de reconnaître un poste avec une adresse fixe ? Pourtant ce n’est pas l’adresse physique (l’ID) qui risque d’avoir changé ! Quand ça coince, parfois le fait d’arrêter le réseau sur le poste (que ce soit un mac ou un PC) puis de le rétablir, remet les yeux du serveur en face des trous et tout re-fonctionne, mais ce n’est pas toujours le cas et il est arrivé que j’en vienne à finir par redémarrer le routeur et le poste pour arriver à les faire se causer entre eux. Pénible. Qu’est-ce qui peut bien provoquer ça ?

Ça arrive par vagues, puis plus de problèmes pendant longtemps. Le tout manuel est plus défavorable que le manuel + DHCP (que le poste soit mac, pc windows ou linux, ce qui me fait soupçonner le routeur de berlue temporaire intermittente) et le tout DHCP est le plus favorable, mais les changements d’adresse m’embêtent.

hr a écrit:

Dans la même série, une autre question tordue, mais j’explique d’abord ce que j’ai compris (ou cru) pour savoir si je ne suis pas enduit d’erreur déjà au départ.

Pour configurer l’adresse IP d’un poste, on a le choix entre laisser l’adresse vide en la laissant être définie par le routeur, c’est à dire par le serveur DHCP du routeur (sur le mac, dans les préférences réseau, option Configurer IPv4 : Via DHCP).

Oui. A ceci près que le serveur DHCP peut être ailleurs que dans le routeur.
C'est l'occasion de préciser qu'un serveur, c'est une application, pas une machine.

hr a écrit:

Par défaut, quand le poste se déclare que le réseau, le DHCP lui attribue une adresse IP arbitraire qui pourra éventuellement ne pas être identique d’une connexion à l’autre.
Cet automatisme est très commode pour un portable qui pourra se trouver une adresse valable sur n’importe quel réseau inconnu muni d’un routeur.

Certains serveurs DHCP savent réserver d'un jour sur l'autre une même adresse IP pour une même machine (une même adresse MAC). Ils gardent ça dans une table bien au chaud. Ils ne renouvellent les associations que lorsque toutes les adresses IP ont déjà été attribuées dans sa vie de serveur et qu'une nouvelle adresse MAC se présente ; il faut bien attribuer une "vieille" adresse IP au nouveau.
D'autres serveurs DHCP, au contraire, savent renouveler le bail (on parle bien de bail DHCP) en plein vol : la machine change alors d'adresse IP comme ça, clac, sans préavis (on sait bien que les propriétaires font ce qu'ils veulent).
La table de correspondance MAC-IP est conservée en mémoire. Les machines aussi maintiennent une telle table appelée cache DHCP.
Tape arp -a dans le Terminal pour voir la table de ta machine.

hr a écrit:

Si on préfère que chaque poste ait toujours une adresse précise définie une fois pour toutes, on indique au routeur l’adresse physique de la carte ethernet du poste (toujours sur le mac, ID ethernet dans l’onglet Ethernet) et l’adresse ethernet qu’on désire lui associer. Quand le poste se déclare sur le réseau, le DHCP l’identifie par son ID et lui attribue l’adresse IP qui lui correspond.

On a donc ici nourri la table à la main. Pour éviter les conflits, la plupart des serveurs DHCP prévoient de définir une plage fonctionnant par attribution manuelle et une autre, disjointe, fonctionnant selon la méthode automatique conventionnelle.

hr a écrit:

Parfait, parfait, si le routeur est en route (haha) au moment où le poste se déclare, tout va bien. Mais il peut arriver que le poste démarre avant que le DHCP ne soit en mesure de lui causer et là, le poste s’attribue une adresse à la gomme et un masque de sous-réseau incompatible qui fait qu’il va se causer à lui tout seul croyant être seul au monde alors que ça grouille autour de lui.

Dans le monde Mac, si la machine ne trouve pas de serveur DHCP, passé un certain délai elle tente sa chance avec Bonjour/Rendezvous/Zeroconf. C'est un mécanisme ou tout ordinateur isolé s'érige en organisateur Bonjour et va orchestrer les attributions d'adresses des futurs arrivant sur un mode différents de DHCP mais visant le même objectif. Comme ça, les appareils (certaines imprimantes, NAS ou autres savent causer Zeroconf) peuvent se causer sans l'aide d'une instance centrale préexistante.
Mais bon, ça ne marche pas toujours très bien.

hr a écrit:

On a alors une autre option possible qui consiste à attribuer « à la main » une adresse fixe à la machine, ainsi qu’un masque et une adresse de routeur (option Manuellement de Configurer IPv4). Dans ce cas, l’adresse est la bonne même si le routeur est hs au moment où le poste se connecte et tout est censé se passer correctement lors du retour à la normale.

On peut même arrêter ainsi le serveur DHCP. Ça empêche les "invités" de venir squatter le réseau (sauf pour ceux dont le niveau de maîtrise est suffisant).

hr a écrit:

Il y a aussi une option intermédiaire avec l’adresse fixe tout en utilisant le DHCP pour le reste (Utilisation de DHCP avec une adresse fixe). Je ne sais pas trop quel intérêt, sauf si le serveur DHCP peut avoir changé d’une connexion à l’autre, peut-être. Je ne sais pas.

L'utilité est de centraliser sur une seule machine (le routeur) la déclaration des serveurs DNS et de figer les adresses IP internes. Avoir une adresse fixe interne est nécessaire pour les machines qui hébergent un serveur Web, par exemple, accessible de l'extérieur (il faut bien que le mécanisme de serveur virtuel du routeur sache ou envoyer les requêtes. Encore qu'on peut imaginer un mécanisme défini sur adresse MAC, le routeur se servant alors de sa table arp pour finir la mise en correspondance).

hr a écrit:

Pourquoi diable ce bougre d’animal de routeur, de temps en temps, est-il incapable de reconnaître un poste avec une adresse fixe ?

Il peut y avoir plusieurs raisons.

D'abord, le routeur est un petit ordinateur. On lui en demande de plus en plus : serveur DHCP, routage, firewall, serveur virtuel, filtre Web, log, proxy DNS... Ça fait beaucoup pour un petit (souvent) processeur. Parfois, ça plante.

Ensuite, si on place des adresses fixes dans un champ DHCP, c'est sympa d'en informer le routeur :



Dans cet exemple, le DHCP attribuera des adresses automatiquement de 192.168.128.130 à 192.168.128.150, soit 21 adresses, pas plus. Il acceptera l'adresse 192.168.128.120 sans être capable de l'attribuer lui-même.

Mais qu'une machine se présente avec l'adresse 192.168.128.140 qu'il est capable d'attribuer lui-même, ça, il risque de ne pas forcément aimer. Même si la majorité du temps ça va marcher.

Autre source de caca : la présence de plusieurs serveurs DHCP. Surtout que la plupart du temps, ils sont réglés avec pratiquement les mêmes paramètres par défaut.

Qu'est ce qui peut bien embraquer un serveur DHCP sans qu'on le sache ?
Une Box. Un Linux. Un point d'accès WiFi (une borne Airport). Un NAS. Un modem. Bref, il n'y a pas que les routeurs.
On peut trouver ça dans la doc de chaque appareil.

Espérons que la source de tes soucis est quelque part là-dedans.

TG a écrit:

Oui. A ceci près que le serveur DHCP peut être ailleurs que dans le routeur.
C'est l'occasion de préciser qu'un serveur, c'est une application, pas une machine.

Oui, effectivement, je généralisais bêtement mon cas dans lequel le routeur est d’ailleurs lui-même dans le modem.

TG a écrit:

On a donc ici nourri la table à la main.

Oui, c’est ce que j’ai fait.

TG a écrit:

Pour éviter les conflits, la plupart des serveurs DHCP prévoient de définir une plage fonctionnant par attribution manuelle et une autre, disjointe, fonctionnant selon la méthode automatique conventionnelle.

Ça a l’air d’être le cas chez moi, les « visiteurs » pouvant se connecter sans problème.

TG a écrit:

Dans le monde Mac, si la machine ne trouve pas de serveur DHCP, passé un certain délai elle tente sa chance avec Bonjour/Rendezvous/Zeroconf. C'est un mécanisme ou tout ordinateur isolé s'érige en organisateur Bonjour et va orchestrer les attributions d'adresses des futurs arrivant sur un mode différents de DHCP mais visant le même objectif. Comme ça, les appareils (certaines imprimantes, NAS ou autres savent causer Zeroconf) peuvent se causer sans l'aide d'une instance centrale préexistante.
Mais bon, ça ne marche pas toujours très bien.

Si je comprends bien, ça pourrait expliquer que parfois, même sans DHCP (qui est dans le routeur pas encore initialisé), je me retrouve avec une adresse compatible si des macs machines ont leur adresse correcte sur le réseau ? Ah bon, très bien, mais si le DHCP une fois réveillé trouve un mac avec son ID et une adresse qui ne correspond pas à ce qu’il a dans sa table, ça ne doit pas lui plaire.

TG a écrit:

Comme ça, les appareils (certaines imprimantes, NAS ou autres savent causer Zeroconf) peuvent se causer sans l'aide d'une instance centrale préexistante.
Mais bon, ça ne marche pas toujours très bien.

Je verrai ça quand j’aurai ma nouvelle imprimante qui est bonjour.

TG a écrit:

On peut même arrêter ainsi le serveur DHCP. Ça empêche les "invités" de venir squatter le réseau (sauf pour ceux dont le niveau de maîtrise est suffisant).

En modifiant leur ID ? À propos l’ID et l’adresse MAC, c’est bien la même chose, non ?

TG a écrit:

hr a écrit:

Il y a aussi une option intermédiaire avec l’adresse fixe tout en utilisant le DHCP pour le reste (Utilisation de DHCP avec une adresse fixe). Je ne sais pas trop quel intérêt

L'utilité est de centraliser sur une seule machine (le routeur) la déclaration des serveurs DNS et de figer les adresses IP internes.

Oui, je te suis, mais je me demandais pourquoi faire la différence entre tout manuel et IP manuelle avec le reste défini par le DHCP ?

hr a écrit:

Pourquoi diable ce bougre d’animal de routeur, de temps en temps, est-il incapable de reconnaître un poste avec une adresse fixe ?

Il peut y avoir plusieurs raisons.

D'abord, le routeur est un petit ordinateur. On lui en demande de plus en plus : serveur DHCP, routage, firewall, serveur virtuel, filtre Web, log, proxy DNS... Ça fait beaucoup pour un petit (souvent) processeur. Parfois, ça plante.

TG a écrit:

Ensuite, si on place des adresses fixes dans un champ DHCP, c'est sympa d'en informer le routeur

Je vais voir si je peux faire ça.

TG a écrit:

Mais qu'une machine se présente avec l'adresse 192.168.128.140 qu'il est capable d'attribuer lui-même, ça, il risque de ne pas forcément aimer. Même si la majorité du temps ça va marcher.

Mais si le poste est configuré avec une adresse fixe et que la table du DHCP correspond, ça ne devrait pas poser problème, si ? Le fait qu’on impose une adresse au DHCP, même si c’est ce qu’il aurait fait lui-même, lui pose peut-être problème ?

TG a écrit:

Autre source de caca : la présence de plusieurs serveurs DHCP. Surtout que la plupart du temps, ils sont réglés avec pratiquement les mêmes paramètres par défaut.

Bon, dans mon cas je ne crois pas. Le pc linux a bien un démon dhcdbd mais je ne sais pas ce que c’est, je ne pense pas que ce soit un DHCP. DHC data base demon ? hum…

D’ailleurs il vient de se passer un problème encore plus étonnant. J’ai démarré le linux à partir de son mode d’hibernation (il démarre très vite et se retrouve dans l’état exact dans lequel il se trouvait). Tout va bien, il commence même à faire marcher la radio internet qui était en route au moment de la mise en hibernation, puis plus d’internet. Je vérifie et il se retrouve avec une adresse à la gomme par défaut, exactement comme les macs quand ils ont le problème (il y a aussi bonjour sur linux). Je désactive/réactive l’interface et il retrouve immédiatement son adresse correcte 10.0.0.17 que lui attribue le DHCP (là, il est configuré en DHCP pur, pas d’adresse manuelle).
J’ai refait un essai dans des conditions identiques, pas de problème cette fois. C’est vraiment aléatoire.
Décidément, c’est le DHCP qui doit dérailler de temps en temps.

TG a écrit:

Espérons que la source de tes soucis est quelque part là-dedans.

En tout cas merci beaucoup pour ton aide.

hr a écrit:

Si je comprends bien, ça pourrait expliquer que parfois, même sans DHCP (qui est dans le routeur pas encore initialisé), je me retrouve avec une adresse compatible si des macs machines ont leur adresse correcte sur le réseau ? Ah bon, très bien, mais si le DHCP une fois réveillé trouve un mac avec son ID et une adresse qui ne correspond pas à ce qu’il a dans sa table, ça ne doit pas lui plaire.

Ça n'a pas à lui plaire ou à ne pas lui plaire. Il fait son boulot et il la ferme. Un serveur DHCP attribue une adresse à qui le demande mais ne fait rien de force. Si l'ordinateur, content d'avoir enfin obtenu une adresse par un autre moyen ne lui demande rien, le serveur DHCP lui foutra la paix.

Mais pour lever ton angoisse, saches qu'on peut avoir plusieurs adresses IP sur une même interface avec une même adresse MAC (prends soin d'écrire en majuscules MAC quand il est question d'adresses Ethernet et Mac quand il est question d'ordinateur Apple : avec mac, tu fous la confusion dans les esprits). On peut en avoir une par DHCP, une par Bonjour, une fixe, etc... il suffit de dupliquer l'interface Ethernet dans les préférences systèmes et d'attribuer à chaque occurrence des réglages différents.
Et même sans ça : en activant Bonjour via le partage iTunes ou iPhoto ou via iChat, on se retrouve avec une adresse Bonjour en plus de l'adresse "normale" obtenue par les réglages.
Idem en activant le partage de connexion.

hr a écrit:

TG a écrit:

On peut même arrêter ainsi le serveur DHCP. Ça empêche les "invités" de venir squatter le réseau (sauf pour ceux dont le niveau de maîtrise est suffisant).

En modifiant leur ID ? À propos l’ID et l’adresse MAC, c’est bien la même chose, non ?

Je ne sais pas de quel ID tu causes. Ça n'existe pas.
DHCP est un mécanisme pour attribuer une adresse IP à qui le demande. Le mécanisme prévoit aussi de renseigner le demandeur sur l'adresse de la passerelle (la porte vers l'internet) et l'adresse des serveurs DNS, minimum syndical pour permettre à l'utilisateur de communiquer.
Si tu arrêtes le serveur DHCP, il faudra que les ordinateurs soient configurés à la main, c'est à dire que les renseignements concernant l'adresse IP, la passerelle et les DNS soient remplis par le propriétaire.
DHCP, c'est juste un mécanisme qui fait le boulot à ta place.

hr a écrit:

pourquoi faire la différence entre tout manuel et IP manuelle avec le reste défini par le DHCP ?

Parce que ça te fait plaisir. C'est une possibilité, tu en fais ce que tu veux. Par exemple, tu peux souhaiter garder la souplesse du DHCP pour ce qui concerne les paramètres de sortie (passerelle et DNS) mais maîtriser les adresses IP des machines.
Ça te permet ainsi, par exemple, d'arrêter ton modem-routeur pour isoler ton installation sans nuire pour autant aux capacités d'échange interne. Ou de passer d'un routeur à un autre sans avoir à tout reconfigurer. Il faut te dire que les mécanismes ont été conçus pour permettre de fournir des réponses à des cas de figure extrêmement variés. A la maison, on se contente d'un ou deux cas de figure différents tout en disposant de toutes les options, ce qui peut en effet conduire à se poser des questions.

hr a écrit:

Mais si le poste est configuré avec une adresse fixe et que la table du DHCP correspond, ça ne devrait pas poser problème, si ? Le fait qu’on impose une adresse au DHCP, même si c’est ce qu’il aurait fait lui-même, lui pose peut-être problème ?

Ça ne pose pas obligatoirement problème mais il y a possibilité dans un tel schéma que le serveur DHCP attribue à une machine une adresse IP flottante (attribuée par lui) déjà attribuée à la main à une autre machine. Et ça, c'est caca.

hr a écrit:

D’ailleurs il vient de se passer un problème encore plus étonnant. J’ai démarré le linux à partir de son mode d’hibernation (il démarre très vite et se retrouve dans l’état exact dans lequel il se trouvait). Tout va bien, il commence même à faire marcher la radio internet qui était en route au moment de la mise en hibernation, puis plus d’internet.

Ça peut provenir de la durée du bail DHCP : s'il est plus court que le temps que l'ordinateur a passé en sommeil, à son réveil l'adresse IP qu'il utilisait a pu être réattribuée. Idéalement, utilise des baux de plusieurs jours.

hr a écrit:

Décidément, c’est le DHCP qui doit dérailler de temps en temps.

Pour que les choses se passent bien, il faudrait qu'un ordinateur sortant de sommeil abandonne son adresse précédente et signale au réseau son souhait de s'en voir attribuer une nouvelle. Pour ça, il faut que la machine cause très bien avec l'OS. Et que les programmeurs y aient pensé. Mais ce sont de vrais branleurs.
En utilisant un bail (lease time dans la copie d'écran que j'ai mise àa disposistion plus haut) plus long, l'adresse sera réservée plus longtemps avant d'être à nouveau considérée comme disponible.
Typiquement, on règle la durée du bail sur un temps plus long que l'absence typique la plus longue dont peut faire l'objet un ordinateur (veille, déplacement, vacances...). On peut aussi utiliser des baux de durée infinie mais dans ce cas le cache du serveur va se polluer avec toutes les adresses MAC de passage (si c'est le cas chez toi. C'est rare en Ethernet mais fréquent en WiFi).

Bref, la plupart du temps, c'est surtout un mauvais ensemble de réglages qui fait défaillir le bidule.

TG a écrit:

Si l'ordinateur, content d'avoir enfin obtenu une adresse par un autre moyen ne lui demande rien, le serveur DHCP lui foutra la paix.

Ah, mais le problème est que parfois du coup le routeur ne le voit plus alors qu’il a bien une adresse compatible (définie en fixe) et que celle-ci n’a été attribuée à personne d’autre par le routeur. Qui plus est elle correspond à la table du DHCP.

TG a écrit:

Mais pour lever ton angoisse, saches qu'on peut avoir plusieurs adresses IP sur une même interface avec une même adresse MAC […] il suffit de dupliquer l'interface Ethernet dans les préférences systèmes et d'attribuer à chaque occurrence des réglages différents.

Suis-je bête ! Un jour j’ai eu besoin d’une seconde adresse et j’ai ajouté une carte réseau… Je n’avais pas acheté la carte pour ça, juste récupérée sur un PC, ça marchait mais évidemment c’était inutile.

TG a écrit:

Je ne sais pas de quel ID tu causes. Ça n'existe pas.

C’est comme ça que ça s’appelle dans les préf. réseau, onglet ethernet : ID Ethernet : 00:03:91:87:04:7a

TG a écrit:

[…]Si tu arrêtes le serveur DHCP, il faudra que les ordinateurs soient configurés à la main, c'est à dire que les renseignements concernant l'adresse IP, la passerelle et les DNS soient remplis par le propriétaire. DHCP, c'est juste un mécanisme qui fait le boulot à ta place.

Oui, là je te suis.

TG a écrit:

Ça ne pose pas obligatoirement problème mais il y a possibilité dans un tel schéma que le serveur DHCP attribue à une machine une adresse IP flottante (attribuée par lui) déjà attribuée à la main à une autre machine. Et ça, c'est caca.

Bon, vu le nombre astronomique de machine sur mon réseau, je peux affirmer que j'ai pu vérifier qu'on n'était pas tombé dans ce cas. Si ç'avait été le cas, j'imagine bien la panade, en effet !

TG a écrit:

Ça peut provenir de la durée du bail DHCP : s'il est plus court que le temps que l'ordinateur a passé en sommeil, à son réveil l'adresse IP qu'il utilisait a pu être réattribuée.

Réattribuée non, comme je l'ai dit, j'ai vérifié, mais il semble effectivement que le temps y fasse quelque chose. Je vais essayer de regarder de ce côté-là.

TG a écrit:

Pour que les choses se passent bien, il faudrait qu'un ordinateur sortant de sommeil abandonne son adresse précédente et signale au réseau son souhait de s'en voir attribuer une nouvelle.

Ah oui ! Ça c'est peut-être bien une des sources de problèmes, pour le pc linux en tout cas, puisque le problème apparaît en sortant d'hibernation, c'est à dire que la machine se remet en route pour se placer exactement dans son état d'avant l'arrêt complet. Si le bail est fichu, problèmes possibles.

TG a écrit:

On peut aussi utiliser des baux de durée infinie mais dans ce cas le cache du serveur va se polluer avec toutes les adresses MAC de passage (si c'est le cas chez toi. C'est rare en Ethernet mais fréquent en WiFi).

Ah, c'est justement le cas, ils sont en infini. Bon, le temps de baux n'est donc pas le problème.

TG a écrit:

Bref, la plupart du temps, c'est surtout un mauvais ensemble de réglages qui fait défaillir le bidule.

Bon, juste là, depuis hier ça ne bloque plus nulle part. Toujours dur de trouver quand c'est aléatoire.

--------
j’ai modifié une citation qui s’emmêlait avec une autre.

hr a écrit:

il a bien une adresse compatible (définie en fixe) et que […] elle correspond à la table du DHCP.

Ouaih, ben ça, c'est plus un problème qu'une solution. Si tu attribues des adresses manuellement, il vaut mieux qu'elles soient en dehors de la plage gérée par le serveur DHCP.

Je répète :

TG a écrit:

Dans cet exemple, le DHCP attribuera des adresses automatiquement de 192.168.128.130 à 192.168.128.150, soit 21 adresses, pas plus. Il acceptera l'adresse 192.168.128.120 sans être capable de l'attribuer lui-même.

Mais qu'une machine se présente avec l'adresse 192.168.128.140 qu'il est capable d'attribuer lui-même, ça, il risque de ne pas forcément aimer. Même si la majorité du temps ça va marcher.

TG a écrit:

Si tu attribues des adresses manuellement, il vaut mieux qu'elles soient en dehors de la plage gérée par le serveur DHCP.

et

TG a écrit:

Mais qu'une machine se présente avec l'adresse 192.168.128.140 qu'il est capable d'attribuer lui-même, ça, il risque de ne pas forcément aimer. Même si la majorité du temps ça va marcher.

Dans ce que tu disais, je n’avais pas compris que le conflit pouvait aussi venir d’une config. manuelle avec une entrée DHCP alors même que les adresses MAC de la machine et de la table correspondaient. Je pensais que le conflit n’existait que si la table contenait une adresse IP correspondant à une autre MAC que celle de la machine connectée, d’où mon erreur.

J’ai donc vidé ma table DHCP, tout mis en manuel sur les machines et défini une plage DHCP hors de mes adresses fixes, en prévision des portables de passage. Par défaut elle était de 10.0.0.1 à 10.0.0.254, donc fatalement mes adresses fixes tombaient dans cette plage. J’en ai profité pour comprendre comment on définissait la plage, ce que j’ignorais.
Je vais peut-être finir par avoir une configuration propre…

Merci pour toutes ces explications !

Excellent !
De la profusion — d'options — naît la confusion.
Mon réseau est lui aussi réglé de la sorte : tout — absolument tout— réglé en manuel sur les postes sédentaires (c'est à dire les machines habituées à être là, portable et NDS compris) et un DHCP d'accueil pour les nomades (au sens de machines invitées, de passage). Ce qui fait que je ne souffre jamais des sautes d'humeur éventuelles du DHCP et que les — rares — visiteurs munis d'une machine peuvent quand même se connecter... après que je leur aies communiqué le SSID et le mot de passe WiFi.

Tout cela devrait t'aider à avoir une installation plus stable et plus fiable.