[omniORB] omniEvents push fails to connect (no peer name)

Austin austin.green at orcon.net.nz
Sat Dec 13 05:34:05 GMT 2014


Hi Duncan,

Many thanks for your clear explanation of what was happening.  Tried your 
telnet suggestion, then checked out the socket status with TCPView (a handy 
utility from Microsoft) which led me to the solution as described below.

Is omniEvents capable of supporting IPv6?  Do I need to upgrade the suppplier 
host somehow?

On Sat, 13 Dec 2014 you wrote:
> On Wed, 2014-12-03 at 12:57 +1300, Austin wrote:
> [...]
> > omniORB: Server accepted connection from giop:tcp:[::ffff:192.168.2.4]:52819
> This is the consumer connecting from 192.168.2.4, port 52819. It is
> connecting with IPv4 on an IPv6-capable socket.
> [...]
> > omniORB: Client attempt to connect to giop:tcp:<consumer-host>:52815
> The consumer published its name in its object reference, claiming it is
> listening in port 52815 (which seems likely to be true because it's
> close to 52819).
> > omniORB: Name '<consumer-host>' resolved: 192.168.2.4
> omniORB resolves the name to plain IPv4 192.168.2.4.
> > omniORB: Failed to connect (no peer name): 192.168.2.4
> The connection attempt fails.
> 
> Perhaps the consumer was not really listening on port 52815?  Or perhaps
> it is only accepting IPv6 connections?  Or perhaps there is a firewall
> that doesn't permit the incoming connection?

It turned out that the socket was IPv6 only -- I had naively assumed that IPv6 
sockets would automatically somehow support v4 as a subset.

> When it's in this state, can you connect to the consumer with telnet on
> the port it claims to be listening upon?  e.g.
>   telnet 192.168.2.4 52815

I could not telnet: "connection refused".  However, after disabling IPv6 on 
that NIC on the consumer host, I could then telnet to the listening socket, 
and furthermore the push events were now getting through to the consumer.

Eternally grateful!

Best regards,
Austin.



More information about the omniORB-list mailing list