Comment modifier le comportement de l'adresse de diffusion globale (255.255.255.255) sous Windows?

Comportement désiré

Lorsqu'une application envoie un paquet à l'adresse IP de diffusion globale 255.255.255.255, je souhaite que le paquet soit envoyé à l'adresse de diffusion globale Ethernet ( ff:ff:ff:ff:ff:ff), sur toutes les interfaces.

Sur Linux et probablement sur d'autres systèmes d'exploitation, cela semble fonctionner. Windows XP et Windows 7 présentent des comportements différents à ce sujet, et aucun comportement n'est souhaitable dans ma situation.

Comportement de Windows XP

Le paquet sera envoyé correctement à la première interface réseau (l'ordre des interfaces est spécifié dans "Connexions réseau / Paramètres avancés / avancés"). Il sera également envoyé aux autres interfaces.

Tout va bien jusqu'à présent. Le problème est que, lors de l'envoi aux autres interfaces, l'adresse source du paquet de diffusion est l'adresse IP de la première interface. Par exemple, imaginez cette configuration réseau (l'ordre est important):

Adaptateur 1: adresse IP 192.168.0.1
Adaptateur 2: adresse IP 10.0.0.1
Adaptateur 3: adresse IP 172.17.0.1

Maintenant, si j'envoie un paquet de diffusion, les paquets suivants seront envoyés (avec les adresses IP source et de destination):

Sur l'adaptateur 1: 192.168.0.1=>255.255.255.255
Sur l'adaptateur 2: 192.168.0.1=>255.255.255.255
Sur l'adaptateur 3: 192.168.0.1=>255.255.255.255

En pratique, les applications utilisant des paquets de diffusion ne fonctionneront sur aucune autre interface que l'adaptateur 1. À mon avis, il s'agit d'un bogue flagrant dans la pile TCP / IP de Windows XP.

Comportement de Windows 7

La modification de l'ordre de l'interface réseau ne semble pas avoir d'effet sur Windows 7. Au lieu de cela, la diffusion semble être contrôlée par la table de routage IP.

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0   10.202.254.254       10.202.1.2    286
          0.0.0.0          0.0.0.0      192.168.0.1      192.168.0.3     10
       10.202.0.0      255.255.0.0         On-link        10.202.1.2    286
       10.202.1.2  255.255.255.255         On-link        10.202.1.2    286
   10.202.255.255  255.255.255.255         On-link        10.202.1.2    286
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.0.0    255.255.255.0         On-link       192.168.0.3    266
      192.168.0.3  255.255.255.255         On-link       192.168.0.3    266
    192.168.0.255  255.255.255.255         On-link       192.168.0.3    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link       192.168.0.3    266
        224.0.0.0        240.0.0.0         On-link        10.202.1.2    286
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link       192.168.0.3    266
  255.255.255.255  255.255.255.255         On-link        10.202.1.2    286
===========================================================================

Voir les 255.255.255.255itinéraires? Oui, ils contrôlent les paquets de diffusion. Dans cette situation, les paquets de diffusion seront envoyés via le 192.168.0.3car il a la métrique inférieure ... mais pas vers les autres interfaces.

Vous pouvez changer l'interface par laquelle les paquets de diffusion globale seront envoyés très facilement (il suffit d'ajouter une 255.255.255.255route persistante avec une métrique faible). Mais peu importe vos efforts, les paquets de diffusion ne seront envoyés que sur une seule interface, pas tous comme j'aimerais qu'il le fasse.

Conclusion

Windows 7 envoie uniquement des paquets de diffusion à une seule interface. Vous pouvez choisir lequel, mais ce n'est pas le point ici.
Windows XP envoie des paquets de diffusion à toutes les interfaces, mais il les envoie uniquement comme prévu à une interface, ce qui en pratique est équivalent au comportement de Windows 7.

Le but

Je veux changer cette prise en charge de la diffusion IP globale dans Windows (de préférence Windows 7) une fois pour toutes. Bien sûr, la meilleure façon serait d'avoir une sorte de changement de configuration pris en charge (hack de registre ou similaire), mais je suis ouvert à toutes les suggestions.

Des idées?

— Etienne Dechamps
source

Qu'utilisez-vous pour générer ces émissions. Je ne peux pas faire que ma pile XP fasse autre chose que des diffusions dirigées. soit 10.202.255.255 dans votre cas.

— Scott Lundberg

Pouvez-vous référencer un RFC ou un autre document qui indique le comportement correct que vous décrivez? Bien que je convienne que c'est le comportement souhaité, pour l'appeler comportement correct, il faut faire référence à une spécification qui définit ce qui est correct. Se pourrait-il que l'implémentation de routage spécifique soit laissée au fournisseur (Microsoft dans ce cas)?

— Jason R. Coombs

Scott Lundberg: de nombreuses applications (notamment des jeux) enverront une diffusion mondiale. Vous pouvez en générer en utilisant netcat: "nc -v -u 255.255.255.255 5000" par exemple.

— Etienne Dechamps

Jason R. Coombs: en effet, j'ai peut-être eu un mauvais choix de mots. J'aurais dû utiliser un "comportement souhaitable". Je ne pense pas qu'il existe un RFC pour cela, mais je peux me tromper.

— Etienne Dechamps

Envoyez-vous un paquet TCP ou UDP? Selon cela, cela compte social.msdn.microsoft.com/Forums/en/peertopeer/thread/… .

— Nissan Fan

Réponses:

Non pas que je veuille défendre Microsoft, mais après avoir lu les RFC suivants qui tentent de définir le fonctionnement des diffusions, je ne pense pas que Microsoft viole nécessairement les RFC. OMI, le problème devrait être résolu au niveau de l'application (c'est-à-dire des diffusions dirigées, non globales) qui atteindra les routes appropriées dans la table de routage et ne sera envoyé qu'à partir de l'interface correcte pour ce réseau IP.

Ils déclarent tous les deux qu'aucune norme n'est définie pour les émissions. Il mentionne également en 919 qu'une interface physique spécifique doit être sélectionnée pour la diffusion. Dans le cas d'une machine multi-hébergée, multi-NIC générant la diffusion, je ne pense pas que ce soit clairement indiqué ce qui devrait arriver. Les diffusions ne sont jamais censées être transmises par les routeurs d'une interface à l'autre, donc la machine Windows est-elle un routeur ou non dans ce cas?
S'il agit comme un routeur, tout hôte répondant à la diffusion avec une adresse IP incorrecte pour ce réseau (adaptateurs 2 et 3 dans votre exemple) doit renvoyer le paquet à l'adresse Ethernet des adaptateurs 2 et 3 en réponse à l'adaptateur. L'adresse IP de 1 et l'hôte Windows doivent l'acheminer vers l'interface appropriée.
Cela semble déroutant ... mais je ne peux pas penser à une meilleure façon de formuler cela

Et enfin, RFC 919 dit spécifiquement de RFC 919

Étant donné que nous supposons que le problème a déjà été résolu au niveau de la couche liaison de données, un hôte IP souhaitant
envoyer une diffusion locale ou une diffusion dirigée n'a qu'à
spécifier l'adresse de destination appropriée et envoyer le datagramme comme d'
habitude. Tout algorithme sophistiqué ne doit résider que dans des passerelles.

Une lecture qui suggérerait que l'adresse IP source n'est pas pertinente pour une diffusion.

Étant donné que chaque application semble gérer les émissions différemment, je pense que c'est là que réside la responsabilité. Par exemple. nbtstatenvoie des diffusions dirigées sur des machines multi-cartes réseau, tandis que les jeux peuvent utiliser des diffusions mondiales.
Bref, l'application doit être réparée, pas l'OS dans ce cas ...

EDIT: Voici un lien pour les mêmes circonstances, mais sous Linux. Le noyau linux le gère en n'envoyant qu'un seul paquet par l'interface par défaut (NIC A dans cet exemple). Ils recommandent que l'application énumère les NIC et envoie une diffusion dirigée sur chaque NIC. Lien

— Scott Lundberg
source

Je ne comprends pas la relation entre le paragraphe que vous citez du RFC 919 et l'adresse source. Il me semble évident qu'il est toujours faux d'envoyer un paquet IP sur une interface avec l'adresse source d'une autre interface, quelle que soit la nature de diffusion / monodiffusion du paquet. Je veux dire, vous ne pouvez pas raisonnablement dire "l'adresse IP source n'est pas pertinente pour une diffusion", bien sûr qu'elle l'est! Sinon, comment les candidatures devraient-elles savoir qui a envoyé la diffusion?

— Etienne Dechamps

"Il mentionne également dans 919 qu'une interface physique spécifique devrait être sélectionnée pour la diffusion." Où? "L'adresse 255.255.255.255 indique une diffusion sur un réseau matériel local" (RFC919 7.)? Dans ce cas, je ne suis respectueusement pas d'accord. Nous discutons de ce qu'il faut faire avec les émissions au niveau de l'hôte, pas au niveau du réseau. En outre, il est dit juste en dessous qu'un hôte peut "diffuser à tous ses voisins immédiats en utilisant 255.255.255.255". Tous ses voisins immédiats. Pas "tous les voisins sur une interface réseau spécifique".

— Etienne Dechamps

"Les applications ne se soucient pas de l'interface qui a envoyé la diffusion. Il leur suffit d'y répondre." Huh ... ils doivent aussi envoyer des émissions, pas seulement y répondre. Prenons le cas d'un navigateur de serveur de jeux LAN. Il envoie des paquets de diffusion pour découvrir les serveurs de jeux sur le réseau. Si les paquets de diffusion ne sont pas envoyés à toutes les interfaces, le navigateur du serveur de jeux n'affichera pas les serveurs de jeux accessibles via ces interfaces. En d'autres termes, l'échec épique.

— Etienne Dechamps

"Je ne suis pas sûr, mais je pense que le système d'exploitation voit la demande 255.255.255.255 et dit qu'il doit envoyer cela sur toutes les interfaces (pour trouver tous les voisins immédiats), mais cela a été demandé à partir d'une application spécifique, liée à un IP spécifique (peut être par défaut en fonction de la métrique). " Je suis d'accord. Cela ne signifie pas que c'est la bonne chose à faire. À mon avis, cela viole complètement le principe de la moindre surprise du point de vue du développeur de l'application, qui s'attend simplement à ce que le paquet soit envoyé à tout le monde sur toutes les interfaces.

— Etienne Dechamps

Je ne sais pas ce que vous entendez par doublon. Les RFC interdisent spécifiquement le transfert de paquets de diffusion. Il ne devrait y avoir qu'un seul paquet envoyé, ce qui est, je pense, tout le nœud de notre discussion. Si le système d'exploitation devait faire ce que vous dites, il devrait en fait générer 9 paquets au total (3 pour chaque interface) car la couche IP devrait générer trois paquets avec des IP source distinctes (un pour chaque carte réseau sur la couche 3), puis chaque carte réseau devrait envoyer ces informations sur Ethernet (couche 2). S'il y avait des routes entre les réseaux, vous obtenez 3 réponses en retour! Lequel a raison?

— Scott Lundberg

Enfin, je l'ai résolu par programme. J'ai écrit un très petit logiciel appelé WinIPBroadcast qui s'occupe de relayer les trames de diffusion vers toutes les interfaces.

Cela fonctionne en utilisant un fait intéressant: il est possible de recevoir des paquets de diffusion globale générés localement lors de l'écoute sur l'adresse de bouclage (127.0.0.1). WinIPBroadcast écoute l'adresse locale pour toutes les diffusions à l'aide de sockets RAW, puis pour chaque paquet de diffusion, il les relaie vers toutes les interfaces sauf celle préférée.

— Etienne Dechamps
source

Comme la pile Windows est un fork de la pile BSD, je suis curieux de savoir si BSD présente le même comportement.

— 2011

Votre logiciel ne fonctionne pas. The program can't start becuase api-ms-win-core-rtlsupport-l1-2-0.dll is missing from your computer.. Bonne chance pour trouver ça .dllsur Google.

— Alex G

@AlexG: c'est bizarre, je pensais avoir résolu ce problème via github.com/dechamps/WinIPBroadcast/commit/… . Êtes-vous sûr que vous utilisez la dernière version (1.6)? N'hésitez pas à déposer un bug sur github.com/dechamps/WinIPBroadcast/issues et je vais y jeter un œil.

— Etienne Dechamps