Bonjour à tous,
Je cherche à comprendre le comportement de ce que je viens d’observer.
Deux stations sont reliées sur un commutateur.
Station A @IP 192.168.1.1/25
Station B @Ip 192.168.1.127/24

L'@IP de B est donc la broadcast du réseau pour la station A.
Cas n°1
Ping de A vers B. ça fonctionne, on observe que l'@MAC de destination de la trame ICMP request est FF:FF:FF:FF:FF:FF (ce qui parait normal)
B répond avec une trame ICMP reply et son @MAC en source.
Cas n°2
Ping de B vers A. A reçoit bien la trame ICMP request mais refuse d'y répondre. Je ne comprends pas pourquoi. Sauf s'il n'est pas autorisé de répondre à un paquet dont l'@IP source est une @IP de broadcast, mais je ne vois cette interdiction nul part dans les RFC.
Merci de m’éclairer sur ce mystère

ca veut juste rien dire une ip source de broadcast

Comment ça rien dire ?
Dans l'exemple ou B ping A, l'@IP source de l'ICMP request qui arrive à A est bien une @IP de broadcast (pour A).
Mais, si on regarde le fonctionnement d'ICMP il n’apparaît à aucun moment qu'il est fait une différence entre une @IP unicast ou une @IP broadcast.

ça a plus à voir avec IP qu'avec ICMP spécifiquement je pense

au delà de ça intuitivement on comprend bien que ça n'a aucun sens

Merci pour vos réponses.
Non c'est bien au niveau ICMP (soit couche 3++ ) que la restriction est faite.
Sur la couche 3 la décision de "routage" IP ne comporte aucune restriction et une répondre à une adresse source qu'elle soit unicast ou broadcast ne diffère pas.
Pour ce qui est de l'utilité ou du sens, je travaille dans la sécurité réseau, et je fais des recherches sur une attaque DOS avec des tempêtes de broadcast. Ou je voudrais qu'une station réponde à une adresse source broadcast pour saturer le réseau.
Je viens d'observer que le comportement n'est d’ailleurs pas le même sur une station Windows que sur une station Linux et une distribution debian qui elle va répondre au broadcast...
Résultat sur une debian:

La debian répond bien avec l'adresse de broadcast. Sur une Windows la station ne répond pas.
De ce côté la je trouve que Windows est plus sécurisé...
J'en déduis que c'est normal que je n'ai rien trouvé dans la RFC, puisqu’il n'est pas interdit de répondre à une adresse de broadcast. C'est juste que par défaut Windows le refuse.

Dans le pare-feu windows il me semble que les réponses ICMP sont désactivées.

C'est faux.
 
La documentation officielle du kernel Linux, https://www.kernel.org/doc/Document [...] sysctl.txt , indique :

Sur une Debian 8, 9 ou 10, ce réglage par défaut n'est pas modifié.
 
Si Debian répond, c'est seulement que le système considère que l'adresse IP destination, 192.168.1.127, n'est pas une adresse de broadcast pour un sous-réseau /24 . A raison.
 
J'ignore ce qu'il en est des RFC mais je peux te suggérer de lire cet article : https://en.wikipedia.org/wiki/Smurf_attack

cette entrée sysctl est pour autre chose tel que je la lis.
Ca dit que la machine ne répond pas à un ping envoyée à l'adresse ip de broadcast.
Genre ma machine est 10.0.0.5/24 et une machine envoie un ping à 10.0.0.255 alors 10.0.0.5 ne répondra pas au ping
 
Là il essaie d'envoyer un ping en mettant comme ip source une ip de broadcast pour que sa machine réponde un ping broadcast (amplification) et apparemment sa debian le fait et en plus utilise la mac de broadcast.
Donc on peut dire que le noyau linux est tout pourri
Fais ton test sur des BSD pour voir

Merci pour vos réponses

Le par-feux de toutes les stations est bien-sur désactivé

Pour Anonymous Coward :
Oui effectivement sur Linux ou bien même sur un Windows un reply à un request avec une @IP de broadcast en destination ne passe pas par défaut, et heureusement ! (ça évite justement les attaques de type "Smurf" auxquels tu faisais allusion)
D'ailleurs sur Linux lorsque l'on souhaite faire un request vers une @IP de broadcast le shell nous demande de confirmer avant d'envoyer le paquet avec un petit message qui nous dit attention vous allez potentiellement saturer la station ou le réseau .
Sur la majorité des réseaux que j'ai pu tester, il n'y a que la passerelle qui répond à un ping vers la broadcast et encore ça varie selon la marque de l'équipement (CISCO répond par défaut).

Mais là, comme le dit Je@nb nous ne sommes pas dans ce cas.
C'est un request qui est envoyé vers la station Linux avec comme @IP source une @IP qui est considéré par la station en destination comme étant la broadcast.
Pour 192.168.1.1/25, 192.168.1.127 est bien l'adresse de broadcast.
La station debian regarde donc dans sa table ARP, trouve une ligne statique 192.168.1.127=> FF:FF:FF:FF:FF:FF et donc répond avec l'@MAC de broadcast en destination (c'est ce que je voulais obtenir )
ça on peut le voir dans la capture Wireshark de mon précédent message.

Je vais essayer avec une BSD.