Issue2078

When creating an ipv4 socket and binding it on ipaddr_any, getsockname returns an ipv6 address:

>>> s=socket(AF_INET, SOCK_STREAM)
>>> s.bind(("",0))
>>> s.listen(1)
>>> s.getsockname()
(u'0:0:0:0:0:0:0:0', 58526)

Expected behavior: return the ipv4 address "0.0.0.0" instead.

Hi Irmen.

I am not able to reproduce this on my local setup.

What version of jython is this happening on?
What java version?
What operating system?

Happens with jython trunk (2.7b1+).
Happens on Windows 7 (java 1.7) and OS X 10.8.4 (java 1.6).
Both machines have a functional IPV6 (and IPV4) network address assigned.

Same result with the  new socket-reboot code in beta 3, but this is not surprising since this part is unchanged (the internal function _socket._get_jsockaddr)

Target beta 4

Also need to fix the nearly identical issue (from an implementation perspective) as reported in #2079:

from socket import *
s=socket(AF_INET6, SOCK_STREAM)
s.bind(("",0,0,0))
s.listen(1)
assert len(s.getsockname()) == 4

Netty4 is strange... you can bind its ServerBootstrap with an Inet4Address, but when you query the Channel it returns for its local address, you get an Inet6Address!

Here's a print-peppered _realsocket.listen() method:

def listen(self, backlog):
    # ...
    print 'Binding to {:s} with type {:s}'.format(repr(self.bind_addr.getAddress()), type(self.bind_addr.getAddress()))
    future = b.bind(self.bind_addr.getAddress(), self.bind_addr.getPort())

    # ...

    self.channel = future.channel()
    localaddr = self.channel.localAddress()
    print 'The channel is bound to {:s} with type {:s}'.format(repr(localaddr.getAddress()), type(localaddr.getAddress()))

    # ...


And what you get when you execute that modified method:

Binding to /0.0.0.0 with type <type 'java.net.Inet4Address'>
The channel is bound to /0:0:0:0:0:0:0:0 with type <type 'java.net.Inet6Address'>


And that's why you get an IPv6 '0' address from getsockname() after binding it with IPv4 '0' address.

As for @zyasoft test case outputting the correct number of tuple elements for AF_INET6 socket address, here's a simple patch to address just that.

The original issue still remains since I don't know how to work around that Netty 4 quirk yet.

How about this hack-ish workaround?

Merged in this commit: https://bitbucket.org/jython/jython/commits/0e62bf96c77388f61ac68c22482f3c2ab9e329a4