Multicast non reçu suivant IP sur un même réseau

Support Debian
#1

Bonjour à tous,

j’avais fait un paquet coucou (cf cr fil) qui diffusait un texte en ulticast. Bon, sur un réseau 10.0.0.0/8, la machine 10.0.1.92 diffuse son IP sur 225.0.0.37:2012

Sur une même machine,

si je met laisse l’adresse DHCP 10.0.0.38 ou 10.0.1. ça marche bien

boole:~# ifconfig | grep -A 1 eth0 eth0 Link encap:Ethernet HWaddr 00:19:d1:01:dd:ea inet adr:10.0.0.34 Bcast:10.255.255.255 Masque:255.0.0.0 boole:~# ecoute 10.0.1.92 boole:~# pascal:~# ifconfig | grep eth0 -A 1 eth0 Link encap:Ethernet HWaddr 00:23:7d:1b:f1:56 inet adr:10.0.2.3 Bcast:10.255.255.255 Masque:255.0.0.0 pascal:~# ecoute 10.0.1.92 pascal:~# mais si je force l’adresse à 10.210.0.?? (car il y a des collisions du fait de machines avec des IPs mises en fixe par les utilisateurs), ça coince

lie:~# ifconfig | grep -A 1 eth0 eth0 Link encap:Ethernet HWaddr 00:01:6c:56:72:f9 inet adr:10.210.0.96 Bcast:10.255.255.255 Masque:255.0.0.0 lie:~# ecoute
alors que les connexions se font parfaitement (je fais ces tests en direct par ssh sur les machines). Si quelqu’un (Pascal?) a une explication, moi je sèche.

#2

Bonjour fran.b,
en attendant la reponse de notre expert, j’ai une sugestion.
Forcer une adresse IP n’est pas équivalent à unDHCP.
Il te faut aussi forcer la gw, voire les DNS (inutile dans ton cas)

#3

C’est le cas (le trafic se fait très bien), mais de toute façon ici la machine est passive et se contente d’écouter. On a donc
deux machines sur le même réseau, l’une avec une adresse donnée en DHCP, l’autre avec une adresse en dur, dans les deux cas, il n’y a pas de conflit d’IP sur le réseau, les deux voient passer les paquets multicast (vérifié par tcpdump), sur celle qui a l’adresse en DHCP, ecoute renvoit le message diffusée en multicast, sur l’autre non:

descartes:~# tcpdump port 2012 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 08:40:45.118181 IP 10.0.1.92.50934 > 225.0.0.37.2012: UDP, length 9 08:40:48.119554 IP 10.0.1.92.50934 > 225.0.0.37.2012: UDP, length 9 08:40:51.120623 IP 10.0.1.92.50934 > 225.0.0.37.2012: UDP, length 9 08:40:54.121850 IP 10.0.1.92.50934 > 225.0.0.37.2012: UDP, length 9 08:40:57.122956 IP 10.0.1.92.50934 > 225.0.0.37.2012: UDP, length 9 ^C 5 packets captured 5 packets received by filter 0 packets dropped by kernel descartes:~# ecoute ^C (après plusieurs minutes) descartes:~# ifconfig | grep -A 1 eth0 eth0 Link encap:Ethernet HWaddr 00:23:7d:20:5b:af inet adr:10.210.0.13 Bcast:10.255.255.255 Masque:255.0.0.0 descartes:~# et

stokes:~# tcpdump port 2012 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 08:43:07.046186 IP 10.0.1.92.50934 > 225.0.0.37.2012: UDP, length 9 08:43:10.047400 IP 10.0.1.92.50934 > 225.0.0.37.2012: UDP, length 9 08:43:13.048586 IP 10.0.1.92.50934 > 225.0.0.37.2012: UDP, length 9 08:43:16.049853 IP 10.0.1.92.50934 > 225.0.0.37.2012: UDP, length 9 ^C 4 packets captured 4 packets received by filter 0 packets dropped by kernel stokes:~# ecoute 10.0.1.92 (au bout de 4s) stokes:~# ifconfig | grep -A 1 eth0 eth0 Link encap:Ethernet HWaddr 00:23:7d:21:45:ed inet adr:10.0.0.104 Bcast:10.255.255.255 Masque:255.0.0.0 stokes:~# Je ne comprend pas…

#4

Je ne suis pas un expert, et d’ailleurs je ne connais pas grand chose au multicast. Juste une idée : tu as comparé les sorties de “ip maddr” sur les deux machines ?

#5

descartes:~# /tmp/ip maddr 1: lo inet 224.0.0.1 2: eth0 link 01:00:5e:00:00:01 link 01:00:5e:00:00:fb inet 224.0.0.251 inet 224.0.0.1 6: tap0 link 01:00:5e:00:00:01 link 01:00:5e:00:00:fb inet 224.0.0.251 inet 224.0.0.1 descartes:~# ifconfig eth0 | head -n 2 eth0 Link encap:Ethernet HWaddr 00:23:7d:20:5b:af inet adr:10.210.0.13 Bcast:10.255.255.255 Masque:255.0.0.0 descartes:~# ecoute ^C descartes:~# et stokes:~# /tmp/ip maddr 1: lo inet 224.0.0.1 2: eth0 link 01:00:5e:00:00:01 link 01:00:5e:00:00:fb inet 224.0.0.251 inet 224.0.0.1 3: tap0 link 01:00:5e:00:00:01 link 01:00:5e:00:00:fb inet 224.0.0.251 inet 224.0.0.1 stokes:~# ifconfig eth0 | head -n 2 eth0 Link encap:Ethernet HWaddr 00:23:7d:21:45:ed inet adr:10.0.0.104 Bcast:10.255.255.255 Masque:255.0.0.0 stokes:~# ecoute 10.0.1.92 stokes:~#

Je regarde quelle a pu être ton idée…

#6

Bon, en affinant les recherches, il suffit de préciser une passerelle quelconque, même si elle n’existe pas pour que ça marche:

ermat:~# route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0 10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0 0.0.0.0 10.210.0.254 0.0.0.0 UG 0 0 0 eth0 fermat:~# route del default gw 10.210.0.254 fermat:~# ecoute ^C fermat:~# route add default gw 10.123.45.67 fermat:~# ecoute 10.0.1.92 fermat:~# route del default gw 10.123.45.67 fermat:~# route add default gw 10.11.12.13 fermat:~# ecoute 10.0.1.92 fermat:~# route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0 10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0 0.0.0.0 10.11.12.13 0.0.0.0 UG 0 0 0 eth0 fermat:~# route del default gw 10.11.12.13 fermat:~# Je ne peux pas dire que ça s’éclaircit pour moi, car j’ai regardé par acquis de conscience le trafic pendant ce temps, il n’y a absolument rien mis à part le multicast: rien, que dalle, nada et surtout rien à destination de la passerelle mythique. C’est un système dévot: la passerelle n’existe pas mais il faut lui faire croire qu’elle existe pour qu’il fonctionne, sinon il est désemparé!

#7

Je pensais à regarder la liste des adresses multicast pendant que le programme tourne.
Mais le problème ne semble pas être là, d’après ta dernière découverte. Cela me fait un peu penser à l’effet de rp_filter, qui bloque les paquets entrants dont l’adresse source n’est pas routable. Tu as testé en créant une route juste pour l’adresse multicast (ce n’est pas une solution, juste une tentative d’affiner le problème) ?

#8

C’est ça, il suffit même d’une route vers 225.0.0.37 seul, ça suffit. Je vais de voir…

#9

Juste pour ma culture,
en DHCP, comment sont définies les routes ?

#10

0.0.0.0 10.0.0.3 0.0.0.0 UG 0 0 0 eth0 0.0.0.0 10.0.0.2 0.0.0.0 UG 0 0 0 eth0

#11

[quote=“PascalHambourg”]Je pensais à regarder la liste des adresses multicast pendant que le programme tourne.
Mais le problème ne semble pas être là, d’après ta dernière découverte. Cela me fait un peu penser à l’effet de rp_filter, qui bloque les paquets entrants dont l’adresse source n’est pas routable. Tu as testé en créant une route juste pour l’adresse multicast (ce n’est pas une solution, juste une tentative d’affiner le problème) ?[/quote]
Pour ta première question, tu obntiens

1: lo inet 224.0.0.1 2: eth0 link 01:00:5e:00:00:01 link 01:00:5e:00:00:fb link 01:00:5e:00:00:25 inet 225.0.0.37 inet 224.0.0.251 inet 224.0.0.1 4: tap0 link 01:00:5e:00:00:01 link 01:00:5e:00:00:fb inet 224.0.0.251 inet 224.0.0.1 (sur une machine qui marche) et

1: lo inet 224.0.0.1 2: eth0 link 01:00:5e:00:00:01 link 01:00:5e:00:00:fb inet 224.0.0.251 inet 224.0.0.1 4: tap0 link 01:00:5e:00:00:01 link 01:00:5e:00:00:fb inet 224.0.0.251 inet 224.0.0.1 quand ça ne marche pas, il y a bien une ligne
inet 225.0.0.37
en plus. Le rajout de d’une route vers 225.0.0.37 rajoute bien
inet 225.0.0.37
et ça marche (mais n’explique pas).

#12

J’avais prévenu : je connais très peu le multicast, j’essaie juste de t’aider à trouver des indices.

#13

Je viens d’imprimer le howto advanced routing (où j’ai toujours trouvé une réponse), je cherche lors de mes temps perdus