Funkcja multiemisji UDP nie działa

Multicast UDP na Raspberry Pi

Nie zawęziłem się wystarczająco, aby wiedzieć, czy mój problem jest spowodowany debianem, konkretnie raspbianem, czy też po prostu czegoś brakuje.

Mam aplikację w języku Python, która korzysta z multiemisji UDP, aby inne urządzenia w sieci wiedziały, że moja aplikacja działa i jest dostępna pod określonym adresem IP.

Grupa multiemisji UDP to 239.255.250.250, a port to 9131. Jeśli uruchomię program tcpdump, widzę, że pakiet, który próbuję wysłać, faktycznie wysyła dane, ale nigdy nie widzę, aby cokolwiek przechodziło na innych komputerach w sieci.

Istnieją inne urządzenia, które używają tego samego rodzaju „sygnału nawigacyjnego” z tą samą grupą multiemisji i portem, i widzę, że te pakiety przechodzą na inne maszyny. Router nie ma zapory ogniowej, w tym momencie naprawdę brakuje mi opcji.

Poniżej znajduje się podstawowa diagnostyka, którą wiem, jak uruchomić. Złe udp chksum wygląda na to, że prawdopodobnie nie jest pomocne, ale tak naprawdę nic o tym nie wiem.

Wyjście ifconfig

eth0      Link encap:Ethernet  HWaddr b8:27:eb:b2:79:12  
          inet addr:192.168.2.7  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1682 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1686 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:119105 (116.3 KiB)  TX bytes:169570 (165.5 KiB)

Dane wyjściowe tcpdump podczas działania aplikacji

    tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
03:29:15.722653 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 221)
    192.168.2.7.33335 > 239.255.250.250.9131: [bad udp cksum 0xae84 -> 0xaabe!] UDP, length 193
    0x0000:  4500 00dd 0000 4000 0111 cb66 c0a8 0207  E.....@....f....
    0x0010:  efff fafa 8237 23ab 00c9 ae84 414d 5842  .....7#.....AMXB
    0x0020:  3c4d 4143 2d41 4444 523d 6238 3a32 373a  <MAC-ADDR=b8:27:
    0x0030:  6562 3a62 323a 3739 3a31 323e 3c2d 5555  eb:b2:79:12><-UU
    0x0040:  4944 3d32 3032 3438 3135 3937 3537 3734  ID=2024815975774
    0x0050:  3930 3e3c 2d53 444b 436c 6173 733d 5574  90><-SDKClass=Ut
    0x0060:  696c 6974 793e 3c2d 4d61 6b65 3d69 5275  ility><-Make=iRu
    0x0070:  6c65 426f 783e 3c2d 4d6f 6465 6c3d 5265  leBox><-Model=Re
    0x0080:  6d6f 7465 426f 783e 3c2d 5265 7669 7369  moteBox><-Revisi
    0x0090:  6f6e 3d30 2e31 3e3c 2d50 6b67 5f4c 6576  on=0.1><-Pkg_Lev
    0x00a0:  656c 3d47 4350 4b30 3032 3e3c 2d43 6f6e  el=GCPK002><-Con
    0x00b0:  6669 672d 5552 4c3d 6874 7470 3a2f 2f31  fig-URL=http://1
    0x00c0:  3932 2e31 3638 2e32 2e37 3a38 303e 3c2d  92.168.2.7:80><-
    0x00d0:  5374 6174 7573 3d52 6561 6479 3e         Status=Ready>
^C
1 packet captured
1 packet received by filter
0 packets dropped by kernel

Wyjście netstat podczas działania programu

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
udp        0      0 0.0.0.0:31144           0.0.0.0:*                           1510/dhclient   
udp        0      0 0.0.0.0:33335           0.0.0.0:*                           2089/python     
udp        0      0 0.0.0.0:68              0.0.0.0:*                           1510/dhclient   
udp        0      0 192.168.2.7:123         0.0.0.0:*                           1911/ntpd       
udp        0      0 0.0.0.0:123             0.0.0.0:*                           1911/ntpd  

Rozumiem, że twój host 192.168.2.7 wysyła pakiet multiemisji do grupy 239.255.250.250 na porcie 9131

UWAGA: Zakładam jednak, że serwery nasłuchują na porcie 9131. Nie podałeś żadnych informacji na ten temat.

Z danych wyjściowych ifconfig widzę, że MULTICAST jest włączony i tcpdump to potwierdza.

Najpierw upewnij się, że host obsługujący serwery (ten odbierający pakiet multiemisji) dołączył do grupy multiemisji.

Na każdym typie hosta serwera:

netstat -gn

Jeśli widzisz swój adres multiemisji, dołączył on do grupy. Jeśli nie, oznacza to, że coś jest nie tak z programem serwera lub z ustawieniami jądra.

Jeśli serwer dołączył do grupy, ale nie widzisz żadnego pakietu przychodzącego od klienta, sprawdź na routerze, czy masz włączoną funkcję igmp (router musi obsługiwać tę funkcję)

Na przykład na routerze cisco

enable
conf t
ip multicast-routing
For each interface involved.
int <NIC>
ip pim sparse-dense-mode

Jeśli igmp jest włączony na routerze, poszukaj funkcji debugowania, aby śledzić pakiety.

Po stronie serwera rozpocznij przechwytywanie pakietów:

tcpdump -i <NIC> host 239.255.250.250

Jeśli nie widzisz żadnego przychodzącego pakietu, pakiet multiemisji nie jest przesyłany dalej (zakładając, że

Następnie na kliencie wyślij pakiet multiemisji (skorzystaj ze skryptu w linku poniżej, aby rozwiązać problem)

UWAGA: pakiet UDP wygląda na zniekształcony, więc nie jestem pewien, czy serwery będą w stanie go odczytać. Możesz użyć skryptu w linku poniżej, aby potwierdzić, czy wiadomość w tcpdump wyświetla się jako zniekształcona, czy nie (w moim przypadku nie)

Przykład kodu python używającego multiemisji:

/programming/603852/multicast-in-python

UWAGA: Użyłem tego skryptu na debian raspi (nie raspbian i serwer odbierał pakiety przez router - zgodnie z powyższą konfiguracją - dobrze)

Przewodnik po Linuksie: http://stlinux.com/howto/network/short-guide

Cisco: http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/release/12-2_52_se/configuration/guide/3750scg/swmcast.html#wp1024278

Zauważyłem, że może to być także problem ze sprzętem i / lub sterownikiem. Używałem multiemisji UDP (przesyłaj i odbieraj) na moich interfejsach RaspberryPI bez żadnych problemów - z programami C, Java i / lub Python.

Jednak właśnie dowiedziałem się, że odbiór multiemisji UDP NIE DZIAŁA z ładnym małym adapterem WiFi USB nano od EDIMAX - wysyłanie UDP (multiemisja) działa, również odbieranie własnych (lokalnych) wiadomości.

szczegóły pamięci USB od lsusb:

Odbiór multiemisji UDP nie działa: ID 7392: 7811 Edimax Technology Co., Ltd EW-7811U Adapter bezprzewodowy 802.11n [Realtek RTL8188CUS]

Odbiór multiemisji UDP działa dobrze: ID 148f: 3070 Ralink Technology, Corp. RT2870 / RT3070 Wireless Adapter

Napotkałem podobny problem, gdy przychodziły pakiety i mogłem je zobaczyć, tcpdumpale żaden program nie mógł odebrać danych.

Problem w tym przypadku polegał na tym, że iptableszezwalałem tylko na ruch z mojej lokalnej podsieci, 192.168.0.0/24ale oczywiście pochodzi z 224.0.0.0/4tego multicast . Zamiast otwierać całą podsieć (może wtedy nie mieć firewalla) po prostu zezwoliłem na ruch ze wszystkich hostów na określonym porcie UDP, którego używałem do multiemisji, i to rozwiązało problem.

Dla nas mieliśmy podobny problem polegający na tym, że grupa multiemisji została dobrze dołączona, ale wiadomości nie były odbierane.

Sprawdziliśmy ustawienia igmp na routerze, które wydawały się być w porządku.

Ostatecznie przeszliśmy z używania adresu multiemisji IPv6 na IPv4, co rozwiązało ten problem dla tego konkretnego systemu.