Skip to main content
Bonjour.

Je suis ammener a devoir utiliser l'adresse broadcast (192.168.1.255), mais celle ci ne redistribue pas aux differents appareils.

Quand par exemple, je ping la broadcast, voici le résultat après 5 minutes :



WARNING: pinging broadcast address

PING 192.168.1.255 (192.168.1.255) 56(84) bytes of data.

^C--- 192.168.1.255 ping statistics ---

290 packets transmitted, 0 received, 100% packet loss, time 295940ms



Rien, aucun retour, aucun packet reçu.

Savez vous comment activé la broadcast, ou du moins, la faire fonctionner ?

Merci !
Personne ? 😓
il faut peut-être utiliser une autre adresse ou faire une recherche sur le net.
Merci de ta réponse.

Il y a, de base, deux adresse broadcast. Voici le résultat du ping des deux :



/home > ping -b 192.168.1.255

WARNING: pinging broadcast address

PING 192.168.1.255 (192.168.1.255) 56(84) bytes of data.

--- 192.168.1.255 ping statistics ---

25 packets transmitted, 0 received, 100% packet loss, time 32122ms



/home > ping -b 255.255.255.255

WARNING: pinging broadcast address

PING 255.255.255.255 (255.255.255.255) 56(84) bytes of data.

--- 255.255.255.255 ping statistics ---

24 packets transmitted, 0 received, 100% packet loss, time 29072ms



Aucun des deux n'a de réponse, même pas de mon PC.
je suis arrivé au m^me constat que vous et je ne peut pas aidez plus.



peut-être qu'un collaborateur pourra aidez.
Je pense que la plupart des OS (PC et embarqué) sont configurés pour ignorer les packets ICMP ECHO en broadcast... Aucune machine ne va répondre, en principe...



Si vous voulez qu'une machine Linux réponde (jusqu'au prochain reboot):

echo "0" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
Et du coup, comment les configurer pour répondre ? (définitivement)
Vous devez alors changer le paramètre sur chaque machine via sysctl. L'endroit où se trouve le fichier de configuration dépend de la distribution...



Vous devrez le faire sur chaque machine linux, et de toute manière les autres machines (windows, routeur, cameras etc..) ne répondront pas. De toute façon, il y a de bonnes raisons (de sécurité) pour lesquelles la réponse au broadcast ICMP ECHO a été désactivée, notamment pour éviter de congestionner le réseau si quelqu'un envoie un flood ping en broadcast...



Mais au fait, qu'essayez-vous de faire exactement ? Car bien entendu, du broadcast en UDP fonctionne, c'est seulement la réponse au ICMP ECHO en broadcast qui est désactivée...
https://translate.google.be/translate?hl=fr&sl=en&u=https://www.howtogeek.com/howto/windows-vista/allow-pings-icmp-echo-request-through-your-windows-vista-firewall/&prev=search



https://www.google.be/search?client=firefox&hs=xNa&q=icmp+echo+windows&oq=icmp+echo+windows&gs_l=psy-ab.3..0i19k1j0i22i30i19k1l3.2831.5439.0.5680.8.8.0.0.0.0.232.985.5j2j1.8.0....0...1.1.64.psy-ab..0.8.968...0j0i22i30k1.pz7b__9P8Uo
@tapedur: cela n'a rien avoir avec le fait de répondre à des requêtes sur ll'adresse de *broadcast*.
Merci de vos réponses.

L'un de mes buts (le plus simple a expliquer ici) est un petit script shell pour connaitres les Ips qui répondent sur le réseau. D'apres ce que je sais sur l'UDP, celui ci, possedant l'Ip de l'envoyeur, pourrais envoyer une réponse ? Une sorte de "signe de vie" ?



J'utilise pour cette tache, pour l'instant, un autre algo, qui "ping" chaque ip potentiel (192.168.1.81-255] )

Mais il y a plusieurs problemes:

- Pour ne pas faire duré inutilement les tentatives, elles ont un timeout de 1 seconde. Ce qui est long, pour 255 possibilités (dont une dixaines répond) Donc pres de 250 secondes de tests.

- Une seconde, ce n'est pas toujours suffisent (les smatphones par exemple, ne répondent que rarement à l'appel)
Je vois... Le problème c'est que ping utilise des packets ICMP et pas UDP, et le stack IP ignore (par défaut) les demandes ICMP ECHO sur l'adresse broadcast.



Je pense que vous devriez arriver à la même chose avec la commande suivante:

for i in {1..256}; do ping -c 1 192.168.1.$i > /dev/null &; done



Celle-ci va envoyer les requêtes (unicast) en parallèle, sans attendre la réponse, donc. Ensuite, vous pouvez utiliser la commande arp pour voir les adresses des machines qui ont répondu. Même les machines qui ne répondent pas au ping auront répondu à la requête ARP qui permet de trouver l'adresse MAC d'une machine avec une adresse IP donnée (celle utilisée dans le ping)



Sinon voyez éventuellement la commande arping (qui utilise des packets ICMP ARP) qui fonctionnerait peut-être en broadcast (mais je ne l'ai jamais utilisée)
Le problemes, c'est qu'avec un peu de chipo, on a vite fait être "invisible".

Pourquoi ?

Car on se base sur une "liste" qu'a faite le réseau.

Et avec quelques cases a chocher, ou quelques commandes bash, et pouf, aussi invisible qu'un avion espion américain.
"arp" utilise une liste donné par le réseau. Donc, si une personne le veux, elle peut être non visible par cette commande (et seul 2 appareils sur les 12 connectés le sont).

Alors que si, par exemple, je me connecte au routeur (192.168.1.1), les 12 sont présent, et apparaissent en une ou deux secondes maximum.
la commande arp affiche simplement les adresses IP pour lesquelles l'adresse MAC est connue. Cette liste ne se remplit pour une adresse IP donnée que si on essaye d'atteindre cette adresse IP à partir de la machine sur lasuelle on consulte la liste. Si une machine ne répond pas à la requête ARP, alors elle ne peut pas communiquer en IP avec les autres machines.



Avez-vous lancé la commande ping sur les 255 adresses avant ?
Pourtant, (un exemple parmis plusieurs) mon imprimente (192.168.1.129) n'est pas dans la liste ARP, alors que je peux y imprimer, ping, etc
Il est pour moi *impossible* qui si vous faites ping 192.168.1.129 depuis une machine, et que vous affichez *ensuite* la liste arp sur cette même machine, l'adresse 192.168.1.129 ne s'y trouve pas (que 192.168.1.129 ignore ou pas le ping). Le protocole arp est la base du routage intra-subnet en IPv4.



Une machine ne sera pas présente dans la table si elle se trouve sur un subnet différent, si les échanges avec cette machine se font seulement en broadcast ou multicast, ou bien encore si un autre protocole est utilisé (IPv6, ...)
Pourtant c'est bien le cas. D'ailleur, dans la partie connzction réseau sur xUbuntu, je peux cocher des cases. Dont:

- broadcast (décocher)

- defaut (cocher)

- arp (décocher)

- ... (tous décocher)
Dans ce cas, ça veut dire que j'ai encore des choses à apprendre... En espérant que quelqu'un viendra donner une explication ici. Moi je laisse ma place.



https://www.tummy.com/articles/networking-basics-how-arp-works/
Enfin, je pense que c'est ce que c'est ce que sa veux dire (on sait jamais avec moi ^^)



Wake on LAN:

- Default

- Phy

- Unicast

- Multicast

- Ignore

- Broadcast

- Arp

- Magic
Non, ça ça permet de choisir sur la réception de quel type de message l'ordinateur doit sortir du mode veille. Ca n'a rien avoir avec le fait de les ignorer...
Haa, bah voila alors 😃

Par contre, pourquoi arp ne detecte meme pas mon propre PC ? ni mon imprimante ? (qui marche) ? (malgré un ping réussi)
Pour le propre PC, c'est normal, il n'a pas besoin d'ARP pour connaître sa propre adresse MAC. Pour l'imprimante, si vous faites un ping sur l'adresse IPv4 et qu'après ça l'adresse n'apparait pas dans la table ARP du PC à partir duquel vous avez fait le ping, je n'ai pas d'explication...
A moins que le PC et l'imprimante soient sur des subnets différents, comme je l'ai dit plus haut...

Commenter


Conditions d'utilisation