Question

我遇到的问题是当我在远程PC上启动设备管理器并且我有一个连接了10GigE端口的外部硬件设备时，来自设备管理器的registerDevice消息注册了10GigE接口的IP地址。外部设备连接到设备管理器PC而不是设备管理器加工实际IP地址。

网络设置：

PC1
  Domain Manager:192.168.5.10
  Device Manager A(GPP):192.168.5.10 (on same machine as the domain manager)

PC2
  Device Manager B(GPP):192.168.5.11 
  Device Interface: 192.168.100.10 (connected to external hardware)

如果我在没有连接到PC2的外部设备的情况下运行我的场景，那台机器上的设备管理器将注册IP地址：192.168.5.11。如果我将外部硬件连接到PC2并且10GigE接口联机，则设备管理器将注册IP地址：192.168.100.10并且整个REDHAWK域挂起。

我通过PC1和PC2上的wireshark日志验证了这个问题。当使用10GigE端口连接UHD设备以外的UHD设备时，我们没有遇到此问题。重要的是要注意，此时实际上没有使用它们的设备或设备管理器。设备刚刚启动，并且启动仅包含GPP的节点。在UHD和外部硬件的情况下，两个10GigE端口都是定制的，并实现了有限的10GigE接口。当使用10GigE而不是具有有限10GigE实现的设备连接到另一台PC时，设备管理器可以正常工作。

如果在节点激活后连接10GigE设备，FE 2.0设备可以正常工作。但是，这种情况对我们不起作用，因为物理走过并打开设备电源对我们的用例无效。此外，在同一台计算机上启动的域上运行设备不会出现这些问题。仅当域位于远程PC上时才会出现此问题。

我们目前正在使用以下REDHAWK版本，但两者都有同样的问题。

CentOS 6.6 with REDHAWK 2.0.3和OmniORB 4.1
带有REDHAWK 2.0.3和OmniORB 4.2的Fedora 24

有没有其他人遇到这个问题，我能做些什么吗？

Answer 1

让我们使用docker来运行一个完整的例子。您需要调出3个终端并安装了docker，但我们可以在一台主机上完成所有这些操作。我将3个终端称为“域”，“沙箱”和“主机系统”。

在Domain Terminal中，启动一个新的redhawk 2.0.2实例：

docker run -it --name=domain axios/redhawk:2.0.2 bash -l

在沙盒终端中，启动另一个redhawk 2.0.2实例：

docker run -it --name=sandbox axios/redhawk:2.0.2 bash -l

如果您不熟悉docker，这两个docker实例具有唯一的文件系统，内存和网络。执行ifconfig检查每个IP地址并记下它们。请注意，它们位于同一子网上，可以相互ping通。

我们现在可以通过创建两个无法相互联系的新网络来模拟您的10GigE端口。在主机终端上使用docker创建两个单独的伪网络并将它们分配给容器实例。

docker network create -o "com.docker.network.bridge.host_binding_ipv4"="1.1.1.1" bad_net_1
docker network create -o "com.docker.network.bridge.host_binding_ipv4"="2.2.2.2" bad_net_2
docker network connect bad_net_1 domain
docker network connect bad_net_2 sandbox

返回Domain和Sandbox终端重新运行ifconfig，请注意您现在有一个eth0和eth1接口，其中Domain和Sandbox实例上的eth1位于唯一的子网上且无法通信。

您的IP地址可能有所不同，但对我来说，我有：

Domain:
  eth0: 172.17.0.2
  eth1: 172.19.0.2

Sandbox:
  eth0: 172.17.0.3
  eth1: 172.20.0.2

我现在将域配置为omniNames主机，设置omniORB连接超时，以便我们不挂起corba调用，并且不正确地配置endPoint以便公布错误的IP地址。

在域名计算机上：

sudo tee /etc/omniORB.cfg << EOF
InitRef = NameService=corbaname::172.17.0.2:2809
supportBootstrapAgent = 1
InitRef = EventService=corbaloc::172.17.0.2:11169/omniEvents
endPoint = giop:tcp:172.19.0.2:
serverCallTimeOutPeriod = 5000
clientConnectTimeOutPeriod = 5000
clientCallTimeOutPeriod = 5000
EOF

在沙盒机器上：

sudo tee /etc/omniORB.cfg << EOF
InitRef = NameService=corbaname::172.17.0.2:2809
supportBootstrapAgent = 1
InitRef = EventService=corbaloc::172.17.0.2:11169/omniEvents
endPoint = giop:tcp:172.20.0.2:
serverCallTimeOutPeriod = 5000
clientConnectTimeOutPeriod = 5000
clientCallTimeOutPeriod = 5000
EOF

在域名计算机上通过cleanomni启动omniNames和事件，这也将清除任何陈旧状态：

cleanomni

在沙盒计算机上运行nameclt list以查看omniORB对象。请注意，它不起作用，因为为域通告的endPoint地址是错误的。如果我们通过traceLevel=40登录/etc/omniORB.cfg，我们甚至可以在邮件中看到错误的IP地址。

omniORB: inputMessage: from giop:tcp:172.17.0.2:2809 236 bytes
omniORB:
4749 4f50 0100 0101 e000 0000 0000 0000 GIOP............
0400 0000 0000 0000 0000 0000 2a00 0000 ............*...
4944 4c3a 6f6d 672e 6f72 672f 436f 734e IDL:omg.org/CosN
616d 696e 672f 4269 6e64 696e 6749 7465 aming/BindingIte
7261 746f 723a 312e 3000 0000 0100 0000 rator:1.0.......
0000 0000 9400 0000 0101 0200 0b00 0000 ................
3137 322e 3139 2e30 2e32 0000 23ae 0000 172.19.0.2..#...
0e00 0000 ff00 bb05 0a58 0100 003c 0000 .........X...<..
0002 0000 0400 0000 0000 0000 0800 0000 ................
0100 0000 0054 5441 0100 0000 1c00 0000 .....TTA........
0100 0000 0100 0100 0100 0000 0100 0105 ................
0901 0100 0100 0000 0901 0100 0300 0000 ................
1600 0000 0100 0000 0b00 0000 3137 322e ............172.
3137 2e30 2e32 0000 f90a 0000 0354 5441 17.0.2.......TTA
0800 0000 bb05 0a58 0100 003c           .......X...<

在域终端上，使用vim或emacs修复/etc/omniORB.cfg中的endPoint并运行cleanomni以清除所有旧引用并重新启动omni服务。从沙箱终端，您现在可以正常运行nameclt list。

在域终端上使用nodeBooter -D启动域，并从沙箱终端通过python连接到域，并确认您可以按预期与其进行交互。

>>> from ossie.utils import redhawk
>>> dom = redhawk.attach('REDHAWK_DEV')
>>> dom.name
'REDHAWK_DEV'
>>> fs = dom.fileManager
>>> fs.list('.')

请注意，到目前为止，我们只是从Sandbox调用域到域，因此只有域机的广告端点才有意义。从“开始”和“停止”这样的调用是由您制作成一个组件，但像pushPacket这样的调用是由组件制作出来的。我们可以通过将Domain Machine上的SigGen连接到Sandbox机器上的HardLimit来确认这一点。请记住，现在正确配置了域计算机，而沙箱计算机则没有。

在域计算机上，停止域并运行以下命令以安装波形并使用GPP启动域：

sudo yum install -y rh.basic_components_demo
nodeBooter -D -d /var/redhawk/sdr/dev/nodes/DevMgr_12ef887a9000/DeviceManager.dcd.xml

现在回到python中的沙箱机器：

from ossie.utils import redhawk, sb
import time
dom = redhawk.attach('REDHAWK_DEV')
app = dom.createApplication('/waveforms/rh/basic_components_demo/basic_components_demo.sad.xml')
siggen = app.comps[0]
siggen.start()
hardlimit = sb.launch('rh.HardLimit')
sink = sb.DataSink()
hardlimit.connect(sink)
siggen.connect(hardlimit)
sb.start()
time.sleep(1)
sink.getData()

您应该在接收器中没有数据，因为沙箱机器会通告错误的endPoint。现在退出python修复Sandbox实例上的endPoint并重新运行此实验。这次您获取数据，因为两个endPoints都已正确配置。

最后，如果您根本没有设置endPoint会发生什么？（正如我想象的那样）来自omniORB sample configuration file：

默认情况下，未定义任何endPoint配置。在这种情况下 ORB将只创建1个tcp端点，就像该行一样： endPoint = giop：tcp :: 在配置文件中指定

和

host和port参数是可选的。如果是或两者都缺失，ORB填空。例如， “giop：tcp ::”将导致ORB选择一个任意的tcp端口作为端点，它将选择一个主机的IP地址作为主持人地址。

所以你可能会得到非常奇怪的行为。希望这个例子有所帮助，并且很容易让每个人都能够完成/重现。

现在我们已经完成了，我们可以使用以下方法清理docker实例和docker网络。

docker rm -f domain sandbox
docker network rm bad_net_1 bad_net_2

具有外部10GigE设备的计算机上的设备管理器导致问题

1 个答案: