UDP многоадресной рассылки не работает


11

Многоадресный UDP по малиновому пи

Я не достаточно сузил круг вещей, чтобы понять, связана ли моя проблема с Debian, особенно с Rasbian, или я просто что-то упускаю.

У меня есть приложение Python, которое использует многоадресный UDP, чтобы другие устройства в сети знали, что мое приложение работает и доступно по определенному IP-адресу.

Группа многоадресной рассылки UDP - 239.255.250.250, а порт - 9131. Если я запускаю tcpdump, я вижу, что пакет, который я пытаюсь отправить, действительно отправляет данные, но я никогда не вижу, чтобы что-то проходило на других машинах в сети.

Существуют другие устройства, которые используют этот же «маяк» с той же группой и портом многоадресной рассылки, и я вижу, как эти пакеты проходят на других машинах. Маршрутизатор не имеет брандмауэра, и на данный момент у меня действительно нет выбора.

Ниже приведена базовая диагностика, которую я знаю, как запустить. Плохой udp chksum выглядит так, как будто это не очень полезно, но я ничего об этом не знаю.

Вывод 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)

Вывод tcpdump во время работы приложения

    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

Вывод netstat во время работы программы

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  

Можете ли вы предоставить вывод netstat -gn на 2 хоста?
UnX

Может быть полезно: superuser.com/questions/324824/…
cpugeniusmv

Ответы:


13

Я понимаю, что ваш хост, 192.168.2.7 отправляет многоадресный пакет в группу 239.255.250.250 через порт 9131

ПРИМЕЧАНИЕ. Однако я предполагаю, что серверы прослушивают порт 9131. Вы не предоставили никакой информации об этом.

Из вывода ifconfig я вижу, что MULTICAST включен, и tcpdump подтверждает это.

Сначала убедитесь, что хост, на котором работают серверы (тот, который получает многоадресный пакет), присоединился к группе многоадресной рассылки.

На каждом сервере тип хоста:

netstat -gn

Если вы видите свой адрес многоадресной рассылки, он присоединился к группе. Если нет, то либо что-то не так с вашей серверной программой, либо возможно с настройками ядра

Если сервер присоединился к группе, но вы не видите никаких пакетов, поступающих от клиента, то проверьте на своем маршрутизаторе, что вы включили igmp (ваш маршрутизатор должен поддерживать igmp)

Например, на маршрутизаторе cisco

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

Если на маршрутизаторе включена функция igmp, найдите функции отладки для отслеживания пакетов.

На стороне сервера запустите захват пакета:

tcpdump -i <NIC> host 239.255.250.250

Если вы не видите входящий пакет, то многоадресный пакет не пересылается (при условии, что

Затем на клиенте отправьте пакет многоадресной рассылки (используйте сценарий по ссылке ниже для устранения неполадок)

ПРИМЕЧАНИЕ. Пакет UDP выглядит неправильно сформированным, поэтому не уверен, что сервер сможет его прочитать. Вы можете использовать скрипт в ссылке ниже, чтобы подтвердить, отображается ли сообщение в tcpdump как искаженное или нет (в моем случае это не так)

Пример кода Python с использованием многоадресной рассылки:

/programming/603852/multicast-in-python

ПРИМЕЧАНИЕ: я использовал этот скрипт на Debian Raspi (не Rasbian и сервер получил пакеты через маршрутизатор - как описано выше - отлично)

Руководство по Linux: 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


Очень длинный ответ и самая крошечная часть - это то, что на самом деле казалось проблемой. Упомянутый вами способ устранения неполадок я уже сделал, но это было после того, как я опубликовал это. На сервере и клиенте все выглядело хорошо. IGMP на роутере была проблемой, но эта настройка была скрыта
Alex

2
Ваше описание не было достаточно четким, чтобы дать прямой ответ, поэтому я подумал, что смогу написать мини-руководство по устранению неполадок.
UnX

1

Я заметил, что это также может быть проблема с оборудованием и / или драйвером. Я использовал многоадресный UDP (передача и получение) на моих raspberryPI без каких-либо проблем - с программами на C, Java и / или Python.

Однако я только что узнал, что многоадресный прием UDP НЕ РАБОТАЕТ с симпатичным маленьким USB-нано-адаптером Wi-Fi от EDIMAX - отправка UDP (многоадресная передача) работает, а также получение собственных (локальных) сообщений.

Подробности о флешках от lsusb:

Многоадресный прием UDP не работает: ID 7392: 7811 Edimax Technology Co., Ltd. EW-7811Ни беспроводной адаптер 802.11n [Realtek RTL8188CUS]

UDP многоадресный прием работает нормально: ID 148f: 3070 Ralink Technology, Corp. Беспроводной адаптер RT2870 / RT3070


также работает: эта карта от ASUS с идентификатором 0b05: 1791 ASUSTek Computer, Inc. Адаптер WL-167G v3 802.11n [Realtek RTL8188SU]
Майкл

0

Я столкнулся с аналогичной проблемой, когда входили пакеты, и я мог видеть их, tcpdumpно ни одна программа не могла получить данные.

Проблема в этом случае заключалась в том, что я использовал, iptablesчтобы разрешить трафик только из моей локальной подсети, 192.168.0.0/24но, конечно, 224.0.0.0/4вместо этого приходит многоадресная рассылка . Вместо того, чтобы открывать всю эту подсеть (может, тогда и не было брандмауэра), я просто разрешил трафик со всех хостов на конкретном порту UDP, который я использовал для многоадресной рассылки, и это решило проблему.


0

У нас была похожая проблема, когда многоадресная группа была присоединена нормально, но сообщения не получали.

Мы проверили настройки igmp на маршрутизаторе, который, казалось, был в порядке.

В итоге мы перешли от использования многоадресного адреса IPv6 к IPv4, и это разрешило его для этой конкретной системы.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.