Python program can not launch redhawksdr component with external network connected

Question

I am a new user of RedHawkSDR and have written a python program under CentOS that controls a "SigGen" component. It works if there is no network connection except the loopback, but fails if I connect a wired network (listed as System ethO).

I do not specify any IP address in the python program, and the omniORB.cfg explicitly lists the loopback address as shown below, since there have been comments in other posts warning against using "localhost"

traceLevel=10
InitRef = NameService=corbaname::127.0.0.1:2809
supportBootstrapAgent = 1
InitRef = EventService=corbaloc::127.0.0.1:11169/omniEvents

Comparing the ominORB data that prints to the screen from the two cases:

Last identical step ==> "omniORB: AsyncInvoker: thread id=2 has started. Total threads=1

Next step:

for working (no network) ==> "omniORB: Adding root<0> (activating) to object table

for nonworking (network connected) ==> "omniORB: Removing root<0> (etherealizing) from object table

full message stream for network connected case==>

[aecom@crancentos1 Desktop]$ python pTrigger.py keyboard 5555 5050
omniORB: Version: 4.1.6
omniORB: Distribution date: Fri Jul  1 15:57:00 BST 2011 dgrisby
omniORB: Information: the omniDynamic library is not linked.
omniORB: omniORBpy distribution date: Fri Jul  1 14:52:31 BST 2011 dgrisby
omniORB: Initialising incoming endpoints.
omniORB: Attempt to set socket to listen on IPv4 and IPv6.
omniORB: Starting serving incoming endpoints.
omniORB: AsyncInvoker: thread id = 2 has started. Total threads = 1
/usr/local/redhawk/core/lib/python/ossie/utils/sb/domainless.py:863:
DeprecationWarning: Component class is deprecated. Use launch() method instead.
warnings.warn('Component class is deprecated. Use launch() method instead.', DeprecationWarning)
omniORB: Adding root<0> (activating) to object table.
omniORB: Creating ref to local: root<0>
target id      : IDL:omg.org/CORBA/Object:1.0
most derived id: IDL:omg.org/CosNaming/NamingContextExt:1.0
omniORB: Creating Python ref to local: root<0>
target id      : IDL:omg.org/CosNaming/NamingContextExt:1.0
most derived id: IDL:omg.org/CosNaming/NamingContextExt:1.0
omniORB: Version: 4.1.6
omniORB: Distribution date: Fri Jul  1 15:57:00 BST 2011 dgrisby
omniORB: Information: the omniDynamic library is not linked.
omniORB: omniORBpy distribution date: Fri Jul  1 14:52:31 BST 2011 dgrisby
omniORB: Initialising incoming endpoints.
omniORB: Attempt to set socket to listen on IPv4 and IPv6.
omniORB: Starting serving incoming endpoints.
omniORB: AsyncInvoker: thread id = 2 has started. Total threads = 1
omniORB: Removing root<0> (etherealising) from object table
Traceback (most recent call last):
File "pTrigger.py", line 118, in <module>
sigGen=sb.Component("SigGen")
File "/usr/local/redhawk/core/lib/python/ossie/utils/sb/domainless.py", line 872, in __new__
raise AssertionError, "Unable to launch component: '%s'" % e
AssertionError: Unable to launch component: 'resource 'SigGen_2' did not register with virtual environment'

Is there a system variable/token/thing that is "127.0.0.1" in the loopback case that switches to the network IP address when the system makes the network connection, which then confuses omniORB?

Any constructive guidance would be appreciated...

Best Regards,

Brad Meyer

ADDITIONAL DATA // Firewall is off=============================

// Smoking gun ?===============================

 omniORB: omniORBpy distribution date: Fri Jul  1 14:52:31 BST 2011 dgrisby
 omniORB: Python thread state scavenger start.
 omniORB: Initialising incoming endpoints.
 omniORB: Instantiate endpoint 'giop:tcp:127.0.0.1:'
 omniORB: Explicit bind to host 127.0.0.1.
 omniORB: Bind to address 127.0.0.1 ephemeral port.
 omniORB: Publish specification: 'addr'
 omniORB: Try to publish 'addr' for endpoint giop:tcp:127.0.0.1:46877
 omniORB: Publish endpoint 'giop:tcp:127.0.0.1:46877'
 omniORB: Starting serving incoming endpoints.
 omniORB: AsyncInvoker: thread id = 2 has started. Total threads = 1
 omniORB: giopRendezvouser task execute for giop:tcp:127.0.0.1:46877
 ==>omniORB: SocketCollection idle. Sleeping.
 omniORB: State root<0> (active) -> deactivating

// ifconfig shows loopback running ================== Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:302 errors:0 dropped:0 overruns:0 frame:0 TX packets:302 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:26197 (25.5 KiB) TX bytes:26197 (25.5 KiB)

// ping 127.0.0.1 works ===========================================

// netstat -tulpn SHOWS OMIN CONNECTED TO SOME PORTS========================================= Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:42451 0.0.0.0:* LISTEN 2409/omniEvents
tcp 0 0 REDACTED FOR POST 0.0.0.0:* LISTEN 2617/dnsmasq
tcp 0 0 0.0.0.0:50517 0.0.0.0:* LISTEN 2067/rpc.statd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 2254/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 2098/cupsd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 2346/master
tcp 0 0 127.0.0.1:42251 0.0.0.0:* LISTEN 2022/omniNames
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1902/rpcbind
tcp 0 0 :::39409 :::* LISTEN 2067/rpc.statd
tcp 0 0 :::22 :::* LISTEN 2254/sshd
tcp 0 0 ::1:631 :::* LISTEN 2098/cupsd
tcp 0 0 ::1:25 :::* LISTEN 2346/master
tcp 0 0 :::2809 :::* LISTEN 2022/omniNames
tcp 0 0 :::11169 :::* LISTEN 2409/omniEvents
tcp 0 0 :::111 :::* LISTEN 1902/rpcbind

DrewC · Accepted Answer · 2015-03-25T14:34:35.373

When multiple network interfaces are available, omniORB arbitrarily chooses one of them for publishing object references (see part 5 in http://omniorb.sourceforge.net/omni41/omniNames.html). In your case, it seems to be grabbing eth0 when you are network-connected, which is not playing well with omniNames for whatever reason (could be a firewall setting).

To get around this, I recommend adding the following line to your /etc/omniORB.cfg file:

endPoint = giop:tcp:127.0.0.1:

This will force omniNames to always use the local loopback instead of eth0. Given your current omniORB.cfg settings, I am assuming using localhost is acceptable for your application. If this is not the case (i.e., you really need to use eth0 instead of localhost), we will need to find the root cause of why omniNames is having trouble with your eth0 interface.

Clarification (since I can't use line breaks in the comments section):

Try turning the log level up to 40 and see if anything useful shows up between these log lines:

omniORB: AsyncInvoker: thread id = 2 has started. Total threads = 1
omniORB: Removing root<0> (etherealising) from object table

I'm having trouble reproducing your problem. In my working case, I get something like this:

omniORB: AsyncInvoker: thread id = 2 has started. Total threads = 1
omniORB: giopRendezvouser task execute for giop:tcp:127.0.0.1:60625
omniORB: Adding root<0> (activating) to object table.

I'm curious as to see if the IP on the second line looks suspicious for you.

Drew: Thanks for your quick reply, but the proposed solution did not work (although it fit what I anticipated the answer would be), but you are correct that I can always use loopback. Also tried shutting down completely and restarting before responding. I have left it in the CFG file. Are there any other things I can try or additional data that would be helpful in diagnosing this? — Brad Meyer, Mar 24 '15 at 19:25
See my "clarification" in the answer (formatting was terrible in the comments field). — DrewC, Mar 25 '15 at 14:36
Drew: I appreciate your help, given that I am very stuck. I have also added data via edit. For some, there the loopback appears idle. I did some basic checks, and do not see anything amiss. Thoughts? — Brad Meyer, Mar 26 '15 at 14:25
I worked on this for a week… but finally found the solution. In the etc/host file, I added a line “ 127.0.0.1 ‘ComputerName’ ” and the problem went away. — Brad Meyer, Mar 27 '15 at 19:12

score 1 · Answer 2 · answered Mar 27 '15 at 19:13

1

I worked on this for a week… but finally found the solution as DrewC pointed me in new directions to look.

In the etc/host file, I added a line “ 127.0.0.1 ‘ComputerName’” and the problem went away.

Brad

answered Mar 27 '15 at 19:13

Brad Meyer

55
5

There are a number of issues you can run into if the IP and hostname don't map to each other. Just FYI, DNS server misconfiguration can cause similar problems. – Daniel Wille Jun 29 '15 at 19:55

Python program can not launch redhawksdr component with external network connected

2 Answers2