2016-10-19 2 views
0

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

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

 
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) 

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

Я проверил эту проблему, проверив журналы проводки на PC1 и PC2. У нас не было этой проблемы при подключении устройств 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

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

ответ

2

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

Если вы не знакомы с докером, эти два экземпляра докеров имеют уникальные файловые системы, память и сеть. Сделайте ifconfig, чтобы проверить IP-адреса каждого и записать их. Обратите внимание, что они находятся в одной подсети и могут пинговать друг друга.

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

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 на экземпляре домена и песочницы на уникальных подсетях и не может общаться.

Ваш 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 звонки, и НЕПРАВИЛЬНО настроить конечную точку, чтобы рекламировать WRONG 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. Обратите внимание, что это не работает, поскольку адрес endPoint, рекламируемый для домена, неверен. Если мы запустим ведение журнала в /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 исправить ENDPOINT в /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('.') 

Обратите внимание, что до сих пор мы лишь делаем звонки из песочницы в домен так только рекламируемое ENDPOINT из машины домена имеет значение. Такие вызовы, как «старт» и «остановка», выполняются от вас до компонента, но вызовы типа pushPacket производятся из компонента для вас. Мы можем подтвердить это, подключив SigGen на машине домена к HardLimit на машине Sandbox. Помните, что сейчас машина домена настроена правильно, а машина для песочницы - нет.

На машине домена, остановить домен и выполнить следующую команду для установки сигнала и запуска домена с ГПП:

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

Теперь обратно в песочнице машине в питоне:

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, исправьте endPoint в экземпляре Sandbox и повторите этот эксперимент. На этот раз вы получите данные, так как оба конечных точки настроены правильно.

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

По умолчанию не определена конфигурация конечной точки. В этом случае ОРБ создаст только 1 TCP конечную точку, как будто линия: ENDPOINT = GIOP: ТСР :: задается в конфигурационном файле

и

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

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

Теперь, когда мы закончили, мы можем очистить наши экземпляры Докер и Докер сети с:

docker rm -f domain sandbox 
docker network rm bad_net_1 bad_net_2 
+0

Я сделал увеличить уровень журнала, прежде чем я сделал Wireshark захватывает. Весь домен зависает, когда это происходит, и это привело меня к функции, в которой эта проблема возникает. Я закончил модификацию исходного кода на двух новых машинах как на диспетчере домена, так и на удаленном узле, чтобы добавить дополнительные инструкции для отладки, чтобы выяснить, где именно происходит эта проблема. У меня еще не было времени отслеживать это, но я знаю точную строку в фреймворке coreManager_impl.cpp, на котором он висит. Я опубликую обновление, если у меня появится возможность вернуться к нему. –

+0

@SirBedevere Я отредактировал свой первоначальный ответ и представил пример, который, надеюсь, поможет вашей ситуации. –

+0

У нас есть сеть с одним менеджером домена и 8 удаленных узлов с множеством SDR подключенных. Некоторые из них - RTLSDR, USRP и некоторые пользовательские SDR, для которых мы разработали интерфейсы FE. Он работает отлично, и мы можем передавать данные и выделять их среди них обычно. Это только кажется проблемой, когда мы подключаем устройство 10GigE с ограниченным сетевым стеком, которое возникает в этой проблеме. Я скоро углубится в это, но у нас не было проблем с нашей настройкой домена redhawk, пока мы не подключили к нему более новые устройства. Узел, к которому подключено устройство, не имеет значения, он всегда регистрирует неверный интерфейс. –

Смежные вопросы