[Ace-users] NamingService behind proxy not working as expected

[Manuel Castro]

Thanks Johnny, it worked adding hostname_in_ior to the server process.

Now that this is working, a new issue has come up, related to the
above issue.
I lookup chapter 27 in the TAO book and checked out this forum, but
couldn't find anything.

When an external client connects to the NotificationService,
everything goes ok, but when invokes connect_structured_push_consumer,
the NotificationService gets the following sniffed frame:

GIOP............
...........#....
NUT...G.........
................
...!connect_stru
ctured_push_cons
umer..........G.
...5IDL:omg.org/
CosNotifyComm/St
ructuredPushCons
umer:1.0........
.......H........
192.168.1.3..1..
....6216488223/.
.(...$@.+.......
............JAC.


so client sends its internal IP, so NotificationService does like
this:

TAO (5392|5972) - IIOP_Connector::make_connection, to
<192.168.1.3:2609> which should block
TAO (5392|5972) - Transport_Connector::wait_for_connection_completion,
going to wait for connection completion on transport[22181436]
TAO (5392|5972) - Leader_Follower[22181436]::wait_for_event, (leader)
enter reactor event loop



Should it be configured at NotificationService side or at client side?
Should notification service take detected external IP instead of sent
internal IP? How is configured this?
Any previous similar experience?

Thanks in advance again.

Manuel Castro





On Feb 12, 1:17 pm, "Johnny Willemsen" <jwillem... at remedy.nl> wrote:
> hi,
>
> Try to add hostname_in_ior also for your real server.
>
> Regards,
>
> Johnny Willemsen
> Remedy IT
> Postbus 101
> 2650 AC  Berkel en Rodenrijs
> The Netherlandswww.theaceorb.nl/www.remedy.nl
>
> *** Integrated compile and test statistics seehttp://scoreboard.theaceorb.nl***
> *** Commercial service and support for ACE/TAO/CIAO             ***
> *** Seehttp://www.theaceorb.nl/en/support.html                ***
>
> "ManuelCastro" <castro.man... at gmail.com> wrote in message
>
> <news:2680a8e8-7a5a-4d26-9369-c98988a28fa0 at 1g2000hsl.googlegroups.com>...
>
> > Hi,
> >  we've got a problem with a NamingService accessed from an external
> > client. I'm sure it's not a TAO bug, but a misconfiguration of ours.
> > We bought the "TAO Developer's Guide 1.4a", but we couldn't find the
> > solution.
> > Any help will be welcome.
> > Thanks in advance.
> >ManuelCastro
>
> >    TAO VERSION: 1.5
> >     ACE VERSION: 5.5
>
> >     HOST MACHINE and OPERATING SYSTEM: Windows2003 Server SP2
>
> >     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
> > WindowsXP Prof.2002 SP2
> >     COMPILER NAME AND VERSION (AND PATCHLEVEL): VC++2005 8.0.50727.762
> > (SP.050727-7600)
>
> >     THE $ACE_ROOT/ace/config.h FILE
> >     #include "ace/config-win32.h"
> >     #define ACE_HAS_VERSIONED_NAMESPACE 0
> >     #define ACE_HAS_STANDARD_CPP_LIBRARY 1
> >     #define ACE_MUST_HELP_DLOPEN_SEARCH_PATH 1
>
> >     AREA/CLASS/EXAMPLE AFFECTED: NamingService
>
> >     DOES THE PROBLEM AFFECT:
> >         COMPILATION? No
> >         LINKING? No
> >         EXECUTION? Yes, TAO
> >         OTHER (please specify)?
>
> >     SYNOPSIS:
> >     Host name supplied in IORs is not always the expected one
>
> >     DESCRIPTION:
> >     A CORBA client application connects from outside of our network.
> >     NamingService is running as a service, at machine 1.2.3.4 with the
> > following registry entry for "TaoNamingServiceOptions" key:
> >     -m 0 -ORBListenEndpoints
>
> iiop://external.domain.es:15000/portspan=299&hostname_in_ior=external.domain
> .es
>
> >     All traffic to external.domain.es is redirected to machine
> > 1.2.3.4.
> >     Wireshark is sniffing at 1.2.3.4 host.
> >     When client application connects, and sniffing GIOP protocolo, we
> > get a first response:
> >     IOR::type_id: IDL:omg.org/CosNaming/NamingContextExt:1.0
> >     IIOP::Profile_host: external.domain.es
> >     IIOP::Profile_port: 15000
> >     This is ok.
> >     Then client application asks for MinDevControl_Factory proxy, but
> > the response includes the following:
> >     IOR::type_id: IDL:MinVClient/MinDevControl_Factory:1.0
> >     IIOP::Profile_host: 1.2.3.4
> >     IIOP::Profile_port: 15600
>
> >     So the client can't connect to 1.2.3.4 since it's an internal IP.
> >     We thing the response should include something like:
> >     IOR::type_id: IDL:MinVClient/MinDevControl_Factory:1.0
> >     IIOP::Profile_host: external.domain.es
> >     IIOP::Profile_port: 15600
>
> >     REPEAT BY:
>
> >     SAMPLE FIX/WORKAROUND:
> >       No workaround so far.