2016-10-19 5 views
0

문제는 원격 PC에서 장치 관리자를 시작하고 장치 관리자 레지스터에서 registerDevice 메시지를 연결 한 10GigE 포트가있는 외부 하드웨어 장치가있는 경우입니다. 장치 관리자가 아닌 장치 관리자 PC에 연결된 외부 장치가 사용하는 10GigE 인터페이스의 IP 주소는 실제 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에 연결된 외부 장치없이 내 시나리오를 실행하는 경우
 
PC2 
    Device Manager B(GPP):192.168.5.11 
    Device Interface: 192.168.100.10 (connected to external hardware) 

, 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 Redhawk이 2.0.3 6.6 및 omniORB의 4.1
페도라 24 Redhawk이 2.0.3와 omniORB의를 다른 사람이이 문제를했고 그것에 대해 할 수있는 일이 있습니다

4.2?

답변

2

철저한 예제를 실행하려면 도커를 사용하십시오. 3 개의 터미널을 가져와 도커를 설치해야하지만 한 대의 호스트에서이 모든 작업을 수행 할 수 있습니다. 3 개의 터미널을 "도메인", "샌드 박스"및 "호스트 시스템"이라고합니다.

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

: 다른 Redhawk이 2.0.2 인스턴스를 회전, 샌드 박스 터미널에서

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

: 도메인 터미널에서

는 신선한 Redhawk이 2.0.2 인스턴스를 회전

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 다시 실행하면 현재 도메인 및 샌드 박스 인스턴스의 eth1 고유 서브넷에와 통신 할 수있는 eth0를하고있는 eth1 인터페이스를 알 수 있습니다.

당신의 IP 주소가 다를 수 있지만 나를 위해 내가 가진 :

 
Domain: 
    eth0: 172.17.0.2 
    eth1: 172.19.0.2 

Sandbox: 
    eth0: 172.17.0.3 
    eth1: 172.20.0.2 

지금 우리가 CORBA 호출에 응답하지 않는 omniNames 호스트 설정 omniORB의 연결 시간 초과 될 수있는 도메인을 구성 할 수 있습니다, 잘못된 IP 주소가 알려 지도록 endPoint를 잘못 구성하십시오.

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 

샌드 박스 시스템에서 : 도메인 시스템에서

cleanomni를 통해 도메인 시스템에서

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 

샌드 박스 컴퓨터에서 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...< 

는 /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('.') 

참고. "start"및 "stop"과 같은 호출은 구성 요소로 전달되지만 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 

을 이제 다시 샌드 박스 기계 파이썬에서 :

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를 수정하고이 실험을 다시 실행하십시오. 두 엔드 포인트가 모두 올바르게 구성 되었기 때문에 이번에는 데이터를 얻습니다.

마지막으로 endPoint를 전혀 설정하지 않으면 어떻게됩니까?(내가 생각한 것처럼) omniORB에서 sample configuration file :

기본적으로 endPoint 구성은 정의되어 있지 않습니다. 이 경우 ORB는 1 TCP 끝점을 만듭니다 마치 선 : 엔드 포인트 = GIOP : TCP :: 구성 파일에 지정된

호스트 및 포트 매개 변수 선택 사항입니다. 또는 이 누락 된 경우 ORB는 공백을 채 웁니다. 예를 들어 "giop : tcp ::"는 ORB가 임의의 tcp 포트 을 엔드 포인트로 선택하게하고 호스트 주소로 호스트의 하나의 IP 주소 인 을 선택합니다.

매우 이상한 동작이 발생할 수 있습니다. 다행히도이 예가 도움이되었고 누구나 쉽게 실행/재현 할 수 있습니다.

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

나는 내가 Wireshark를 캡처했다 전에 로그 레벨을 증가했다 : 우리는 우리가 우리의 고정 표시기 인스턴스와 고정 표시기 네트워크를 정리할 수 있습니다 완료 이제

. 이 문제가 발생하면 전체 도메인이 중단되고이 문제가 발생하는 함수로 이동합니다. 도메인 매니저와 원격 노드의 새로운 두 머신에서 소스 코드를 수정하여 디버그 문을 추가하여이 문제가 발생한 정확한 위치를 찾아 냈습니다. 아직까지 이것을 추적 할 시간이 없었지만, 프레임 워크 핵심 DomainManager_impl.cpp의 정확한 라인을 알고 있습니다. 다시 연락 할 기회가 있으면 업데이트를 게시 할 것입니다. –

+0

@SirBedevere 초기 응답을 편집하여 상황을 개선하는 데 도움이되는 예제를 제공했습니다. –

+0

우리는 하나의 도메인 매니저와 다양한 SDR이 연결된 8 개의 원격 노드가있는 네트워크를 가지고 있습니다. 일부는 RTLSDR, USRP 및 FE 인터페이스를 개발 한 일부 사용자 정의 SDR입니다. 완벽하게 작동하며 데이터를 스트리밍하고 정상적으로 할당 할 수 있습니다. 이 문제가 발생하는 네트워크 스택이 제한되어있는 10GigE 장치를 연결할 때만 문제가되는 것 같습니다. 빨리 조사해 보겠지만 새로운 장치를 연결하기 전에는 redhawk 도메인 설정에 문제가 없습니다. 장치가 연결된 노드는 항상 잘못된 인터페이스를 등록한다는 점에서 중요하지 않습니다. –