3

短い話:私の DDS サブスクライバーは、私の DDS パブリッシャーからのデータを見ることができません。私は何が欠けていますか？

長い話：

QNX 6.4.1 VM A -- Broken Publisher. IP ends with .113
QNX 6.4.1 VM B -- Working Publisher. IP ends with .114
Windows 7      -- Subscriber/Main Dev box. IP ends with .203
RTI DDS 5.0    -- Middleware version

QNX VM (自分のマシンではなく、ネットワーク上でホストされている) があり、RTI DDS 経由でデータを公開しています。Windows 7 サブスクライバー アプリケーションにデータが表示されません。

興味深いことに、同じコードを VM B に置くと、サブスクライバーがデータを取得できます。これは Windows 7 のファイアウォールの問題に違いないと考えて、VM A の IP アドレスを VM B と交換しましたが、これは役に立ちませんでした。

Wireshark を使用すると、VM A からのハートビート トラフィックを確認できますが、データはありません。VM B からは、ハートビート トラフィックとデータが表示されます。以下は、無害化された Wireshark のスニペットです。 Wireshark 出力

NDDS_DISCOVERY_PEERSマルチキャストと、各会話の反対側の明示的な IP アドレスの両方を含めるように設定されています。QOS プロファイルは同じで、RTI アナライザーは一致分析が成功したことを示します (すべて緑色)。

仮想マシン A: NDDS_DISCOVERY_PEERS=udpv4://239.255.0.1,udpv4://127.0.0.1,udpv4://BLAH.203

仮想マシン B: NDDS_DISCOVERY_PEERS=udpv4://239.255.0.1,udpv4://127.0.0.1,udpv4://BLAH.203

Windows 7 ボックス: NDDS_DISCOVERY_PEERS=udpv4://239.255.0.1,udpv4://127.0.0.1,udpv4://BLAH.113,udpv4://BLAH.114

それらをNDDS_DISCOVERY_PEERS行に含めると、ネットワーク上の他の人々は、Windows 7 ボックスで DDS SPY を使用して VM A からの DDS トラフィックを見ることができます。私の Windows 7 ボックスではできません。

Windows 7 のイベント ログには、データ パケットを停止しているファイアウォールまたは WFP が表示されていないようです。

Windows 7 マシンから RTI DDS Spy を実行すると、VM A (0A061071) ライターがネットワーク上に表示されますが、データは受信されません。また、Windows 7 マシンのサブスクライバーのリーダーが表示されていることも示されていますが、奇妙な IP アドレスで表示されています。

おまけの質問(主な質問ではなく、単なる好奇心から): ローカル マシンのトラフィック192.168.11.1が、マシンの IP または の代わりにDDS SPY に表示されるのはなぜ127.0.0.1ですか?

RTI DDS SPY 出力

主な質問:何が欠けていますか?

更新: route print私の Windows 7 ボックスでは、VM A でマルチキャスト グループに参加したことが示されている netsh interface ip show joinsように見えます。

調査の更新:

  1. VM を再起動しても効果はありませんでした。

  2. Windowsボックスを再起動しても効果がありませんでした。

  3. NDDS_DISCOVERY_PEERS両側の環境変数からマルチキャストを削除しましたが、効果はありませんでした。

  4. Windows 7 ボックスには、3 つのネットワーク インターフェイス (およびループバック) があります。1 つの LAN 接続と 2 つの (関連のない) VM アダプターです。LAN接続で作業しています。QNX VM には 1 つのネットワーク インターフェイス (およびループバック) があります。動作中の VM と故障した VM は、QNX 6.4.1 のフレーバーがわずかに異なるため、互いに異なるイーサネット ドライバーを使用していることに注意してください。壊れたものはwm0インターフェースとして、機能しているものはインターフェースとして持っen0ています。これが問題だとは思いませんが、違いです。

  5. 「壊れた」QNX VM の再生中に DDS SPY を実行し、DDS データを取得しました。VM がホストされている場所と Windows 7 マシンとの間のネットワークをスニッフィングして、インターフェイスから抜け出すかどうかを確認する良い方法はありませんが、QNX VM のイーサネット インターフェイスから送信されたパケット数を調べます。は確実に何かを送信していることを示しており、Windows 7 マシン自体での Wireshark キャプチャは、少なくとも一部のトラフィックが通過していることを示しています。

  6. ここのLAN上の他の人々は、「壊れた」VMからのDDSトラフィックを見ることができます. ファイアウォールを再確認しましたが、役に立ちませんでした。ファイアウォールの問題であれば、VM A と VM B の間で IP アドレスを交換すれば問題は解決したと思います。いずれにせよ、Windows 7 のファイアウォールは現在オフになっているため、役に立ちません。

  7. 以下は、Wireshark 出力のいくつかの画面です。4回目以降は最後までトラフィックが4回目の最下位のように見える傾向があったため、3回目と4回目の間をスキップしました。

画像1 画像2 画像3 (ここではたくさんスキップしました) 画像4 (上記の最後の 11 行のようにほとんど続きます)

他に何を試す必要がありますか？

更新: 以下の Rose の質問に答えるrtiddsping -publisherには、悪い VM で使用し、rtiddsping -subscriber適切に動作します。

この問題は、変な IP アドレスが原因なのだろうか。たまたま公開され、何らかの形でラッチされる IP アドレスは、ローカル VM イーサネット アダプター (VM A とは別) です。以下のスクリーンショットを参照してください。

Win7 Ipconfig

添付したいアドレスは 10.6.6.203 です。それを特定する方法はありますか？

4

3 に答える 3

4

1 年以上後、これは別の仮想マシンで再び発生しました。私は昨日それを働いていたので、私は非常に疑わしい. 過去 24 時間に行ったすべてのコード変更の問題を探しましたが、何も見つかりませんでした。次に、IT 部門が私のコンピューターに何らかのパッチをプッシュしたかどうかを確認することにしました。

何だと思う？Windows ファイアウォールは、前日から積極的に更新されていました。ルールの欠落または変更など。ログには、パケットがドロップされていることが示されていました。ファイアウォールフィルターを少し開いたところ、突然、すべてが再び機能しました。私は 100% ではないので、この問題を閉じるのをためらっていますが、これは昨年とまったく同じでしたが、非常に似ていると感じています。昨年、ファイアウォールの設定でパケット ドロップがログに記録されていなかったと思われます。

要するに、DDS が突然動作しなくなった場合は、ファイアウォールの設定を確認してください。

于 2014-05-16T20:48:20.720 に答える
2

試してみるいくつかのこと：

  1. 破損した VM で rtiddsping -publisher を実行し、Windows で rtiddsping -subscriber を実行してみてください。これには 2 つの利点があります。

    • データ型は小さく、よく知られているため、さまざまなイーサネット ドライバーが原因でデータがフラグメント化されるという問題がある場合、rtiddsping では発生せず、問題の追跡に役立つ場合があります。
    • パブリッシャーとサブスクライバーがお互いを検出すると Rtiddsping が出力されるため、両側で検出が正しく完了していることを確認できます。Analyzer が両方のアプリケーションを表示しているので、ディスカバリーが機能していると思いますが、確認するのは良いことです。

  2. アプリケーションで見られるのと同じ問題が rtiddsping で発生する場合は、冗長性を rtiddsping -verbosity 3 に上げてから 5 に上げます。最も高い冗長性レベルでは、(大量の) 追加の出力が出力されます。何が起こっているかについてのヒント。

スパイに関するおまけの質問に答えるには: スパイがその IP アドレスを表示している理由は、それが発見の一環として発表されているアドレスの 1 つだからです。検出中に、DomainParticipant は、それに到達するために使用できる最大 4 つの IP アドレスを通知できます。Spy はそれらのいずれかを選択して表示しますが、アプリケーションとの通信に使用されている実際のアドレスではない場合があります。マシンに 192.168.11.1 IP アドレスとのインターフェイスがない場合、これはより大きな問題を示している可能性があります。(ただし、正しい IP が発表された 4 つのうちの 1 つである限り、これは正常な場合があります。)

パケット トレース イメージに目を通すと、明らかに問題となるものは何もありません。私が気づいたいくつかのこと：

  • 最終的なパケット トレース イメージには、ハートビート/ACKNACK の通常のパターンがあるようです。これは、2 つのアプリケーション間で何らかの双方向通信が行われていることを示しています。
  • これらの画像から、.113 から .203 に送信されるデータが参加者間メッセージで構成されているのか、それとも実際の発見メッセージで構成されているのかを判断するのは困難です - パケット #805 とパケット #816 (フラグメント 811- 815) .203 に送信されている発見通知のように見えます。これは、.113 のアプリケーションに少なくとも 4 つのエンティティ (DataWriter または DataReader) があることを示しています。

そのため、検出データはアプリケーションによって .113 で送信されています。それは WireShark によって受信され、再構築されていますが、アプリケーションによって正しく受信されたとは限りません。

パケット #816 の最後にハートビートがあります。パケット #818 または #819 がそのハートビートに応答している ACKNACK である可能性がありますが、画像からは確信が持てません。次のステップは、.203 から .113 までの ACKNACK を調べて、.203 がすべての発見データを受信したと考えているかどうかを確認することです。以下は、ディスカバリー DataReader がすべてのデータを受信した HB/ACKNACK ペアの例です。

Submessage: HEARTBEAT
... 
firstSeqNumber: 1
lastSeqNumber: 1

ハートビート シーケンス番号は 1 です。これは、単一の DataReader に関するアナウンスのみを送信したことを示します。

Submessage: ACKNACK
... 
readerSNState: 2/0:
    bitmapBase: 2
    numBits: 0

readerSNState は 2/0 です。これは、シーケンス番号 2 より前のすべてを受信して​​おり、欠落がないことを意味します。ビットマップに 0 以外の値がある場合は、DataReader が一部のデータを受信して​​いないことを示しています。

アプリケーションがすべての検出データを正しく受信していることを確認できる場合は、WireShark フィルターを使用してユーザー データのみを表示できると便利です。画像では検出データとユーザー データが強調表示されていないためです。

rtps2 ユーザー データのみの WireShark フィルター: rtps2 && (rtps2.traffic_nature == 3 || rtps2.traffic_nature == 1)

于 2013-06-03T04:25:10.177 に答える
1

これについても同様の問題がありました。以下は環境を非常に要約したものです。

  • パブリッシャー
  • 有効な加入者 (ラップトップ)
  • 稼働していない加入者 (デスクトップ)

どちらのサブスクライバーもまったく同じソフトウェアを持っていました (デスクトップは Clonezilla によるラップトップからのクローンでした) が、rtiddsspy はデスクトップの観点からは見えませんでした。ただし、逆の方法でもうまくいきました。パブリッシャー マシンの rtiddsspy はデスクトップを認識しました。ラップトップとパブリッシャーのマシンは常にうまく機能しました。ラップトップとデスクトップも (お互いのサブスクリプションを見た)

これの回避策 ( https://community.rti.com/content/forum-topic/discovery-issuesに基づく ) は、デスクトップ NIC の MTU を増やすことでした。理由は聞かないでください。でもうまくいきました。

編集: 当初、パブリッシャーの MTU はサブスクライバーよりも高い値に設定されていました。そのため、サブスクライバーの MTU をパブリッシャーの MTU と一致するように変更しました。

于 2015-08-28T15:14:01.840 に答える