Raspberry Pi上のマルチキャストUDP
私の問題が具体的にはdebian、raspbianのせいなのか、それとも完全に何かが足りないのかを知るのに十分なほど絞り込んでいません。
マルチキャストUDPを使用するpythonアプリケーションがあり、アプリケーションが稼働中で特定の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 [email protected]....
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
あなたのホスト192.168.2.7がポート9131でグループ239.255.250.250にマルチキャストパケットを送信していることを理解しました
注:ただし、サーバーはポート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マルチキャストを使用したコードの例:
https://stackoverflow.com/questions/603852/multicast-in-python
注:私はこのスクリプトをdebian raspiで使用しました(raspbianではなく、サーバーはルーターを介してパケットを受信しました-上記の設定で-細かい)
これもハードウェアやドライバの問題である可能性があることに気付きました。私は問題なくraspberryPIでマルチキャストUDP(送信および受信)を使用しました-C、Javaおよび/またはPythonプログラム。
ただし、UDPマルチキャスト受信はEDIMAXの素敵な小さなUSBナノwifiアダプターでは機能しないことを知りました。UDP(マルチキャスト)の送信は機能し、独自の(ローカル)メッセージも受信します。
lsusbのUSBスティックの詳細:
UDPマルチキャスト受信が機能しない:ID 7392:7811 Edimax Technology Co.、Ltd EW-7811Un 802.11nワイヤレスアダプター[Realtek RTL8188CUS]
UDPマルチキャスト受信は正常に機能します:ID 148f:3070 Ralink Technology、Corp. RT2870/RT3070ワイヤレスアダプター
私たちにとって、マルチキャストグループが正常に参加したという同様の問題がありましたが、メッセージが受信されていませんでした。
ルーターのigmp設定を確認しましたが、問題がないようです。
最終的に、IPv6マルチキャストアドレスの使用からIPv4に切り替え、その特定のシステムで解決しました。
パケットが着信し、tcpdump
でそれらを見ることができたが、プログラムがデータを受信できなかったという同様の問題が発生しました。
この場合の問題は、ローカルサブネットからのトラフィックのみを許可するためにiptables
を使用していたことでした192.168.0.0/24
ですが、もちろんマルチキャストは224.0.0.0/4
代わりに。サブネット全体を開くのではなく(ファイアウォールがない場合もあります)、マルチキャストに使用していた特定のUDPポート上のすべてのホストからのトラフィックを許可するだけで、問題が解決しました。