8

RaspBMC を Raspberry Pi に、XBMC を Windows ラップトップに、UPnPlay を Android デバイスにインストールしました。Raspberry Pi は常にオンになっており、システムのサーバーとして機能することを目的としています。

関連する IP アドレス:

  • 192.168.0.18:RPi

  • 192.168.0.13: ラップトップ

  • 192.168.0.1: ルーター

Android デバイスを WiFi に接続し、UPnPlay をオンにするか、ラップトップで XBMC を開始すると、以前は Raspberry Pi がデバイスのリストに表示されるまでに 5 ～ 10 分の遅延がありました。ただし、過去数週間、他のサービス (XBMC または UPnPlay) の実行中に Pi を再起動しない限り、Pi はまったく表示されません。Pi に ssh および sftp で接続でき、両方のデバイスから問題なく RaspBMC の Web インターフェイスにアクセスできます。

UPnP ネットワークの検出/通知メッセージが失われたりブロックされたりする可能性はありますか? これをどのように調査しますか？ネットワークに関する私の知識は、ポート転送に限られています。

私は UPnP の代替プロトコルの提案を歓迎します - それは私が遭遇した最初のプロトコルであり、以前のセットアップ (Apple TV にメディアを送信するデスクトップ上の XBMC) で問題なく動作しました。

編集：

ラップトップで Wireshark を使用したいくつかの分析では、ラップトップが期待どおりに動作していることを示しています。M-SEARCH および NOTIFY パケットを SSDP 経由で定期的に 239.255.255.250 (マルチキャスト アドレスであると思われます) に送信しています。ただし、RPi はユニキャスト パケットでこれらのパケットに応答しないだけでなく (Wikipedia で推奨されているように)、ブート時を除いて SSDP パケットも送信しません。

私は Wireshark とネットワーク分析全般に非常に慣れていませんが、ガイダンスやアドバイスをいただければ幸いです。

私が使用した Wireshark フィルターは "(udp.dstport == 1900 or ip.addr == 192.168.0.18) and !(ip.src == 192.168.0.1)" で、192.168.0.18 は私の RPi のアドレスです。これは正しいことですが、私が言ったように、私は Wireshark に非常に慣れていないので、間違っていたら訂正してください! 特に、M-SEARCH に対する RPi のマルチキャスト応答は ip.src = 192.168.0.18 であると想定しましたが、確かではありません (おそらく 192.168.0.1 または 239.255.255.250 である可能性があります)。

編集2：

この投稿に導かれて実行し/sbin/route -n、次の出力を得ました。

pi@raspbmc:~$ /sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

これをどのように解釈すればよいかわかりませんが、リンクされたスレッドの他のコメントから判断すると、マルチキャストのエントリが欠落しているようです。繰り返しになりますが、リンクされたスレッドからのこのアドバイスに従って、 を実行しsudo route add -net 239.0.0.0 netmask 255.0.0.0 eth0、これを に追加して/etc/rc.local、RPi を再起動しましたが、UPnP クライアントのネットワーク デバイスのリストにまだ Pi が表示されません。また、マルチキャスト アドレスとして 239.255.255.250 を使用しようとしましたが (上記の編集 1 を参照)、エラーが発生しましroute: netmask doesn't match route addressた。

繰り返しますが、リンクされた投稿に従って、インストール済みの tshark を実行して実行しました (ネットワーク上の他のデバイス間で多くのトラフィックが見sudo tshark -i et0 multicast | grep 192.168.0.18られたため、追加しました)。grep

これが出力です。

RPi はNOTIFYパケットのクラスターを送信しますが、非常にまれです (このレコードは 20 分近くをカバーし、2 つのクラスターのみが送信されます)。ARPパケットはここで説明されているとおりであると思います。これは、一部のデバイスがネットワーク上の他のデバイスの MAC アドレスを欠いていることを意味します。これは潜在的に心配なことではありますが (特定のデバイスは同じアドレスを 2 回以上要求します - なぜ彼らはこれを「忘れる」のですか?)、おそらくもっと心配なのは、これらのパケットが送信される頻度が低いことと、送信された場合でも、 、ネットワーク上のクライアントはまだ RPi を取得しません。

要約すると、次のようになります。

  • RPi はNOTIFYパケットを送信していますが、非常にまれです。これを制御する方法はありますか？

  • RPi がNOTIFY(起動時ではなく、通常のイベントの過程で) パケットを送信した場合でも、ネットワーク上のクライアントはその存在を認識しません。

  • M-SEARCHRPi は、他のデバイスから送信されたパケットに応答していないようです。

4

2 に答える 2

5

UPnP ネットワークの検出/通知メッセージが失われたりブロックされたりする可能性はありますか?

失われた、間違いなく。おそらく、いずれかの UPnP ノードで音声マルチキャスト UDP が正しく実装されていないために、まったく送信されないという意味でブロックされました。ブランド認定のホーム エンターテイメント デバイスで、RaspBMC と同様の動作が定期的に見られます。

UPnP ネットワークに接続しているすべてのノードは、自身をアドバタイズする必要があります。マルチキャストを送信する (つまり、アドレス 239.255.255.250 に) HTTP と非常によく似た内容の UDP パケットを送信しますが、アクションはNOTIFY. RaspBMCのこの部分はうまく機能しているようです。そのため、別のテスト シナリオを依頼しました。

次に、同じノードがオプションでネットワークを検出M-SEARCHできます。再度アクションでマルチキャスト UDP パケットを送信しますがNOTIFY、実際には、他の UPnP ノードからのユニキャスト応答を待ちます。メディア サーバーとしてのRaspBMCは、他のノードを認識する必要がないため、これを行う必要はありません。ただし、他のノードはネットワーク内のサーバーについて知る必要があり、いくつかの点が間違っている可能性があります。

  • XBMC/UPnPlay は、このマルチキャスト検出を送信しません (XBMC が以前は機能していたとのことですが、可能性は低いです)。
  • RaspBMCがチョークし、最初の検出時に予期されたユニキャスト応答を送信せず、しばらくしてから送信します
  • XBMC/UPnPlay はRaspBMCが送信した応答を理解せず、破棄します

これをどのように調査しますか？

Windows ラップトップにIntel UPnP Developer ToolsからDeviceSpyをインストールします。これは、UPnP コントロール ポイントの最も信頼できる実装として常に観察されています。RasPiがすぐに表示されない場合は、RaspBMCの問題です。ユニキャスト応答をまったく送信しなかったか、応答が正しくありません。

ポップアップする場合は、同じツールセットからDevice Snifferを実行します。XBMC または UPnPPlay を起動し、UPnP ディスカバリ マルチキャスト トラフィックを観察します。Windows または Android の予想される IP アドレスから発信された M-SEARCH があるが、RaspBMCがポップアップしない場合、それはRaspBMCの問題です。残念ながら、ツールはRaspBMCからのユニキャスト応答をキャッチできません(存在する場合)。

最悪の場合、Wiresharkをインストールし、キャプチャをRasPiの IP アドレスにフィルタリングします。ユニキャスト応答を送信したかどうかが通知され、コンテンツを確認できます。

于 2012-12-05T09:49:48.960 に答える