[omniORB] OmniOrb uses wrong network adapter

[Peter Danziger]

Hi,



we are
using OmniOrb 4.1.6 on Windows Server 2003 and 2008R2. In the last weeks, we
observed a problem with the name resolution of CORBA calls. The involved
machines have two network adapters, one for the ?normal? network and one for a
management network. In the management network, the IP packets are blocked by a
firewall. The result is, that the clients? nslookup for the server machine
returns two IP addresses. One works, the other doesn?t. In the Windows configuration
the ?normal? network adapter is at the first, the other adapter is at the
second position. So the OmniOrb most of the time uses the working adapter.



We have an
object reference of a CORBA service which is running on a different machine and
we are doing a call every few seconds. Most of the time, the calls work. But
from time to time, the OmniOrb uses the adapter of the management network, and
the call fails.



Why does
OmniOrb switch the IP address between different calls on the same CORBA object?


Is it
possible to enforce the usage of a specific network adapter?



Any help
appreciated.



Regards,

Peter


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20130409/d7b6fa9a/attachment.html>

[Peter Danziger]

I forgot to mention, that I'm using a corbaloc to access the service, e.g. "corbaloc::wgvcxpa1:9942/drsm480". The "wgvcxpa1" is resolved to the wrong IP address.

Regards,
Peter

From: p_danziger at hotmail.com
To: omniorb-list at omniorb-support.com
Date: Tue, 9 Apr 2013 17:49:19 +0200
Subject: [omniORB] OmniOrb uses wrong network adapter






Hi,



we are
using OmniOrb 4.1.6 on Windows Server 2003 and 2008R2. In the last weeks, we
observed a problem with the name resolution of CORBA calls. The involved
machines have two network adapters, one for the ?normal? network and one for a
management network. In the management network, the IP packets are blocked by a
firewall. The result is, that the clients? nslookup for the server machine
returns two IP addresses. One works, the other doesn?t. In the Windows configuration
the ?normal? network adapter is at the first, the other adapter is at the
second position. So the OmniOrb most of the time uses the working adapter.



We have an
object reference of a CORBA service which is running on a different machine and
we are doing a call every few seconds. Most of the time, the calls work. But
from time to time, the OmniOrb uses the adapter of the management network, and
the call fails.



Why does
OmniOrb switch the IP address between different calls on the same CORBA object?


Is it
possible to enforce the usage of a specific network adapter?



Any help
appreciated.



Regards,

Peter



_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20130409/0d52135d/attachment.html>

[Peter Danziger]

Hi,

I forgot to mention, that we are using corbaloc to access the service,
e.g. "corbaloc::wgvcxpa1:9942/drsm480". The "wgvcxpa1" is resolved to
the wrong IP address.

Regards,
Peter

From: p_danziger at hotmail.com
To: omniorb-list at omniorb-support.com
Subject: OmniOrb uses wrong network adapter
Date: Tue, 9 Apr 2013 17:49:19 +0200






Hi,



we are
using OmniOrb 4.1.6 on Windows Server 2003 and 2008R2. In the last weeks, we
observed a problem with the name resolution of CORBA calls. The involved
machines have two network adapters, one for the ?normal? network and one for a
management network. In the management network, the IP packets are blocked by a
firewall. The result is, that the clients? nslookup for the server machine
returns two IP addresses. One works, the other doesn?t. In the Windows configuration
the ?normal? network adapter is at the first, the other adapter is at the
second position. So the OmniOrb most of the time uses the working adapter.



We have an
object reference of a CORBA service which is running on a different machine and
we are doing a call every few seconds. Most of the time, the calls work. But
from time to time, the OmniOrb uses the adapter of the management network, and
the call fails.



Why does
OmniOrb switch the IP address between different calls on the same CORBA object?


Is it
possible to enforce the usage of a specific network adapter?



Any help
appreciated.



Regards,

Peter


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20130409/9e8ae610/attachment.html>

[Duncan Grisby]

On Tue, 2013-04-09 at 18:28 +0200, Peter Danziger wrote:

> I forgot to mention, that we are using corbaloc to access the service,
> e.g. "corbaloc::wgvcxpa1:9942/drsm480". The "wgvcxpa1" is resolved to
> the wrong IP address.

omniORB gives that name to getaddrinfo() or a similar system call to
resolve the name. If a name resolves to multiple addresses, it's up to
the machine's DNS setup as to what order the results come back. If
connecting to an address fails, omniORB actually tries to connect to
other addresses in turn until one works, except that often the only way
to know that a connection has failed is that it times out, by which time
it's too late to try the other addresses.

Every time omniORB needs to open a connection, it re-resolves the name,
so if the name resolution changes, different connection attempts to the
same name can lead to different addresses. omniORB will open a new
connection either if it previously closed the connection because it was
idle, or because it wants to make a concurrent call while another call
is already in progress.

The answer about forcing omniORB to use the address you want ought to be
to use the clientTransportRules configuration, and only allow it to
connect to the correct address. Unfortunately, the transport rules are
evaluated before the name lookup, so they can't save you.

I'll look into processing the transport rules on the resolved names as a
way to avoid this problem. As an alternative, are you able to resolve
the name yourself, rather than using the name in the corbaloc? That way
you'll be able to pick the correct address for yourself.

Cheers,

Duncan.

--
-- Duncan Grisby --
-- duncan at grisby.org --
-- http://www.grisby.org --

[Peter Danziger]

Duncan,

thank you very much for your comprehensive answer. Yes, I have already tried to do the
address resolution myself, but it didn't help.

This is the result if I use "corbaloc::10.1.2.31:9901/Analyzer1":

LocateRequest to remote: key<Analyzer1>'
Client attempt to connect to giop:tcp:169.254.95.120:9901'
Failed to connect (no peer name): 169.254.95.120'
Switch rope to use address giop:tcp:169.254.95.12U:9901'
Unable to open new connection: giop:tcp:169.254.95.12U:9901'
throw giopStream: :CommFai|ure From giopStream.cc:1153(0,NO,TRANSIENT_ConnectFailed)'
throw TRANSIENT From omniObjReF.cc:1135 (NO,TRANSIENT_ConnectFailed)'

The Orb seems to do a reverse lookup get the wrong (169.254.95.120) from the right (10.1.2.31) IP address.

Regards,
Volker

> Subject: Re: [omniORB] OmniOrb uses wrong network adapter
> From: duncan at grisby.org
> To: p_danziger at hotmail.com
> CC: omniorb-list at omniorb-support.com
> Date: Tue, 30 Apr 2013 18:17:30 +0100
>
> On Tue, 2013-04-09 at 18:28 +0200, Peter Danziger wrote:
>
> > I forgot to mention, that we are using corbaloc to access the service,
> > e.g. "corbaloc::wgvcxpa1:9942/drsm480". The "wgvcxpa1" is resolved to
> > the wrong IP address.
>
> omniORB gives that name to getaddrinfo() or a similar system call to
> resolve the name. If a name resolves to multiple addresses, it's up to
> the machine's DNS setup as to what order the results come back. If
> connecting to an address fails, omniORB actually tries to connect to
> other addresses in turn until one works, except that often the only way
> to know that a connection has failed is that it times out, by which time
> it's too late to try the other addresses.
>
> Every time omniORB needs to open a connection, it re-resolves the name,
> so if the name resolution changes, different connection attempts to the
> same name can lead to different addresses. omniORB will open a new
> connection either if it previously closed the connection because it was
> idle, or because it wants to make a concurrent call while another call
> is already in progress.
>
> The answer about forcing omniORB to use the address you want ought to be
> to use the clientTransportRules configuration, and only allow it to
> connect to the correct address. Unfortunately, the transport rules are
> evaluated before the name lookup, so they can't save you.
>
> I'll look into processing the transport rules on the resolved names as a
> way to avoid this problem. As an alternative, are you able to resolve
> the name yourself, rather than using the name in the corbaloc? That way
> you'll be able to pick the correct address for yourself.
>
> Cheers,
>
> Duncan.
>
> --
> -- Duncan Grisby --
> -- duncan at grisby.org --
> -- http://www.grisby.org --
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20130508/5bfaa5d7/attachment.html>