Диспетчеры устройств на машинах с внешними устройствами 10GigE, вызывающими проблемы

Question

У меня возникает проблема, когда я запускаю диспетчер устройств на удаленном ПК, и у меня подключено внешнее аппаратное устройство с портами 10GigE. Сообщение registerDevice от диспетчера устройств регистрирует IP-адрес интерфейса 10GigE, используемого подключенным внешним устройством. к компьютеру диспетчера устройств вместо компьютеров диспетчера устройств фактический IP-адрес.

Настройка сети:

PC1
  Менеджер домена:192.168.5.10
  Диспетчер устройств A(GPP):192.168.5.10 (на том же компьютере, что и диспетчер домена)

PC2
  Диспетчер устройств B(GPP):192.168.5.11 
  Интерфейс устройства: 192.168.100.10 (подключен к внешнему оборудованию)

Если я запускаю свой сценарий без подключения внешнего устройства к ПК2, диспетчер устройств на этом компьютере регистрируется с IP-адресом: 192.168.5.11. Если я подключаю внешнее оборудование к ПК2, и интерфейс 10GigE подключается, диспетчер устройств регистрируется с IP-адресом: 192.168.100.10, и весь домен REDHAWK зависает.

Я проверил эту проблему, просматривая логи wireshark на ПК1 и ПК2. У нас не было этой проблемы при подключении устройств UHD, отличных от устройств UHD с портами 10GigE. Важно отметить, что на данный момент никакие устройства или диспетчеры устройств для них не используются. Устройства просто включены, и запускается узел только с GPP. В случае UHD и внешнего оборудования оба порта 10GigE являются пользовательскими и реализуют ограниченный интерфейс 10GigE. При подключении к другому ПК с 10GigE вместо устройства с ограниченной реализацией 10GigE работает диспетчер устройств.

Если я подключу устройство 10GigE после того, как узел активен, устройства FE 2.0 будут работать отлично. Этот сценарий, однако, не будет работать для нас, так как физическое обхода и включение устройства не подходит для нашего варианта использования. Кроме того, при работе с устройствами в домене, запущенном на том же компьютере, этих проблем не возникает. Эта проблема возникает только в том случае, если домен находится на удаленном компьютере.

В настоящее время мы работаем со следующими версиями REDHAWK, и у них одна и та же проблема.

CentOS 6.6 с REDHAWK 2.0.3 и OmniORB 4.1
Fedora 24 с REDHAWK 2.0.3 и OmniORB 4.2

У кого-нибудь еще была такая проблема, и могу ли я что-нибудь с этим сделать?

Answer 1

Давайте используем Docker, чтобы выполнить тщательный пример. Вам нужно будет вызвать 3 терминала и установить докер, но мы можем сделать все это на одном хосте. Я буду называть эти 3 терминала "Доменом", "Песочницей" и "Хост-системой".

В доменном терминале раскрутите свежий экземпляр 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-адреса каждого и записать их. Обратите внимание, что они находятся в одной подсети и могут пинговать друг друга.

Теперь мы можем эмулировать ваши порты 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

Вернуться в домен и песочницу перезапустить терминалы ifconfigобратите внимание, что теперь у вас есть интерфейс eth0 и eth1, где eth1 в экземпляре Domain и Sandbox находятся в уникальных подсетях и не могут обмениваться данными.

Ваши IP-адреса могут отличаться, но у меня есть:

Домен:
  eth0: 172.17.0.2
  eth1: 172.19.0.2

Песочница:
  eth0: 172.17.0.3
  eth1: 172.20.0.2

Теперь я настрою домен в качестве хоста omniNames, установлю тайм-аут соединения omniORB, чтобы мы не зависали при вызовах corba, и НЕПРАВИЛЬНО сконфигурирую конечную точку, чтобы объявить НЕПРАВИЛЬНЫЙ 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

На Домене машины запустите omniNames и события через cleanomni который также очистит любое устаревшее состояние:

cleanomni

На песочнице беги машина nameclt list для просмотра объектов omniORB. Обратите внимание, что это не работает, поскольку адрес конечной точки, объявленный для домена, неверен. Если мы войдем в систему /etc/omniORB.cfg через traceLevel=40 мы даже можем увидеть в сообщении неправильный 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 и запустите cleanomni очистить все старые ссылки и перезапустить все службы. Из терминала песочницы вы можете теперь правильно запустить nameclt list,

На доменном терминале запускай домен используя nodeBooter -D и из терминала песочницы подключитесь к домену через python и подтвердите, что вы можете взаимодействовать с ним, как и ожидалось.

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

Обратите внимание, что до сих пор мы только совершали звонки из Песочницы в Домен, поэтому имеет значение только объявленная конечная точка Доменного компьютера. Вызовы типа "старт" и "стоп" выполняются от вас к компоненту, а вызовы типа pushPacket - от компонента к вам. Мы можем подтвердить это, подключив SigGen на доменной машине к 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()

Вы не должны получать данные в приемнике, так как машина-песочница объявляет неправильную конечную точку. Теперь выйдите из python, исправьте конечную точку в экземпляре Sandbox и повторите этот эксперимент. На этот раз вы получите данные, поскольку обе конечные точки правильно настроены.

И наконец, что произойдет, если вы вообще не установите конечную точку? (Как я понимаю, это был твой случай) Из примера файла конфигурации omniORB:

По умолчанию конфигурация endPoint не определена. В этом случае ORB создаст только 1 конечную точку tcp, как если бы строка: endPoint = giop:tcp:: указана в файле конфигурации

а также

Параметр host и port не обязателен. Если один или оба отсутствуют, ORB заполняет пробел. Например, "giop:tcp::" заставит ORB выбрать произвольный порт tcp в качестве конечной точки и выберет один IP-адрес хоста в качестве адреса хоста.

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

Теперь, когда мы закончили, мы можем очистить наши докеры и сети докеров с помощью:

docker rm -f domain sandbox
docker network rm bad_net_1 bad_net_2